内容简介：这是第141篇UWA技术知识分享的推送。今天我们继续为大家精选了若干和开发、优化相关的问题，建议阅读时间10分钟，认真读完必有收获。UWA 问答社区：answer.uwa4d.comUWA QQ群2：793972859（原群已满员）
这是第141篇UWA技术知识分享的推送。今天我们继续为大家精选了若干和开发、优化相关的问题，建议阅读时间10分钟，认真读完必有收获。
UWA 问答社区：answer.uwa4d.com
UWA QQ群2：793972859（原群已满员）
本期目录：
- Camera.Render耗时瓶颈定位
- 特效片段较多，如何打包更合理
- AssetBundle打包粒度规划
- 一次疑似内存泄漏的排查记录
- Shader代码中提前声明变量对性能的影响
渲染
Q：我想问下，我们测试报告中的Camera.Render耗时特别大，请问是为什么呢？测试机型：红米2，具体的情况如下：
总体CPU耗时趋势
第3380帧的堆栈
Drawing消耗
Culling消耗
其他函数消耗
本人之前没有这方面优化经验，有没有大佬能指点分析下从具体堆栈信息能看出来哪些问题。PS：相机有点多，场景一个相机，每个UI一个相机这样。
UWA: Camera.Render耗时高建议先看一下DrawCall和Triangle的统计，红米2这样的低端机上还是建议控制到150个DrawCall和10W渲染面以下的。
如果以上两个指标都比较合理了，建议可以再提测一个没有开启多线程渲染的包，因为看截图里的报告应该是一个开启了多线程渲染的包，真实开销发生在渲染线程，主线程的Camera.Render里的耗时都集中在RenderLoopJob上了，看不出细节（比如蒙皮、粒子、UI）的耗时分配。
补充一下，从性能堆栈中可以看出，题主应该是在红米2设备上开启了相机的实时阴影，这个功能不太建议在低端设备上（比如红米2）上进行开启，建议尝试通过其他方法来进行替代。可以阅读以下文章进行完善：
资源管理
Q：AssetBundle包粒度打的粗细对加载时间影响大吗？我想把一些小资源单独打成依赖包，不知道依赖包打太细会不会让加载变慢？
A1：简单地讲，就是如果粒度过粗，单个AssetBundle加载时间过长，可能会影响到游戏体验。粒度细的话，好处是多个资源可以同时加载，减少资源加载时间；但过细的麻烦是资源管理会更繁琐，另外也需要更多次的IO来加载，这也是个小消耗。所以根据项目选取合适的粒度，我见过比较多的项目以1MB为参考。
感谢赵林@UWA问答社区提供了回答
A2：我们做法如下：
1）我们进行AssetBundle打包前一定要做的就是依赖分析，分析出依赖树，依据依赖树进行AssetBundle打包，这样避免资源冗余;
2）主要的打包规则分成两部分：
- 整体打包规则：Root节点作为AssetBundle包的Mainasset（例如Prefab、Scene、tex等），共用资源单独打包，非共用资源和root节点打到一起
- 一些特殊资源打包时进行整合，例如Shader
3）进行测试分析，很多时候资源的使用率决定我们打包规则，系统、战斗、大世界等等都会影响，这是我们要统计资源的使用率和使用情况，进行资源合并，将很多我们已有的Root节点进行合并打包，降低AssetBundle包的数量，提高加载速度，但是会增加更新资源的AssetBundle包大小，更新一些非更新资源。
如果使用LZ4压缩格式，LoadfromFile，只会加载头文件，具体Load资源时才会加载，这样的好处是，我们可以将多资源打入同一个AssetBundle，提高加载速度。资源打散的好处是，在大量资源时我们就不会加载很多无用的资源。
PSS的问题，主要集中在降低加载资源峰值：
1）当有大量资源需要加载时，进行资源依赖分析，对资源及AssetBundle进行排序，增加AssetBundle包复用率；
2）分帧加载，在Loading时提前进行GC，降低多资源，同一帧进行加载及实例化产生的内存峰值。
感谢郑骁@UWA问答社区提供了回答
资源管理
Q：我们的特效片段比较多，比较碎且复用频繁，大家有什么好办法打AssetBundle包？我们特效图片都放在一个目录，和美术沟通完他们所有的图片理论上都是复用的，就是一张图被几个特效用还是被几十个特效用到的差别。目前我们特效贴图没有单独打AssetBundle，冗余严重。如果每张贴图单独打AssetBundle，又怕AssetBundle太碎，导致IO多，加载时间长，SerializedFile文件多等问题。
A：我们现在是这样做的：
特效Prefab按UI，场景，战斗等分类，写个 工具 来分类特效资源：
1）如果某个资源被UI特效用了，同时又被场景特效用了，就把这个资源标记为Common资源。
2）如果某个资源只是被UI特效用了，那就只是UI特效资源。
也可以添加其他的规则。
另外UI，场景，战斗中的分类可以再细分，工具可以先根据大类筛选，然后按细分的子类继续筛选。甚至可以按每个Prefab来整理资源。
内存
Q：我们用了一个插件USquencer用来播放相机动画（这个问题可能跟插件无关），在过完新后进大世界前，播放了太多相机动画，导致全播放完后在Unity的Memory Profiler中的Assets/MonoBehaviour中显示月一万多个USquencer相关的脚本。
我尝试了各种办法去理解它，但始终理解不了。
我简化了这个复杂的播放过程：
其实只是从AssetBundle加载了一个Prefab，然后用它实例化一个对象，再销毁对象，最后释放资源和引用。但仅仅是这样，也会有引用导致它释放不掉。引用看不懂，也理解不了它。
我们目前只能确定不是以下原因导致的引用无法释放：
1）Profiler采样前，已经确定调用了释放无用资源的接口（unloadXXX），并不是没有释放Asset导致的；
2）实例化的GameObject确实已经销毁了，这些脚本在Scene视图是找不到的；
3）在编辑器我们跑的AssetBundle资源，跟在真机上效果一样，不是编辑器导致的“假泄漏”（用这种方式，我们已经成功解决了很多Texture的泄漏）；
4）我没有用原生最底层Unity提供的代码去简化这个例子，那样似乎得写好多复杂的代码。我们封装好的应该没啥问题，毕竟已经解决了其他好多资源的泄漏；
其实不仅是MonoBehaviour，Transform和GameObject等都有大量残留。Texture的泄漏大家都比较重视，也好解决，但MonoBehaviour等的泄漏就完全没有思路了，不知道从哪开始研究。我现在只能猜测，因为它是Assets下的资源。
UWA： 如果GameObject销毁了，但其Component仍然在不断存在，且不断上升，很有可能是你的的 Lua 导致了泄露。建议通过UWA GOT Online去查一下你的Lua堆内存，看其内存是不是在不断上升，以及其Mono对象是否在不断增加。
新功能！Lua，是时候和你走走心了！题主补充： 找到原因了，我只调用了UnLoad资源，没有调用Lua的GC导致。
Shader
Q：求问Shader代码中提前声明变量会不会影响效率？
例如
1 half3 lightPos = _WorldSpaceLightPos0.xyz; 2 o.diff = v.color * max(0, dot(o.worldNormal, lightPos)); 3 o.lightDir = dot(o.worldNormal, normalize(lightPos + o.worldViewDir));
和另一种写法：
1 o.diff = v.color * max(0, dot(o.worldNormal, _WorldSpaceLightPos0.xyz)); 2 o.lightDir = dot(o.worldNormal, normalize(_WorldSpaceLightPos0.xyz + o.worldViewDir));
第二个版本是否更耗时？
UWA： 不会，实际上两个版本经过编译以后的代码是一样的，题主可以通过Inspector里面的Show Generated Code按钮查看编译后的代码。编译器会帮我们做一些优化工作。
今天的分享就到这里。当然，生有涯而知无涯。在漫漫的开发周期中，您看到的这些问题也许都只是冰山一角，我们早已在UWA问答网站上准备了更多的技术话题等你一起来探索和分享。欢迎热爱进步的你加入，也许你的方法恰能解别人的燃眉之急；而他山之“石”，也能攻你之“玉”。
官网：www.uwa4d.com
官方技术博客：blog.uwa4d.com
官方问答社区：answer.uwa4d.com
官方技术QQ群：793972859（原群已满员）
以上就是本文的全部内容，希望本文的内容对大家的学习或者工作能带来一定的帮助，也希望大家多多支持 码农网
猜你喜欢:
本站部分资源来源于网络，本站转载出于传递更多信息之目的，版权归原作者或者来源机构所有，如转载稿涉及版权问题，请联系我们。
Google软件测试之道
James A. Whittaker、Jason Arbon、Jeff Carollo / 黄利、李中杰、薛明 / 人民邮电出版社 / 2013-10 / 59.00元
每天，google都要测试和发布数百万个源文件、亿万行的代码。数以亿计的构建动作会触发几百万次的自动化测试，并在好几十万个浏览器实例上执行。面对这些看似不可能完成的任务，谷歌是如何测试的呢？ 《google软件测试之道》从内部视角告诉你这个世界上知名的互联网公司是如何应对21世纪软件测试的独特挑战的。《google软件测试之道》抓住了google做测试的本质，抓住了google测试这个时代最......一起来看看 《Google软件测试之道》 这本书的介绍吧!
