温馨提示！由于新浪微博认证机制调整，您的新浪微博帐号绑定已过期，请重新绑定！&&|&&
我是阿赵,请多多指教！
LOFTER精选
网易考拉推荐
用微信&&“扫一扫”
将文章分享到朋友圈。
用易信&&“扫一扫”
将文章分享到朋友圈。
这里假设我们在Unity3D里面写的代码抽象成这样一个Test类，里面包含了公开和私有的变量，有自带的Start方法、Update方法和OnGUI方法，还有public、private和protected方法。虽然说用抽象类代表了项目里面实际的类，但为了可以看得到代码效果，所以在方法里面大概写了一些简单的打印的命令。&把这个Test类放到上次的类库项目里面，然后生成dll，放到Unity3D项目里面：&其实要看到dll里面的内容，很多软件都可以，我们这里就拿Unity3D自带的MonoDevelop来看。找到引用里面的dll文件，这里是AzhaoDll.dll。&可以直接浏览到dll里面的内容，看看刚才那个Test类，是不是每一个变量、每一个方法都一字不缺的显示出来了？&还有上次写的Math3D方法，也能直接看得到。&dll就是这么不保险的一个东西，所以我们要引入这一篇文章的内容：对Dll进行混淆。.Net的代码混淆器有好几种，比如VS自带的DotFuscator、小巧的Reactor，或者相对比较专业的xeoncode。这里我使用了xeoncode 2010版本。界面如下：&来到Application，可以添加dll文件：&选择需要混淆的dll：然后在Project可以看到dll里面的类、变量和方法。看到某些变量和方法前面打了勾，这是需要混淆的意思，这个可以自己调整，后面再说：&&在Output里面选择一个输出的路径：&然后点击右下角的Build Application，就可以发布混淆好的dll。&把混淆好的dll放回Unity3D项目，就可以看到，这次的dll里面出现了很多随机数字和字母组成的变量名称和方法名称：&仔细的看，可以看出，刚才打钩了的方法和变量都变成乱码名称，然后在方法调用里面也会发生一些变化，除了名称改变以后，代码本身也会发生一些变化，没有之前那么直接的显示出调用的情况，如果是复杂的调用，将会出现goto来代替了。这样一来，就算是写代码的人自己也很难看得明白这些代码了。当然如果真的非常有心的逐个变量方法名称去对应，逐个goto调用去查找，也还是可以还原的，但估计很少人会话这个功夫去做这种事情。到这里，混淆的目的就达到了。 不过现在拿这个dll去实际运行，会发现出现很多问题的，比如Unity3D自带的方法Start、Update之类的是不会执行的。这是因为混淆的时候把一些不应该混的东西给混淆了。那么接下来就说一下注意的事项：1、public和protected的变量和方法，默认是不会混淆的，你也可以手动的把勾打上，让它混淆，不过由于这些是被外部调用的变量和方法，你混淆了它的名称，那么外部调用的时候是必然出错的。2、像Unity3D的Start、Update、OnGUI等MonoBehaviour自带的方法，都是具有特定含义的，虽然是私有方法，但也不应该混淆，不然到了该执行的时候就不会执行了。3、某些有特定含义的名称，或者有用到使用字符串来识别变量或者方法名称时，这些方法和字符串都不应该混淆，不然也会出现调用不到的情况。& 以上是简单的使用方法，具体的情况可能要到真正用的时候才会出现，所以就随机应变了。 六一节快乐！&
阅读(10885)|
用微信&&“扫一扫”
将文章分享到朋友圈。
用易信&&“扫一扫”
将文章分享到朋友圈。
历史上的今天
loftPermalink:'',
id:'fks_',
blogTitle:'Unity3D项目程序加密2——对dll进行混淆',
blogAbstract:'\t之前一篇文章阿赵已经简单的介绍了怎样把自己写的代码打包成dll动态链接库，然后在Unity3D里面用。那么接下来的事情似乎就很简单了，我们在Unity3D里面写脚本，到最后完成时，把核心的代码剪切出去打包成dll文件再放回项目里面。这样似乎别人就不能直接修改你的代码了。事实真的是这样吗？这里假设我们在Unity3D里面写的代码抽象成这样一个Test类，里面包含了公开和私有的变量，有自带的Start方法、Update方法和OnGUI方法，还有public、private和protected方法。虽然说用抽象类代表了项目里面实际的类，但为了可以看得到代码效果，所以在方法里面大概写了一些简单的打印的命令。',
blogTag:'dll,混淆,xeoncode',
blogUrl:'blog/static/',
isPublished:1,
istop:false,
modifyTime:2,
publishTime:2,
permalink:'blog/static/',
commentCount:12,
mainCommentCount:5,
recommendCount:3,
bsrk:-100,
publisherId:0,
recomBlogHome:false,
currentRecomBlog:false,
attachmentsFileIds:[],
groupInfo:{},
friendstatus:'none',
followstatus:'unFollow',
pubSucc:'',
visitorProvince:'',
visitorCity:'',
visitorNewUser:false,
postAddInfo:{},
mset:'000',
remindgoodnightblog:false,
isBlackVisitor:false,
isShowYodaoAd:false,
hostIntro:'我是阿赵,请多多指教！',
hmcon:'0',
selfRecomBlogCount:'0',
lofter_single:''
{list a as x}
{if x.moveFrom=='wap'}
{elseif x.moveFrom=='iphone'}
{elseif x.moveFrom=='android'}
{elseif x.moveFrom=='mobile'}
${a.selfIntro|escape}{if great260}${suplement}{/if}
{list a as x}
推荐过这篇日志的人：
{list a as x}
{if !!b&&b.length>0}
他们还推荐了：
{list b as y}
转载记录：
{list d as x}
{list a as x}
{list a as x}
{list a as x}
{list a as x}
{if x_index>4}{break}{/if}
${fn2(x.publishTime,'yyyy-MM-dd HH:mm:ss')}
{list a as x}
{if !!(blogDetail.preBlogPermalink)}
{if !!(blogDetail.nextBlogPermalink)}
{list a as x}
{if defined('newslist')&&newslist.length>0}
{list newslist as x}
{if x_index>7}{break}{/if}
{list a as x}
{var first_option =}
{list x.voteDetailList as voteToOption}
{if voteToOption==1}
{if first_option==false},{/if}&&“${b[voteToOption_index]}”&&
{if (x.role!="-1") },“我是${c[x.role]}”&&{/if}
&&&&&&&&${fn1(x.voteTime)}
{if x.userName==''}{/if}
网易公司版权所有&&
{list x.l as y}
{if defined('wl')}
{list wl as x}{/list}关于Unity中的资源管理，你可能遇到这些问题 - 知乎专栏
{"debug":false,"apiRoot":"","paySDK":"/api/js","wechatConfigAPI":"/api/wechat/jssdkconfig","name":"production","instance":"column","tokens":{"X-XSRF-TOKEN":null,"X-UDID":null,"Authorization":"oauth c3cef7c66aa9e6a1e3160e20"}}
{"database":{"Post":{"":{"title":"关于Unity中的资源管理，你可能遇到这些问题","author":"zhang-xin-81-92-50","content":"原文链接：在优化Unity项目时，对资源的管理可谓是个系统纷繁的大工程。鉴于Unity独特又绝（cao）妙（dan）资源打包的AssetBundle管理机制，不同资源的属性适合于不同的存储和加载方式。此外，要处理好成百上千个资源之间的相互依赖关系也非易事。谁说良好的资源管理不是个艺术呢？：）——————————————————关键字AssetBundle资源制作 纹理\\网格\\材质\\Shader\\音频\\动画Lightmap一、AssetBundle 相关Q1：Unity中的SerializedFile是怎么产生的？请问用Unload(false)可以清除吗？因为读取了Bundle里面的内容后已经赋值给其他物体了。而且我把图片都打成了Bundle，然后读取出来，图片的大小应该是超过了这个SerializedFile的大小的？SerializedFile是AssetBundle加载时产生的序列化信息，一般为LoadFromCacheOrDownload、LoadFromFile和New WWW加载本地AssetBundle文件所致。如果AssetBundle中的资源已经加载，且后续没有依赖该AssetBundle的资源进行加载，那么可以通过Unload(false)将其删除。SerializedFile中记录的是AssetBundle的序列化信息，而不是其包含资源的内容，因此，其大小要小于或远小于资源的实际内存。Q2：我们现在采取了2种资源管理方式， 我想了解下内存占用问题。 方式A：AssetBundle加载好以后在内存中保留， 如果需要创建对象就通过Instantiate来创建。方式B：AssetBundle加载好以后立刻通过Instantiate实例化一个对象， 然后Unload（false）这个AssetBundle，如果需要，创建对象通过clone来完成。对于方式A，在Profiler中发现 WebStream中有相关AssetBundle文件存在， 我们认为这份内存是多余的, 所以就采取了方式B， 方式B又面临资源卸载不干净的情况。想确认一个问题， 如果采取方式A： 一个 xxx.assetBundle原始文件大小是 1MB， 解压到Webstream内存中是2MB， 最终实际内存占用是2MB 还是3MB 呢？如果采取方式A：最终实际内存占用是2MB，而不是3MB，WebStream中已经包含原始AssetBundle的数据。对于没有依赖关系的AssetBundle文件，我们推荐方式B的形式对AssetBundle进行卸载，这样可以免除不必要的内存占用，对于这种方式加载出来的资源，可以通过Resources.UnloadAsset和Resources.UnloadUnusedAssets来进行卸载，如果无法卸载，则该资源一定被缓存了，研发团队可通过检测自己的缓存池/Constainer来进行检测。同时，如果是Unity 5.3以后版本，可尝试通过Memory Profiler来进一步查看。Q3：打包时候AssetBundle的md5总变化(被打包的东西没变)，请问能怎么解决？有说法是加上DeterministicAssetBundle就可以，但是我尝试后发现md5依然变化。该方法确实并不受用。对于Unity 4.x版本的AssetBundle文件，其md5值在某些情况下确实会前后不一致（哪怕是完全一样的内容进行打包）。对于该系列版本，仅能建议开发团队建立配置文件来对AssetBundle进行管理。而对于Unity 5.x版本，则可以在打包时开启 AppendHashToAssetBundleName 选项，这样Unity引擎会在每个AssetBundle文件后生成一个唯一的HashID（显示地放在文件名后），开发团队可以通过该ID来判断对应的AssetBundle文件是否发生改变。Q4：如果采用依赖打包的话，比如NGUI，图集A作为被依赖包，界面1、2、3作为独立包，分别依赖打包。当图集A重新打包的时候，是不是界面1、2、3也都要重新打包？目前我们是界面打包时清空全部的图集信息再打包，在客户端加载后再动态赋值回来。这样可以实现单独更新图集，但是代价就是加载的性能。请问有什么更好的解决方案呢？“当图集A重新打包的时候，是不是界面1、2、3也都要重新打包”，这是不需要的，Unity 4.x的依赖打包的限制在于，在重新打一个包时需要将它依赖的包都重新打一次，但不需要重打依赖它的包。Q5：请问内置的shader怎么打包？我用到了内置材质球，不只是Shader，这时候在Profiler中看到加载的结果中会出现多份，如下图所示通常有两种方式对内置的Shader进行打包：将其添加到Graphics Settings中的Always Included Shaders 中，此时添加后的内置Shader就不会被打入AssetBundle包中；在下载内置的 Shader，将其导入项目，并替换成非内置的材质球，从而可以直接通过脚本来控制其打包的方式。Q6：请问粒子特效的Shader是否不能使用依赖打包？ 我们对Shader的模型和特效使用了依赖打包，运行的时候发现模型显示是正常的，但是粒子特效使用的Shader就不能正常运行，特效显示不正常。而在编辑器中，我们看到Material中的Shader是存在的。这时候如果重新手动给这个Material指定同样的Shader，这个粒子特效就能正常显示，请问这是什么原因引起的？部分 Shader 在打包到 Android 版本的 Assetbundle 之后，会因为平台不兼容而无法正确显示，这是因为打包后的 Shader 代码只保留了目标平台的预编译代码，不一定能够在 Editor 下运行，所以这是正常现象。 但这并不会影响依赖打包，因为在真机上并不会出现类似的问题。Q7：Resource的场景下有两个场景Scene1.unity和Scene2.unity。我要对这些文件进行打包，生成了Scene1.assetbundle \nScene1.assetbundle.meta \nScene2.assetbundle \nScene2.assetbundle.meta\n如果我有相同的资源，理论上它会在这两个包里各存一份，这样就造成了包体过大。所以有没有办法把共享资源做成依赖项单独打包，这样的话每个场景就不会过大了。Unity 5.x的BuildAssetBundles打包机制是否和Unity 4.x不一样？原来的打包机制已经被剔除了吗？用Unity 4.x 的 Push/Pop 是可以抽出相同的资源，并且据我们所知该方法在Unity 5.x 中也受用。根据Unity 5.x新的打包机制，只要把相同资源的 AssetBundle Name 设置好，打包时就会自动抽出来。Q8：现在生成AssetBundle的时候每个文件会多生成一个Manifest文件，这个文件也需要一起随着AssetBundle上传吗，在资源加载的时候具体怎么用呢？每个文件多生成的Manifest 文件是不需要上传的，其作用就是供开发人员查看AssetBundle 中的依赖关系等信息。但除了每个文件多生成的 Manifest 以外，根目录下还会有一个与根目录同名的AssetBundle 以及 Manifest 文件，通过运行时加载这个AssetBundle，可以得到一个 AssetBundleManifest 对象，然后就可以通过这个对象得到AssetBundle直接的依赖关系。更多信息可以参考Q9：如果我有一个Prefab，它的Dependencies都在Resources文件夹中，那么，当我在AssetBundle打包时，只打包这个Prefab（不指定pleteAssets和BuildAssetBundleOptionsCollectDependencies）的话，这个Prefab能够正确实例化吗？这是不能正确实例化的，因为AssetBundle中的资源和Resource文件夹下资源是不会建立依赖关系的（脚本除外，因为开启BuildAssetBundleOptionsCollectDependencies 时，脚本依然不会打包到AssetBundle中）。所以会出现Mesh、Material等的丢失。Q10：我们通过AssetBundle预加载Shader后，并没有卸载AssetBundle，但是发现后面加载的Object并没有引用到正确的Shader，这可能是由于什么原因呢？很可能是项目中AssetBundle的依赖关系打包不正确。后续加载的AssetBundle都需要与Shader的AssetBundle文件进行依赖，这样Unity引擎才会在加载后续AssetBundle时，将Shader进行关联。建议开发团队通过UWA资源检测来检测下AssetBundle文件的依赖关系。主要查看两处，一个是Shader是否被冗余打包；一个是其& 他的AssetBundle是否与Shader的AB进行正确的依赖。具体检测效果如下：如下图红框所示，开发团队可以直接查看Shader以及其他资源在AssetBundle包中的冗余情况。Q11：我游戏里重复的特效较多，有些只是图案相同但改变了颜色参数，如果都打成独立AssetBundle，则内存里面会有多份Texture。关于这样的打包一般有什么推荐的方法呢？如果是相同内容且仅是整体颜色不同的话，那么建议项目中只保留一份初始纹理资源，并通过Shader在运行时改变其整体配色，从而达到不同的效果。但如果是局部配色不同，那么可以在原始纹理的基础上加一种或几种Mask纹理，用来负责颜色的自适应调配，然后再通过Shader来达到不同的展示效果。Q12：请问一下，我两个预设都引用了第三个AssetBundle的贴图，如果不希望这张贴图存在两份，一定要等这两个预设都加载好了，才能卸载贴图的AssetBundle吗 ？是的，但并不是因为这样做会使“这张贴图存在两份”，而是因为如果先卸载贴图的AssetBundle会导致后续加载两个预设时会丢失依赖，即找不到贴图。如果脚本中会对这个情况进行检查并重新加载贴图的AssetBundle，那么此时才会造成“这张贴图存在两份”的问题。Q13：UGUI的图集操作中我们有这么一个问题，加载完一张图集后，使用这个方式获取其中一张图的信息：assetBundle.Load (subFile, typeof (Sprite)) as S 这样会复制出一个新贴图（图集中的子图），不知道有什么办法可以不用复制新的子图，而是直接使用图集资源 。经过测试，这确实是 Unity 在 4.x 版本中的一个缺陷，理论上这张“新贴图（图集中的子图）”是不需要的，并不应该加载。 因此，我们建议通过以下方法来绕过该问题：在 assetBundle.Load (subFile, typeof (Sprite)) as S 之后，调用Texture2D t = assetBundle.Load (subFile, typeof (Texture2D)) as Texture2D;Resources.UnloadAsset(t);从而卸载这部分多余的内存。Q14：下图一是刚进游戏时获取的信息，第二张是开关几次同一个UI界面后获取，对比两图我们发现有多份重复的Texture。请问这是为什么？我们的加载方式是UI通过AssetBundle加载，加载后会释放AssetBundle，然后再次加载 UI 就会造成纹理资源的冗余。刚进游戏时获取的图中出现的“重复”资源可能并不是冗余，因为 Atlas的一个 Group 中可能包含多张一样大小的Page（即纹理），而这几个Page在内存中的名字是一样的。但是，如果同一UI界面多次开启后，内存中出现了更多同样的资源，则说明UI的管理方式存在一定问题。对于频繁使用的UI，我们建议在加载之后通过缓冲池对其进行缓存，后续使用时，直接通过缓冲池获取即可。而不要每次均通过AssetBundle进行加载，这种做法既会造成更大的CPU占用，同样会很大几率造成资源的冗余。同时，如果多次开启的是不同UI界面，并且造成内存中同种资源的增加，则很有可能是UI在AssetBundle打包时形成了冗余（这种情况在目前的UGUI系统中较为常见）。对此，如果开发团队使用的是UGUI，那么我们的建议如下：对于使用Unity 5.x的新AssetBundle打包系统，则打包时尽可能将同种Atlas的UI界面打成一个AssetBundle文件，否则将很有可能出现资源冗余的情况；对于使用Unity 4.x的老AssetBundle打包系统，则可以将一个含有Atlas的Prefab（或其他Object）先打包，其他UI元素对其进行依赖即可。此外，开发团队可以考虑用
来加载共享包，因为 new WWW 的方式会在内存中形成 WebStream 造成较多的内存开销。关于该函数的具体优劣，开发者可以参考。Q15：项目在发布时，Player Setting中勾选的这个选项(Optimize Mesh Data)，对于已经打包并且放到了Streaming Assets中的AssetBundle文件有效果吗？模型资源里有个Optimize Mesh，是否能达到同样的效果？理论上 Optimize Mesh Data 是 Build Player 或者 Bundle 时才生效的，所以之前打好的 Bundle 就没效果了。另外，两个选项的效果是不同的，后者是调整面片排序的。二、资源使用纹理相关Q1：关于贴图类型设置请问有什么好的建议呢？是否所有的贴图都设置为Advanced比较好？这种情况下的贴图内存是不是比较小？Unity默认情况下会将绝大多数纹理设置为Texture模式。一般来说，Texture模式对于绝大多数纹理资源也都是合适的。上面的例子中，Advanced模式下之所以内存占用较小，是因为关闭了Mipmap选项，所以其内存下降了。其本质跟Advanced模式无关。Advanced模式较之Texture模式和其他模式，可以更大自由地对纹理资源进行控制。因此，如果你想对纹理资源进行更加自定义地设置，可以选择Advanced模式进行编辑。Q2：同样的包同一个图集，ETC2格式，在红米Note1上会比酷派的内存会大四倍，请问这是什么原因造成的？如果不支持OpenGL 3.0，会造成这么大的影响吗？ETC2 的格式理论上只在OpenGL ES 3.0 的设备上被支持，而在不被支持的设备上则会内部自动转成 RGBA32/ARGB32的格式，这对于 RGBA Compressed ETC2 8bits 的纹理就是放大了 4 倍。因此，如果希望在 OpenGL ES 2.0 的设备上对透明材质进行压缩，那么可以尝试使用分离 Alpha 通道的方式，用两个 ETC1 来进行压缩。Q3：我现在动态加载StreamingAssets下的贴图，代码如下我发现这种方式内存消耗很大，一张512 x 512的贴图占用了2MB，看官方的解析是内存和显存各需一份。想了解下动态加载贴图有什么推荐的方式吗？一般来说，我们比较建议通过AssetBundle来动态加载资源，而非通过bytes流来进行加载。如果你的项目正在使用这种方式来加载纹理，我们建议从策略上考虑将其更改。在我们目前来看，通过bytes流来生成资源，绝大部分原因是想对其进行加密，从而让资源难于破解。但其实这种加密方式用处不大，因为据我们所知，现在有很多工具可以直接通过底层显卡层来直接查看各种纹理、Mesh资源，比如Mali Graphics Debugger、Qualcomn Profiler等。因此，如果是从加密的角度来通过bytes流生成资源，那么我们建议通过AssetBundle这种直接的方式进行加载。Q4：iOS平台需要对图集做RGB和Alpha通道的分离吗？我发现在同样大小的图片（正方形），RGB Compressed PVRTC 4bits和RGBA Compressed PVRTC 4bits两种格式，占用内存是一样的，如果把一张图片分成两张，那么在iOS平台是不是占用内存多一倍？有透明通道的，对于它的图集怎么处理会更好一点？通常iOS下是不需要做通道分离的，因为 iOS 通用的 PVRTC 格式支持 Alpha 通道。但目前也有团队反馈，在 iOS 上进行通道分离有助于减少失真，可以在一定程度上提高视觉效果，因此也可以尝试做一个对比。如果发现占用内存是一样的，那么原始图片是RGB的。如果iOS上做通道分离，内存确实会增加一倍。UI的纹理在iOS下可以直接选择默认的 Compress，在打Atlas时会自动处理成 PVRTC，开发团队可以从Sprite packer窗口来看Atlas的压缩格式做个确认。Q5：在Unity 4.x的版本中，所有UI贴图使用ETC2格式，即使目标设备不支持该格式，也会解压成RGBA32使用。 而在目前使用的Unity 5.3.4版本中，iOS平台无法设置ETC2格式。如果压缩只能使用PVRTC格式，那么PVRTC存在显示效果比较差，并且图片必须为正方形，但如果用RGBA32格式，贴图占用的内存和存储又都过大，请问目前版本的Unity在iOS平台上应该如何设置UI贴图的压缩格式？我们建议可以先尝试其他的压缩格式看是否可以达到类似的效果，如ASTC格式。ASTC 在 iOS 的高端机上是被支持的，因此理论上在 Editor 下不会强制把 ASTC 转为 RGBA32，建议尝试设置为 ASTC 后打包，从 Editor.log 中或者直接从包体大小上可以看出是否确实使用了 ASTC。一般来说，如果 RGBA16 的效果可以接受的话，建议使用 RGBA16，虽然打包时相对大一些，但是内存中相比 RGBA32 能够减半，但使用 ASTC 的话，虽然打包时比较小，但是在普通机型上会被处理成 RGBA32，导致过大的内存开销。Q6：请问Unity引擎中使用什么贴图压缩格式，可以保证在占用内存相对较小的情况下True Color效果和原图相当？同时在iOS和Android平台上图片的压缩格式分别用什么比较合适？有什么需要注意的地方吗?目前来讲，并不存在一个所有GPU平台都支持硬件解压的压缩格式。 ETC1 和 PVRTC 分别是Android和iOS上我们最推荐的格式。 但对于透明纹理，ETC1不支持，而 PVRTC 则可能有较大失真，因此更推荐使用 RGBA 16。一般来说建议直接使用 Unity 默认的压缩格式（即选择 Compressed 即可，不需要做特殊设置），Unity 会做如下处理：Android 上不带Alpha通道的图片采用 ETC1，带Alpha通道的图片采用True Color中的RGB16，TrueColor中的 RGBA16 会&比 RGBA32 更节省空间，但图像的显示质量会差一些；iOS 上使用 PVRTC，但PVRTC格式要求纹理的长宽相等，且都是2的幂次（即POT，在ImportSettings中可以将NPOT的纹理自动转换成POT）。另外，针对Android 上的带Alpha通道的图片，还有一种常见的做法，即把Alpha通道独立出来作为另一张纹理，从而将 RGB 部分和 Alpha 部分分别采用 ETC1来压缩，但渲染时就需要自定义的 Shader来处理。同时，我们不建议直接使用 RGBA32 格式的纹理，因为它占用了很大的内存。一般建议使用 RGBA16 和 ETC 格式的纹理来进行加载。 如果转换到 RGBA16 格式时出现了类似“色阶”的颜色问题，则建议尽可能避免大量的过渡色使用。Q7：请问游戏中特效使用的很多贴图, 一般有什么好的方式去管理吗 ? 不合并图集的话会有上千张小的透明贴图, 合并图集又会有占用内存过多的问题。可以合并成Atlas，一般将尽可能同时出现频率较高的Texture合成Atlas，这样并不会造成内存过大。在这方面也可以参考我们前不久推荐的插件。Q8：iOS上方形POT图片有时候会失真，请问这种情况如何避免？一张NPOT的图变换成POT，是否有推荐的方法？ 采用 ToLarger 的模式拉成POT是否会有损失呢？在其他设置一致的情况下，这两种方式无论在加载还是渲染方面其实并没有实质上的差别。在我们接触到的大多数案例中，纹理资源方面的问题除了尺寸外，纹理格式、Mipmap设置和Read&Write功能同样是需要研发团队时刻关注的。Q9：纹理Atlas是建议合成一张2048（尺寸）的纹理还是四张1024的纹理？在其他设置一致的情况下，这两种方式无论在加载还是渲染方面其实并没有实质上的差别。在我们接触到的大多数案例中，纹理资源方面的问题除了尺寸外，纹理格式、Mipmap设置和Read&Write功能同样是需要研发团队时刻关注的。Q10：NGUI的图集在内存里存了多份，求问怎么清理？游戏运行中，UI Mesh出现多份不同内存的情况，是正常的，因为随着UI widget使用的增加或减少，创建的UI Mesh是会随着变化的。同时，如果不同UIPanel中存在相同Atlas的Widgets，则也会出现上图中的情况。因此，建议大家遇到这种情况时，查看单帧中NGUI UI Mesh重名的是否有多份重名资源。如果存在，则说明相同Atlas中的资源被多个不同的UIPanel所使用，这种情况是需要尽可能避免的。Q11：我在UWA报告中看到大量的n/a资源，其格式的高度和宽度等信息都无法获取，并且存在大量重复，请问我该如何定位这些文件？能否优化解决呢？\"图中n/a资源是我们在项目运行时检测到的无名称资源，一般来说，该类型资源并非Asset文件夹中的美术资源，而是项目通过脚本动态生成的资源，比如new Mesh、new Texture等操作，即会生成这种类型的无名称资源。对此，我们建议研发团队详细检测逻辑代码/第三方插件中诸如New Mesh/Textue等此类操作，同时，在脚本动态生成该类资源后，为其赋上一个名字，这样即可在后续测试中看到对应名称的资源使用情况。\"网格相关Q1：如果一个模型对应Skinned Mesh Renderer实例，那其所占的内存会随着角色增加而增长么 ？简单地从一个角色Prefab实例化（Instantiate）出多个实例时，Mesh并不会出现多份（这个行为与其他资源是一致的，包括Texture，AnimationClip，Material等等）。如果在内存中发现多份，可以考虑从项目中AssetBundle的加载方式入手，因为即使是同一个AssetBundle中的同一个角色Prefab，如果被反复进行“加载-实例化-卸载”操作，依然是会导致Mesh出现多份的（当然其他的资源也是一样）。Q2：我有一个特效依赖了两个FBX。我把这两个FBX的这个勾选去掉，Editor运行正常。否则就会宕机，请问这是什么原因？将FBX上的Read/Write Enabled关闭后，内存中便不再保存其Mesh的副本（只存在显存中），因此其属性就不可再被访问和修改。而粒子系统通常需要动态地修改其粒子的顶点属性。因此，理论上来说，供粒子系统使用的Mesh是需要开启Read/Write Enabled的，而在Editor下Mesh和Texture都是强制开启的，所以在真机上就会出现问题。Q3：MeshBaker 烘焙的Mesh可以保存到Prefab中，但是不能像FBX一样，设置Model导入设置中的Generate Lightmap UVs 等信息，请问有没有大招可以处理此情况？首先从理论上说，一个 Mesh 只能有一个 LightmapIndex 和 LightmapOffset 属性，这就决定了 Mesh 的合并必须在 Lightmap 的烘焙之前。而在做Mesh合并时，需要注意到UV2对于一个Mesh而言，其所有三角面的UV区域都必须是互不重叠的，所以不能简单直接地合并。考虑到合并前每一个Mesh的UV2区域都应该是在[0,1]x[0,1]的区间中，在合并时可以给每一个UV2区域做一个缩小和平移，从而可以把每个区间在互不重叠的情况下，放到同一个[0,1]x[0,1]的区间中。在UV2也正确拼合后，重新进行Lightmap的烘焙即可得到正确的效果。动画片段相关Q1：我想要在Editor下批量地对Animator Controller文件中每一个的State里的Animation Clip进行替换，但好像没有看到 Unity引擎有提供类似的API，只提供了能在Runtime时进行替换的方法，类似下图：我现在想要达到的目地是在Editor下写一个批量替换Animation Clip的插件，请问下Unity引擎是否有提供这样的接口呢？在Unity 5.x 中已有一套完整且稳定的 API 可以访问、修改和创建 Animator 中的任何元素。其命名空间是在 UnityEditor.Animations 下，以下Blog 中有一个简单的例子是通过脚本创建一个 AnimatorController 以及其中的各种属性和参数。另外，如果需要修改Animation Clip，可以直接修改一个 AnimationState 的 Motion 属性。 Animation Clip可以继承自 Motion。Q2：如果我的Animator是直接引用了FBX里的动画文件，而不是复制了FBX的动画文件出来再引用，那么打包的时候会把FBX都打包吗？这种情况下并不会把 FBX 打入 AssetBundle 中。将动画文件Copy出来通常是为了直接对动画文件打包，作为依赖包。Q3：我们的动画是放在FBX文件里的这样做导致打包的时候把一些无用的文件也打进AssetBundle包里了，实际上我们只想使用最后这个动画文件。但在编辑器里选中FBX文件里的动画文件时却没有AssetLabels这个窗口，设置不了AssetBundle Name。是不是只能用代码设置？还是意味着不能设置AssetBundle Name，只能把动画文件提取出来，类似下图这样单独的一个文件？在Unity 5.x 的打包机制下确实无法手动为 FBX 下的 Mesh 或 AnimationClip 单独资源设置 AssetBundle Name。因此，如果需要将这部分资源抽出来作为依赖包，目前确实就需要先通过脚本将这部分资源提取出来了。音频相关Q1：请问音频中的 Quality 什么意思？一般设置为多少合适？我拖进去一首歌曲，试了一下 在0 和 100 的情况下区别不大，但是生成的音频文件大小差别很大。Quality 表示在压缩音频时的失真程度（实际上可以认为是压缩算法的一个参数），该值越大，压缩后的文件越大，但音质保留的越好。而对于其失真的程度是视音频数据以及内部的压缩算法而定的，确实会有区别不大的情况。该值的设置原则就是，在音质失真可接受的情况下，越小越好。材质相关Q1：我们发现材质实例数量特别多，想问下这个对性能的影响如何，有没有什么建议？Material的内存占用一般很小，所以大量的Material资源对于内存的压力其实很小的。但是，它本身对于场景的切换时间是有影响的，即资源冗余得越多，切换场景时，UnloadUnusedAssets的开销越大，进而增加了场景的切换时间，同时也会影响DrawCall的拼合。所以，建议研发团队尽可能定位资源冗余的原因，并对其进行修复和完善。这一点，我们在UWA性能测评报告中的“分析和建议”中都有详细说明。Q2：我在UWA上进行了性能检测，在资源内存这里看到详情如下。请问这个数量峰值大于1是不是就是有问题的？但一个Material是很可能被实例化多份的。实例化后对象释放掉，然后清理掉原始的Material，按道理就不算冗余吧？毕竟大部分都是材质在操作，对贴图资源应该没有影响。而且，如果确实有那么多角色同屏怎么办呢？是的，如果数量峰值&1，则说明存在资源冗余的风险。如果是Material实例化，那么后者是有个（instance）后缀的，比较好识别。如果是new Material(Shader)出来的，那么是没有instance后缀的。但无论是哪种方式，如果数量峰值较大，都应引起大家注意。一般都是可以通过其他方法来尽可能避免冗余的。如果变化不是随机的，且Material参数变化情况比较少，那么可以根据参数的变化情况只做几种Material，然后通过脚本动态赋值。如果是随机或者动画，那就没什么办法了，要么改需求，要么就接受这么多。Shader相关Q1：我用内建的Shader渲染场景，深度图里有内容。而用自己的Shader，取到的深度图什么都没有，都是1，什么原因导致的呢？我已经打开ZWrite了。Unity的_CameraDepthTexture 的生成，会根据Rendering Path的选择和设备的不同使用不同的方法实现，一种是直接从depth buffer获取，另一种是添加额外的Pass来渲染到纹理。目前在移动设备上主要是通过后者实现，而后者的实现借助了Shader Replacement的机制（批量替换为简单的Shader，并将深度渲染到纹理中）。因此，在使用自定义的Shader时，就需要正确地设置RenderType的Tag（所有内置Shader都是设置好的），从而使得Shader Replacement正确地执行。具体可见文档：Q2：我们的游戏使用 Spine 插件，因为要用到裁切动画，所以修改了Shader，但在使用的时候出现异常： Shader wants normals, but the mesh Skeleton Mesh doesn't have them，可能是什么原因？开发团队需要注意：Surface Shader在生成代码中默认会处理normal（即 Spine/Skeleton 实际上是需要 normal 的），而对应的Mesh并没有包含normal，所以在预览窗口里渲染的时候会检查 Mesh 是否包含 normal 信息，没有的话会报这个错误。开发团队可以尝试编写一个Vertex & Fragment Shader 从而避免处理normal，也可以尝试创建带normal的Mesh，来避免该问题。Q3：以前端游时代，材质根据Pass不同、光照环境不同可以离线预编译成ShaderCache，运行时并不需要拼材质再实时编译，只要加载二进制代码就好了。那Unity有没有做这件事呢？我们是根据平台和环境预编译的Shader。对于支持 Binary Shader 加载的设备，在首次编译某个 Shader 的时候是会生成其对应的 Binary Shader Cache ，生成的 Binary 文件位于和 Application.persistantPath 并列的Cache 目录下。Q4：相同效果前提下，就性能而言，Shader 是用 V&F 还是Surface好？Surface生成的V&F比较庞杂，分支较多，如果不注意 #pragma surface 参数的选择，容易出现不必要的开销。举例来说，如果直接用 Unity 5.x 中默认创建的 Surface Shader （默认参数为 #pragma surface surf Standard fullforwardshadows），那么 Shader 是会做 Physically based Standard Lighting 的，而这在移动端开销非常大，且并非必要。Q5：某个Shader里设置了Culling Off，会影响到后面所有Shader的渲染状态么（假设后面不再设置Culling）？一次 Draw Call 提交所相关的 Render State 是不会影响到下一次的渲染状态的。如果不在 Shader 中显示指定 Cull 模式，则会使用默认的 Cull Back。Q6：我们将Shader放到了Resource的目录下，也已加到Editor的GraphicSetting里，也试过在加载一个空的Prefab时绑定对应的Shader。 但该Shader在Editor里无法正常显示，看运行时指向是有的，重新指一下就能显示了, 然而打包以后在手机上显示正常。这确实是Unity已知的一个问题，Android 和 iOS 的部分Shader在打包后，在Editor 下无法正常显示。 主要原因是在打包时，只会把对应平台的Shader预编译代码（如 gles ）打入包中，因此在 Editor 下会执行失败（通常 Editor 是 d3d 驱动）。 因此，目前只能尝试在Editor下重新指定Shader来绕过这个问题。Q7：我在shader里这么写的代码o.texcoord1 = vec2(mod(v.texcoord.x,1.0),mod(v.texcoord.y,1.0));
\n但是报错 undeclared identifier 'mod' at line 106 (on d3d11)，请问是什么原因导致的呢？报错表明mod在d3d11的Shader中是未定义的，如果开发团队无需在d3d11的平台上使用该 Shader，则可以添加以下预编译指令：#pragma exclude_renderers d3d11如果Shader依旧无法正常显示，那可能是因为在Editor中使用的是 DX11（可以从标题栏中看出）。 可以尝试修改DX9的参数 ：Build Settings -& 点击 PC, Mac ... -& Player Settings（不需要点击 Switch Platform） -& 去掉 Auto Graphics API for Windows 的勾选，只保留 Direct3D9。同时，开发团队也可以直接使用 fmod 替换 mod，理论上 fmod 在各个平台都是支持的。字体相关Q1：我们现在为了美观，需要同时使用2套字体。但是每增加一套字体，就会内存增加50MB左右。请问你们在优化其他Unity游戏时，怎么处理类似情况的？如果美术字不多的话，建议使用单独的字体贴图来进行实现，从而来达到特定美术字显示的效果；如果美术字较多的话，那么仅能建议使用另外一个套字体来进行实现。一般来说，字体的内存量应该也是完全可以控制在10MB以下的。开发者可以直接在Unity Profiler中查看字体的内存占用，也可以通过上测评报告中的具体资源信息页面查看对应的字体资源使用情况。Q2：我做的预设用到了这个字体我将这个预设打成AssetBundle包，通过Profiler分析时发现占了两份内存。下面这个SIMHEI应该是那个TTF的，为什么会占两份内存呢？通常TTF文件会包含一个字体的多个字型，如可能包含正常字型、加粗字型、斜体字型等。而在Unity中会将其分为不同的Font资源，且他们之间会相互依赖。所以，如果项目中确实需要加粗字型的话，内存里出现两个Font是正常的，但如果实际上不需要加粗，那么可以尝试寻找一个不包含加粗字型的字体文件来替换该TTF文件。粒子系统Q1：我在UWA上提交了资源检测，资源打的是依赖包，报告显示Default—Particle这个资源存在大量冗余，这个是正常的吗？Default—Particle 这个是粒子系统的默认资源。如果使用的是默认的粒子系统，没有对Material进行修改，且每个粒子系统都是打一个AssetBundle文件的话，那么该冗余问题是正常的。对此，我们建议开发团队把下图中默认的Material换成自己的资源，不使用Built-in资源，这样通过依赖关系打包，就不会出现该资源冗余的问题了。LightmapQ1：Unity 5.x 能把指定集合的Mesh烘焙到一张Lightmap里吗？Unity 5.x 是没有这样的功能项的。据我们的判断，这样的需求通常是为了动态加载，因此可以尝试将Mesh分组到不同的场景分别烘焙。而在加载时可通过脚本动态地合并Lightmap，同时将物件的Lightmap Index进行正确的偏移即可。Q2：Lightmap在Baked GI的等待时间比较长(Realtime GI已关闭)，想请教有没有什么建议的参数或是方式，可以缩短等待的时间?目前就我们的了解，在Unity 5.x比较影响烘焙时间的主要是大面积的面片导致Light Transport 过程过久（Enlighten 的机制所限）。可以尝试拆分面积较大的面片，来提高烘焙的速度（通常，拆分大面积的面片对渲染性能也会有所提升）。主要原因可参考如下的帖子： Q3：如下图所示，第一张显示的是没有烘培Lightmap的场景效果，里面有一盏点光源；第二张显示的是烘培Lightmap后的场景效果。请问为什么同一盏点光源照亮的效果差别那么大？简单来说，这就是实时的直接光照和全局光照的差别。在渲染时前者只能处理光源和单个物件之间的直接光照，而后者在烘焙时是通过光线跟踪或者辐射度等复杂算法，计算出所有物体各个表面之间相互反射的光照信息，这也是烘焙Lightmap需要较久的时间的原因 。可以发现在全局光照下，即使是物体的背面也会因为其它表面的反射而被照亮，这在直接光线下就无法实现这样的效果。Q4：当关闭预渲染GI时会出现IndirectResolution，这个参数有什么用，为什么调大了以后会大大增加渲染时间，但是烘培出来没有啥效果。简单来说，该值主要控制的是GI的烘焙密度，数值越大，表示每个单位距离内的texel越多，即烘焙得越精致，自然烘焙的时间也越长。该值并不需要越大越好，场景越小，建议该值越低。该值为1时，对于多数场景，其烘焙效果已经足够了，升高该值，其效果也不会有明显提升。开发者也可以参考Unity官方的说明文档：Q5：Lightmap丢失。用Unity5.1.2的AssetBundle做热更新，资源导出的时候分析了所有的依赖项单文件导出。比如在导出场景的时候场景的烘焙出来的LightmapSnapshot.asset文件导出不了，导致运行的时候场景的Lightmap丢失了。LightmapSnapshot.asset 本身是Editor下使用的，并不能单独被打包进AssetBundle。 运行时加载Lightmap，一种方法是把场景（.unity 文件）打成AssetBundle加载，Lightmap 信息会打入场景AssetBundle（因为Lightmap信息和场景绑定）。另一种是通过Lightmapsettings.Lightmaps方法来运行时设置。需要注意的是，同时还需要重设Prefab的Lightmap信息（Lightmapindex和Lightmapscaleoffset），因为Lightmap信息在Unity 5.x下不会保存在Prefab 上。另外存在一种可能，Unity 5.x中加入了Shader Stripping功能，在打包时，默认情况下会根据当前场景的Lightmap及Fog设置对资源中的Shader进行代码剥离。这意味着，如果在一个空场景下进行打包，则Bundle中的Shader会失去对Lightmap和Fog的支持，从而出现运行时Lightmap和Fog丢失的情况。 而通过将Edit-&Project Settings-&Gaphics下Shader Stripping中的modes改为Manual，并勾选相应的Mode即可避免这一问题。Q6：Lightmap在PC上显示正常，但是转到Android平台上存在色差，颜色普遍偏暗。一般来讲，有两种情况可能会导致色偏和亮度差异。Unity烘焙的Lightmap是32bit的HDR图，而移动设备通常不支持HDR图(32bit per channel)，会按照LDR图(8bit per channel)的形式进行处理，因此会出现色偏问题。因此我们建议：1）在移动平台下使用Mobile/Diffuse材质，可载入Standard Assets(Mobile) package获得。如果要获得更合适的效果，需要自行修改Lightmap的DecodeLightmap函数，该函数可在Unity\\Editor\\Data\\CGIncludes\\UnityCG.cginc文件中找到。需要说明的是，这种方法也不能达到与PC端完全一致的效果。2）如果需要PC和移动平台的显示效果一致，可以用图像编辑软体修改Lightmap為LDR格式，例如PNG(8bit per channel)。3）为了避免类似问题，请不要使用过于强烈的Light进行烘焙，因為Light的强度(Intensity)越高，色偏问题会越严重。若有阴影丢失时，可以尝试检查一下模型的Lightmapindex、Lightmapscaleoffset、UV2等影响Lightmap采样的一些参数。另一种可能是存在过曝现象，可以尝试将playersettings -& use direct3d 11关闭，看问题是否解决。Q7：在同一场景里烘培的Lightmap，我用了2张的光照图，大小是5.3MB；别人用了3张的图，大小是4.3MB。请问是什么影响这个光照图的大小，在哪里调？首先，请确认下Lightmap的类型，Single类型只生成一张，而Dual和Directional会生成两张。 其次，请确认下当前的发布平台，Android下的Lightmap会比Standalone更小。因为不同平台采用的压缩格式不同。此外，Lightmapping中的Lock Atlas，Resolution，Padding等选项也会影响最后烘焙光照图的大小。Q8：在游戏中，有些Mesh在编辑时候是接收Lightmap的，出于某些原因我们合并了相同的Mesh（材质也相同）。但是发现原先的Lightmap不再影响合并后的Mesh，请问怎么才能实现让合并后的Mesh也接收原先的Lightmap？如果Lightmap不止一个的话，手动合并Mesh是会出现问题的，因为合并的Mesh烘焙信息很可能出现在不同的Lightmap中，但合并之后的Mesh在渲染时只能使用一个Lightmap，这样uv2读取到Lightmap信息就会出现问题，进而出现这种现象。其实，对于材质相同的Static物体并不需要手动对其Mesh进行combine，因为Unity的Static Batching会自行完成。而如果由于某种特定需求一定要将Mesh进行合并的话，那么也要将其所需要的Lightmap也一并合并，同时改变相应的uv2。不仅如此，Shader中Lightmap也需要进行相应修改，这是比较复杂的，所以我们并不建议这样的做法，因为可能会花掉开发团队大量的开发时间。Q9：当关闭预渲染GI时会出现IndirectResolution,这个参数有什么用，为什么调大了以后会大大增加渲染时间，但是烘培出来却没有什么效果。该值主要控制的是GI的烘焙密度，数值越大，表示每个单位距离内的Texel越多，即烘焙得越精致，自然烘焙的时间也越长。该值并非越大越好，场景越小建议该值越低。该值为1时，对于多数场景，其烘焙效果已经足够了，升高该值，其效果也不会有明显提升。","updated":"T03:08:11.000Z","canComment":false,"commentPermission":"anyone","commentCount":6,"collapsedCount":0,"likeCount":39,"state":"published","isLiked":false,"slug":"","lastestTipjarors":[],"isTitleImageFullScreen":false,"rating":"none","titleImage":"/v2-88db6bd5daad72e02f412_r.png","links":{"comments":"/api/posts//comments"},"reviewers":[],"topics":[{"url":"/topic/","id":"","name":"Unity（游戏引擎）"},{"url":"/topic/","id":"","name":"性能优化"},{"url":"/topic/","id":"","name":"手机游戏开发"}],"adminClosedComment":false,"titleImageSize":{"width":800,"height":499},"href":"/api/posts/","excerptTitle":"","column":{"slug":"uwa4d","name":"UWA：简单优化、优化简单"},"tipjarState":"activated","tipjarTagLine":"用一杯咖啡为你省下消磨一个难题的时间！","sourceUrl":"","pageCommentsCount":6,"tipjarorCount":0,"annotationAction":[],"snapshotUrl":"","publishedTime":"T11:08:11+08:00","url":"/p/","lastestLikers":[{"bio":"全栈码工","isFollowing":false,"hash":"a356ccac320ffbea24e7b2e889f016d2","uid":84,"isOrg":false,"slug":"liao-xin-wei","isFollowed":false,"description":"","name":"廖鑫炜","profileUrl":"/people/liao-xin-wei","avatar":{"id":"da8e974dc","template":"/{id}_{size}.jpg"},"isOrgWhiteList":false},{"bio":"","isFollowing":false,"hash":"9e50def5330cbd28e0bfff4a83707d48","uid":80,"isOrg":false,"slug":"annie-zhang-25-92","isFollowed":false,"description":"","name":"柚梨柚梨","profileUrl":"/people/annie-zhang-25-92","avatar":{"id":"da8e974dc","template":"/{id}_{size}.jpg"},"isOrgWhiteList":false},{"bio":"","isFollowing":false,"hash":"94da5ad3c68310bbf2b4","uid":070300,"isOrg":false,"slug":"cao-yang-63-51","isFollowed":false,"description":"","name":"曹阳","profileUrl":"/people/cao-yang-63-51","avatar":{"id":"da8e974dc","template":"/{id}_{size}.jpg"},"isOrgWhiteList":false},{"bio":"为2061制造回忆","isFollowing":false,"hash":"7eedba6752bfa7e7b2e9","uid":12,"isOrg":false,"slug":"lucidniht","isFollowed":false,"description":"","name":"幻想多","profileUrl":"/people/lucidniht","avatar":{"id":"de519c741","template":"/{id}_{size}.jpg"},"isOrgWhiteList":false},{"bio":"","isFollowing":false,"hash":"a79bdefa0","uid":92,"isOrg":false,"slug":"qing-yihuo","isFollowed":false,"description":"艺术设计研究生 & Digital Arts and Humanities MA联合培养中，技能点分给了编程、游戏、设计、绘画。","name":"青一火","profileUrl":"/people/qing-yihuo","avatar":{"id":"v2-8ae6ffbffb46b3c","template":"/{id}_{size}.jpg"},"isOrgWhiteList":false}],"summary":"原文链接：在优化Unity项目时，对资源的管理可谓是个系统纷繁的大工程。鉴于Unity独特又绝（cao）妙（dan）资源打包的AssetBundle管理机制，不同资源的属性适合于不同的存储和加载方式。此外，要处理好成…","reviewingCommentsCount":0,"meta":{"previous":{"isTitleImageFullScreen":false,"rating":"none","titleImage":"/v2-a0e84aa99e3ae89ad8328df09bab9ef2_r.png","links":{"comments":"/api/posts//comments"},"topics":[{"url":"/topic/","id":"","name":"Unity（游戏引擎）"},{"url":"/topic/","id":"","name":"性能优化"},{"url":"/topic/","id":"","name":"手机游戏开发"}],"adminClosedComment":false,"href":"/api/posts/","excerptTitle":"","author":{"bio":"招网站前端、后端、引擎功能开发实习生。有意者私信我：）","isFollowing":false,"hash":"7fdb9e2544cdf169ab0bf0b1bd9e04ba","uid":498100,"isOrg":false,"slug":"zhang-xin-81-92-50","isFollowed":false,"description":"用实力让情怀落地。","name":"张鑫","profileUrl":"/people/zhang-xin-81-92-50","avatar":{"id":"v2-4e579678fdf30dc1f03b1fd9fdd412a8","template":"/{id}_{size}.jpg"},"isOrgWhiteList":false},"column":{"slug":"uwa4d","name":"UWA：简单优化、优化简单"},"content":"原文链接：上期我们聊到了UGUI的性能优化思路，本期我们来探秘NGUI。可能不少开发朋友会有疑惑，到底是NGUI还是UGUI的性能更好？小编在此想先表达下我的个人观点：从理论上来说，没有什么依据可以证明UGUI的性能一定比NGUI更优异。在UWA的测评报告中，对于NGUI来说，主要统计UIPanel.LateUpdate\\UICamera.Update\\UIRect.Update和UIRect.Start；对于UGUI来说，主要统计Canvas.BuildBatch和Canvas.SendwillRenderCanvases。相对于NGUI来看，UGUI确实在以下方面存在提升性能的可能：首先，5.2版本之后，Unity逐渐将一部分UGUI的计算放到子线程去做，以此来缓解主线程的压力；其次，UGUI的UIMesh生成是通过底层C++代码实现的，而NGUI只能通过在上层不断创建vertex list来进行，这样在堆内存的管理上，UGUI确实要好很多，带来的隐性收益就是GC触发次数会少很多。但不能表示NGUI做出来的UI性能就一定比UGUI差，这个说法是不存在的。而且，在我们深度优化的过程中发现，NGUI同样可以达到很高的性能水准。所以，NGUI和UGUI都是很好的工具，只要把它们的特性掌握好，都可以做成性能很棒的UI界面。关键字界面制作界面切换网格重建UICamera.UpdateDraw Call加载字体一、界面制作Q1：我用的是NGUI，本来已经打包图集了，输出时候是不是就不用理会那些原始2D Sprite图 ？粒子贴图需要Packing Tag吗？在NGUI中使用Atlas后，原纹理是不需要进行打包或进行其他特殊处理的，因为理论上这些资源在运行时已不再需要。粒子系统所使用的纹理并不是Sprite类型的，因此不需要设置Packing Tag。Q2：NGUI变形，如下图走样了，请问是不是图片压缩导致的？当UI纹理在设备上的显示分辨率低于原始分辨率时，会因为出现aliasing现象，导致UI局部变形。通常对于粗线条、块状的UI图素，变形通常是不明显的，但对于细线条的UI图素，则可能非常明显。通常该问题可以考虑三种方式来改善：在NGUI中将UIRoot的Scaling Style设置为Flexible，这种方式的好处在于UI纹理不会因为设备分辨率的限制而降低，而缺点在于相同的UI纹理在高分辨率设备上显得比较小，而在低分辨率设备上显得比较大，从而提高了UI布局的复杂度；将UI纹理的显示分辨率（Sprite的size属性）设定为高于原始分辨率，其缺点在于高分辨率设备上可能会产生模糊，但大多数情况下“模糊”相比于“走样”更不易察觉；开启UI纹理的Mipmap，从而在低分辨率设备上自动切换到低Level，以“模糊”替换“走样”，但缺点在于增加了纹理的大小，因此只适用于出现了明显变形的少量UI。Q3：能否在NGUI多分辨率适应方面提供一些解决方案或者思路？多分辨率适应涉及到以下几个方面：布局。通常可以通过 NGUI 中的 Anchor 组件来实现，能够保证 UI 到屏幕上指定锚点的距离；UI 背景图比例。通常我们建议将背景图的长宽比放大，以适配不同长宽比的屏幕，但要注意两边需要留空，或者保留可被裁掉的元素；UI 的整体缩放。可以通过 UIRoot 组件的 Scaling Style 来统一配置。需要提醒的是，不同类型的游戏对布局的需求通常也不同，因此还是需要结合实际开发情况来做调整。Q4：我发现ScrollRect里有大量元素，在拖动的时候触发了很多onTransformChanged，能否提供一些优化思路？OnTransformChanged是UI元素在移动时触发的，所以该回调的开销是不可避免的，但一般来说该回调本身耗时并不会太高。因此，当OnTransformChanged耗时很高时，有三种方式进行优化：可以先查看是否有哪个或者哪些子函数占比较高，比如，当OnTransformChanged触发了OnDimensionChanged时，耗时会明显升高，而OnDimensionChanged则是在开启了Canvas的Pixel Perfect时才会出现的。那么就可以考虑是否在拖动时暂时关闭Pixel Perfect。如果主要是其自身开销造成，那么很可能就是因为移动的UI元素数量太大引起的。那么就可以从策略上减少UI元素数量，比如，做成拖动翻页的界面，一次性只需移动两页的UI元素等。如果使用的是Mask组件，那么可以尝试改为Rect Mask 2D组件，同样会有性能上的提升。Q5：我看到UICamera.Update()的GC调用特别高，只要我一移动就会产生2.8K的GC，看起来是NGUITools.FindInParents这个方法导致的，有没有什么可以优化的方法呢？在 Editor 下，当调用GetComponent() 且 T组件并不在当前的GameObject 上时，确实会出现GC Alloc，但这在发布后是不会出现的，因此建议在真机上做一个验证。这是因为在Editor下，Unity的MissingComponentException实现所致，在出现以上情况时，Unity 并不是直接返回一个 NULL，而是返回一个代理 Object用来储存一些相关信息，在后续被访问时可以给出更详细的报错信息。二、网格重建Q1：我用NGUI开发，因为角色名字导致重建，使得UIPanel.LateUpdate的CPU占用很高。如果将它们分离到多个UIPanel里，是否这个开销会相对小一些？将较多的动态UI元素分组放在不同的UIPanel中确实是UWA比较推荐的方式，一方面可以降低重建的概率，某些分组中可能没有UI元素发生变化，从而不会进行重建；另一方面可以降低重建的开销。通过分组，可以将每个UIPanel所产生的Mesh控制在较小的范围内，从而控制其重建的开销（通常重建的开销会因Mesh的增大而明显升高，且不是线性的关系）。虽然这种做法会产生额外的DrawCall，但DrawCall的开销与网格重建相比通常都非常小。Q2：我的UWA报告中看到几乎每次切换场景都会有UIPanel.LateUpdate()这个函数的堆内存开销，请问说明了什么问题，我是否还能优化？UIPanel.LateUpdate持续分配较大量的堆内存，说明UI界面在制作上存在以下问题：Panel中Widgets数量过多，且存在频繁的变动，导致UIPanel需要进行大量的网格重建；动静态UI元素没有分离；建议研发团队对UI界面的制作进行进一步检测，尽可能将静态UI元素和动态UI元素分开，存放于不同的Panel下。同时，对于不同频率的动态元素也建议存放于不同的Panel中。Q3：UWA建议“尽可能将静态UI元素和频繁变化的动态UI元素分开，存放于不同的Panel下。同时，对于不同频率的动态元素也建议存放于不同的Panel中。”那么请问，如果把特效放在Panel里面，需要把特效拆到动态的里面吗？通常特效是指粒子系统，而粒子系统的渲染和UI是独立的，仅能通过Render Order来改变两者的渲染顺序，而粒子系统的变化并不会引起UI部分的重建，因此特效的放置并没有特殊的要求。三、界面切换Q1：请问这个GameObject.Active的开销怎么这么高？Activate会产生堆内存分配吗？这个是PC上的鼠标交互事件造成的，是UI界面的Active操作，所以触发了各种相关的OnEnable调用，研发团队可以在Profiler中进行进一步定位，查看根源。一般来说，GameObject的Activate操作本身是不会产生堆内存分配，但它引发的各种底层类的OnEnable会产生堆内存的分配。开发团队可以参考这里加深理解：Q2：我在Profiler中看到GameObject.Deactivate耗时较大，请问该如何优化？实际上GameObject.Activate/Deactivate本身通常不会产生很高的开销，主要都是由其上或其子节点上的组件的OnEnable/OnDisable操作引起，比如UI相关的组件在OnEnable和OnDisable中都会有较多的操作，所以较复杂的UI界面的GameObject.Activate/Deactivate会有很高的开销。因此，针对这一问题，如果是由自定义的脚本造成，那么就需要考虑优化OnEnable/OnDisable的逻辑；如果是UI，那么可以对频繁切换激活状态的UI采用平移出屏幕、修改Culling Layer等方式来替换。Q3：游戏中出现UI界面重叠，该怎么处理较好？比如当前有一个全屏显示的UI界面，点其中一个按钮会再起一个全屏界面，并把第一个UI界面盖住。我现在的做法是把被覆盖的界面 SetActive(False)，但发现后续 SetActive(True) 的时候会有 GC.Alloc 产生。这种情况下，希望既降低 Batches 又降低 GC Alloc 的话，有什么推荐的方案吗？可以尝试通过添加一个 Layer 如 OutUI， 且在 Camera 的 Culling Mask 中将其取消勾选（即不渲染该 Layer）。从而在 UI 界面切换时，直接通过修改 Canvas 的 Layer 来实现“隐藏”。但需要注意事件的屏蔽，禁用动态的 UI 元素等等。这种做法的优点在于切换时基本没有开销，也不会产生多余的 Draw Call，但缺点在于“隐藏时”依然还会有一定的持续开销（通常不太大），而其对应的 Mesh 也会始终存在于内存中（通常也不太大）。以上的方式可供参考，而性能影响依旧是需要视具体情况而定。Q4：通过移动位置来隐藏UI界面，会使得被隐藏的UIPanel继续执行更新（LateUpdate有持续开销），那么如果打开的界面比较多，CPU的持续开销是否就会超过一次SetActive所带来的开销？这确实是需要注意的，通过移动的方式“隐藏”的UI界面只适用于几个切换频率最高的界面，另外，如果“隐藏”的界面持续开销较高，可以考虑只把一部分Disable，这个可能就需要具体看界面的复杂度了。一般来说在没有UI元素变化的情况下，持续的 Update 开销是不太明显的。Q5：如图，我们在UI打开或者移动到某处的时候经常会观测到CPU上的冲激，经过进一步观察发现是因为Instantiate产生了大量的GC。想请问下Instantiate是否应该产生GC呢？我们能否通过资源制作上的调整来避免这样的GC呢？如下图，因为一次性产生若干MB的GC在直观感受上还是很可观的。准确的说这些 GC Alloc 并不是由Instantiate 直接引起的，而是因为被实例化出来的组件会进行 OnEnable 操作，而在 OnEnable 操作中产生了 GC，比如以上图中的函数为例：上图中的 Text.OnEnable 是在实例化一个 UI 界面时，UI 中的文本（即 Text 组件）进行了 OnEnable 操作，其中主要是初始化文本网格的信息（每个文字所在的网格顶点，UV，顶点色等等属性），而这些信息都是储存在数组中（即堆内存中），所以文本越多，堆内存开销越大。但这是不可避免的，只能尽量减少出现次数。因此，我们不建议通过 Instantiate/Destroy 来处理切换频繁的 UI 界面，而是通过 SetActive(true/false)，甚至是直接移动 UI 的方式，以避免反复地造成堆内存开销。四、字体Q1：对NGUI字体错乱有什么好的解决方案吗？有这么几种可能：一次展开文字太多了。这种情况在部分高通机型和Unity早期版本上都经常出现，现在也偶尔有，究其原理是FontTexture的扩容操作做得不够快或者收到了硬件驱动的限制。一般来说有两种方法可以解决：（1）减少面板中的字体内容；（2）一开始就用超大量的字体去扩容，将动态字体的FontTexture扩大到足够大；文字渲染与开发团队编写的多线程渲染发生了冲突。这种情况也常有发生，特别是通过GL.IssuePluginEvent方式来开启多线程渲染的项目，就会容易出现问题。就我们的优化经验来看，第一种情况发生的可能性比较大。Q2：我在用Profiler真机查看iPhone App时，发现第一次打开某些UI时，Font.CacheFontForText占用时间超过2s，这块主要是由什么影响的?若iPhone5在这个接口消耗2s多，是不是问题很大？这个消耗和已经生成的RenderTexture的大小有关吗？Font.CacheFontForText主要是指生成动态字体Font Texture的开销, 一次性打开UI界面中的文字越多，其开销越大。如果该项占用时间超过2s，那么确实是挺大的，这个消耗也与已经生成的Font Texture有关系。简单来说，它主要是看目前Font Texture中是否有地方可以容下接下来的文字，如果容不下才会进行一步扩大Font Texture，从而造成了性能开销。五、加载相关Q1：加载UI预制的时候，如果把特效放到预制里，会导致加载非常耗时。怎么优化这个加载时间呢？UI和特效（粒子系统）的加载开销在多数项目中都占据较高的CPU耗时。UI界面的实例化和加载耗时主要由以下几个方面构成：1. 纹理资源加载耗时UI界面加载的主要耗时开销，因为在其资源加载过程中，时常伴有大量较大分辨率的Atlas纹理加载，我们在之前的有详细讲解。对此，我们建议研发团队在美术质量允许的情况下，尽可能对UI纹理进行简化，从而加快UI界面的加载效率。2. UI网格重建耗时UI界面在实例化或Active时，往往会造成Canvas（UGUI）或Panel（NGUI）中UIDrawCall的变化，进而触发网格重建操作。当Canvas或Panel中网格量较大时，其重建开销也会随之较大。3. UI相关构造函数和初始化操作开销这部分是指UI底层类在实例化时的ctor开销，以及OnEnable和OnDisable的自身开销。上述2和3主要为引擎或插件的自身逻辑开销，因此，我们应该尽可能避免或降低这两个操作的发生频率。我们的建议如下：在内存允许的情况下，对于UI界面进行缓存。尽可能减少UI界面相关资源的重复加载以及相关类的重复初始化；根据UI界面的使用频率，使用更为合适的切换方式。比如移进移出或使用Culling Layer来实现UI界面的切换效果等，从而降低UI界面的加载耗时，提升切换的流畅度。对于特效（特别是粒子特效）来说，我们暂时并没有发现将UI界面和特效耦合在一起，其加载耗时会大于二者分别加载的耗时总和。因此，我们仅从优化粒子系统加载效率的角度来回答这个问题。粒子系统的加载开销，就目前来看，主要和其本身组件的反序列化耗时和加载数量相关。对于反序列化耗时而言，这是Unity引擎负责粒子系统的自身加载开销，开发者可以控制的空间并不大。对于加载数量，则是开发者需要密切关注的，因为在我们目前看到的项目中，不少都存在大量的粒子系统加载，有些项目的数量甚至超过1000个，如下图所示。因此，建议研发团队密切关注自身项目中粒子系统的数量使用情况。一般来说，建议我们建议粒子系统使用数量的峰值控制在400以下。Q2：我有一个UI预设，它使用了一个图集， 我在打包的时候把图集和UI一起打成了AssetBundle。我在加载生成了GameObject后立刻卸载了AssetBundle对象， 但是当我后面再销毁GameObject的时候发现图集依然存在，这是什么情况呢？这是很可能出现的。unload(false)卸载AssetBundle并不会销毁其加载的资源 ，是必须调用 Resources.UnloadUnusedAssets才行。关于AssetBundle加载的详细解释可以参考我们之前的文章：","state":"published","sourceUrl":"","pageCommentsCount":0,"canComment":false,"snapshotUrl":"","slug":,"publishedTime":"T10:56:08+08:00","url":"/p/","title":"关于Unity中的NGUI优化，你可能遇到这些问题","summary":"原文链接：上期我们聊到了UGUI的性能优化思路，本期我们来探秘NGUI。可能不少开发朋友会有疑惑，到底是NGUI还是UGUI的性能更好？小编在此想先表达下我的个人观点：从理论上来说，没有什么依据可以证明UGUI…","reviewingCommentsCount":0,"meta":{"previous":null,"next":null},"commentPermission":"anyone","commentsCount":0,"likesCount":0},"next":{"isTitleImageFullScreen":false,"rating":"none","titleImage":"/v2-f04c7ecfac9cfe23fa863_r.png","links":{"comments":"/api/posts//comments"},"topics":[{"url":"/topic/","id":"","name":"Unity（游戏引擎）"},{"url":"/topic/","id":"","name":"手机游戏开发"},{"url":"/topic/","id":"","name":"性能优化"}],"adminClosedComment":false,"href":"/api/posts/","excerptTitle":"","author":{"bio":"招网站前端、后端、引擎功能开发实习生。有意者私信我：）","isFollowing":false,"hash":"7fdb9e2544cdf169ab0bf0b1bd9e04ba","uid":498100,"isOrg":false,"slug":"zhang-xin-81-92-50","isFollowed":false,"description":"用实力让情怀落地。","name":"张鑫","profileUrl":"/people/zhang-xin-81-92-50","avatar":{"id":"v2-4e579678fdf30dc1f03b1fd9fdd412a8","template":"/{id}_{size}.jpg"},"isOrgWhiteList":false},"column":{"slug":"uwa4d","name":"UWA：简单优化、优化简单"},"content":"UWA曾经发布过MMORPG 和 ARPG 的Unity手游性能测评报告，延续该系列，最近UWA对提交测试（登陆）的所有MOBA手游进行了客观的分析和汇总，并将其具有属性特征的几大性能模块数据在此分享，希望能给相关行业的研发人员一些更为明确和建设性的意见。这是侑虎科技第160篇原创文章，欢迎转发分享，未经官方授权请勿转载。如果您有任何独到的见解或者发现也欢迎联系我们，一起探讨。（QQ群）一、总体性能MOBA游戏类型是目前所有游戏中性能最难把控（CPU开销最大）的游戏类型，在Android中低端机器上流畅运行，是当前MOBA项目最大的挑战。MOBA游戏中，同屏众多的英雄、小兵和血条HUD等，使得渲染、UI和自身逻辑代码的开销都大大高于引擎的其他系统开销；在UWA以往优化的MOBA项目中，UI优化是最为难啃的骨头。不仅数量众多，而且出现和消失时机完全随机，如何做到较为理想的动静分离，是MOBA项目中UI性能优化的关键。下面我们就来具体分析下这些主流模块的开销情况。二、主流模块性能一、渲染模块严重程度：噩梦Draw Call的主体使用范围为34~142，峰值平均为215；渲染三角面片的峰值集中在42K~291K，峰值平均为113K面。UWA推荐：渲染三角面片峰值& 100K，目前达标比例: 35.6%。不透明物体的渲染耗时平均为3.3ms，半透明物体的渲染耗时平均为6.1ms。相机后处理特效的CPU耗时主要集中在0.1~10.5 ms。小结：MOBA游戏的场景渲染三角形面片数量普遍较高，仅35.6%的项目能够将场景的渲染三角形面片数峰值控制在10w以下；半透明物体的渲染开销较高，这主要与UI界面、技能特效、野外树林和草丛量有关。建议：如果渲染面片数过高，则优化可从两方面入手，一是对场景模型、英雄小兵模型尝试进行网格简化，二是对中低端机器上渲染Shader进行简化，尽可能做到单Pass渲染；2.如果是UI HUD开销很高（比如CreateVBO较高等），则需要对UI系统进行优化，具体可见UWA之前的、文章和PPT对UI模块进行完善（可以参考UWA公众号的历史推送：uwatech 或者UWA博客：）。二、UI模块严重程度：地狱使用NGUI作为UI解决方案的项目占据了相当高的比例，NGUI目前仍然是研发团队对于UI系统使用的主要解决方案；UI模块的性能开销很高，将近74%的研发团队都面临较为严重的性能问题；建议研发团队根据UWA之前的、文章和PPT对UI模块进行完善（可以参考UWA公众号的历史推送或者UWA博客：）。三、逻辑代码严重程度：地狱GC触发频率很高，是造成卡顿的主要原因之一；90%以上的游戏团队需要对GC的调用进行进一步规划，对代码的堆内存分配进行大力优化。Instantiate实例化操作平均每次调用的CPU耗时主要分布在: 1.6~64.4 ms，均值为6.9ms，每1万帧总调用次数主要分布在: 55~5452 次；Instantiate的频繁实例化是太多数研发团队非常容易忽视的问题。Log输出操作平均每次调用的CPU耗时主要分布在: 4.0~114.0 ms，均值为13.7 ms。Shader解析操作平均每次调用的CPU耗时主要分布在: 19.4~257.9 ms，均值为66.8ms；Shader解析时间较高，且大多数情况是相同Shader的重复开销，值得研发团队密切关注。四、粒子系统严重程度：地狱五、动画模块严重程度：噩梦目前仅使用Mecanim动画系统的MOBA游戏项目占比为58.9%，仅使用Unity 3.x老版本动画系统的占比为4.1%，两种系统混合使用的占比为37.0%。小结：MOBA类型的动画模块开销是目前所有游戏类型中CPU开销最高的，ARPG可以根据设定好的剧情分布加载和卸载，MMORPG可以根据玩家的位置来动态加载，但MOBA是允许玩家根据小地图快速切屏的，所以以上方式均不适用。经过统计，MOBA游戏中一场5V5战斗基本上需要保证90-110个Skinned Mesh在不停进行动画和蒙皮计算，这是动画系统开销如此高的原因之一。建议：根据场景中角色位置或者视域体范围，对场景中的英雄、小兵和炮塔等需要进行动画计算的GameObject进行分级控制，比如Disable其Animator组件等；开启Optimize Game Objects选项，一切策划需求为其让路；善用缓存池，尽可能避免如下图中Animator.Initialize的频繁耗时。三、内存模块目前MOBA项目中的内存占用普遍较高，但泄露问题的占比仅为23.3%，大幅低于其他游戏类型游戏。总体内存严重程度：地狱总体堆内存严重程度：地狱纹理资源严重程度：地狱Mesh资源严重程度：地狱RenderTexture资源严重程度：噩梦字体资源严重程度：普通Shader资源严重程度：地狱动画资源严重程度：地狱音频资源严重程度：普通希望以上数据能给大家的开发提供帮助。之后我们将不断与大家分享其他类型的数据，如ACT，SLG等。我们深信数据是会说话的，总有规律值得我们追溯求实、鉴往知来。同时我们也会不断细化评析的标准、划分，以使得这些数据更有代表性和说服力。","state":"published","sourceUrl":"","pageCommentsCount":0,"canComment":false,"snapshotUrl":"","slug":,"publishedTime":"T12:52:36+08:00","url":"/p/","title":"UWA 发布| MOBA移动游戏性能分析报告：渲染、UI和逻辑代码是性能头号杀手！","summary":"UWA曾经发布过MMORPG 和 ARPG 的Unity手游性能测评报告，延续该系列，最近UWA对提交测试（登陆）的所有MOBA手游进行了客观的分析和汇总，并将其具有属性特征的几大性能模块数据在此分享，希望能给相关行业的研发人员一些更为明确和建设性的意…","reviewingCommentsCount":0,"meta":{"previous":null,"next":null},"commentPermission":"anyone","commentsCount":0,"likesCount":0}},"annotationDetail":null,"commentsCount":6,"likesCount":39,"FULLINFO":true}},"User":{"zhang-xin-81-92-50":{"isFollowed":false,"name":"张鑫","headline":"用实力让情怀落地。","avatarUrl":"/v2-4e579678fdf30dc1f03b1fd9fdd412a8_s.jpg","isFollowing":false,"type":"people","slug":"zhang-xin-81-92-50","bio":"招网站前端、后端、引擎功能开发实习生。有意者私信我：）","hash":"7fdb9e2544cdf169ab0bf0b1bd9e04ba","uid":498100,"isOrg":false,"description":"用实力让情怀落地。","profileUrl":"/people/zhang-xin-81-92-50","avatar":{"id":"v2-4e579678fdf30dc1f03b1fd9fdd412a8","template":"/{id}_{size}.jpg"},"isOrgWhiteList":false,"badge":{"identity":null,"bestAnswerer":null}}},"Comment":{},"favlists":{}},"me":{},"global":{},"columns":{"uwa4d":{"following":false,"canManage":false,"href":"/api/columns/uwa4d","name":"UWA：简单优化、优化简单","creator":{"slug":"zhang-xin-81-92-50"},"url":"/uwa4d","slug":"uwa4d","avatar":{"id":"4fecf539d0fcfce34c4b","template":"/{id}_{size}.jpeg"}}},"columnPosts":{},"postComments":{},"postReviewComments":{"comments":[],"newComments":[],"hasMore":true},"favlistsByUser":{},"favlistRelations":{},"promotions":{},"switches":{"couldAddVideo":false},"draft":{"titleImage":"","titleImageSize":{},"isTitleImageFullScreen":false,"canTitleImageFullScreen":false,"title":"","titleImageUploading":false,"error":"","content":"","draftLoading":false,"globalLoading":false,"pendingVideo":{"resource":null,"error":null}},"config":{"userNotBindPhoneTipString":{}},"recommendPosts":{"articleRecommendations":[],"columnRecommendations":[]},"env":{"isAppView":false,"appViewConfig":{"content_padding_top":128,"content_padding_bottom":56,"content_padding_left":16,"content_padding_right":16,"title_font_size":22,"body_font_size":16,"is_dark_theme":false,"can_auto_load_image":true,"app_info":"OS=iOS"},"isApp":false},"sys":{}}}