优化为什么一定要关注Render.Mesh？
- 作者：admin
- /
- 时间：2018年03月12日
- /
- 浏览：5861 次
- /
- 分类：厚积薄发
本期聚集话题：Render.Mesh耗时剖析、PSS走势详解、合理优化RenderTexture、排查没有依赖的插件资源等，都是非常实用的技巧哦~
这是第102篇UWA技术知识分享的推送。今天我们继续为大家精选了若干和开发、优化相关的问题，建议阅读时间15分钟，认真读完必有收获。文末，我们的互动话题是，AssetBundle Diff Patch 方案是否可行？期待你的高见！
UWA 问答社区：answer.uwa4d.com
UWA QQ群：793972859（仅限技术交流）
渲染
Q1：可否解释下不透明渲染中，BatchRenderer.Flush中的Render.Mesh代表什么意思，我看在我的报告中一直都很高。这个数据算正常吗？
UWA：这个问题正好可以解释一下Flush下的这些显示项含义。BatchRenderer.Flush其实就是引擎要对当前这一帧进行渲染时的CPU端开销。一般来说，都是先Batch Draw Call，然后就可以调用Ogl相关代码分批次将数据传输到GPU端进行渲染了。
这里根据项目的不同主要会出现三个显示项：Batch.DrawStatic、Batch.DrawDynamic和Render.Mesh。其中DrawStatic表示当前帧同通过Static Batching的Mesh的Draw Call统计耗时。相应的，DrawDynamic则为Dynamic Batching相关耗时。而Render.Mesh则为无法进行Draw Call Batching的统计耗时。
题主提供的信息中，可以看出是Render.Mesh的Draw Call为42，而CPU耗时为8.27ms，坦白说，对于42个Draw Call来说，该值属于偏高了。但具体原因，但这份表格是无法获悉到的。对此，UWA的建议如下：
（1）题主需点击“Render.Mesh”查看其在整体测试中的CPU耗时走势，如果只是单一几帧出现零星高值，则不用过于担心，因为任何统计都不免出现“奇异值”；
（2）但如果是普遍、持续的高耗时，那么就必须严肃对待了。可以通过报告中的图表查看出现高CPU耗时时的具体位置，然后有针对性地进行更为深入的分析，比如使用Unity Frame Debugger，重点查看到底会有哪些无法Batch的Draw Call，是否合理等；
（3）通过第（2）步，你应该可以了解了一些无法进行Batch的模型，然后可以进行一些二分法来逐步定位到底哪些模型对其耗时影响最大，直到排查到问题为止。
当然，还有一个高效的方法，就是把项目抠一个可复现问题的Sample出来，然后发给我们。我们每天都在帮助深度客户来解决问题，一些典型问题我们会以专栏的方式放出来，具体可以看求知探新。
该回答由UWA提供，欢迎大家转至社区进行进一步交流：
https://answer.uwa4d.com/question/5aa15dbfd35eb22c10a0a372
资源管理
Q2：我们用的是Unity 2017.3，游戏工程删除Resources文件夹和所有Scene后出的空包非常大，检查发现使用的插件包含比较多的图片导致。但是那些资源没有地方引用，怎么会打进包里呢？如果全部删除的话在开发的时候不方便，所以请问有没有办法在出包是剔除没有用的资源？
配图：
题主可以自己修改下插件，把资源放到”Editor Default Resources”或者”Editor/Resources”下，不要直接放Resources下，反正根据打包日志慢慢把这些插件的清理干净就好，体力活。
PS. 在Unity 5.4之前(大概是这个版本，具体要查Changelog) ，Editor下的Resources也会被打包进来的，后来就修掉了。
感谢UWA问答社区 @钱康来 提供了回答，欢迎大家转至社区进行进一步交流：
https://answer.uwa4d.com/question/5a97b0330b827e2c0bfdd06b
资源管理
Q3：对于RenderTexture的优化一直比较迷茫，貌似和分辨率和AA关系比较大，上图是相关的设置图，我想请教下。
1）这个分辨率的设定一般怎么比较合理？1440×2560是不是有点高了？
2）AA的设置一般是None吧？看大家说在移动设备上一般不需要开启这个效果，是吗？
3）Color Format一般选什么格式呢？ARGB32的比较高清，那是否也会占据大量的内存？
4）这个参数设置图中是否还会有其他因素也造成RT较高？
下图是我们的资源详情图，希望能给些分析建议，谢谢！
1）RT分辨率的设置取决于这张RT是做什么使用的。一般RT的大小为屏幕尺寸大小，也就是screen.width和screen.height，而screen的尺寸，一般由于性能问题，我们会限制为720p或者1080p，这样的话1440*2560肯定是超大了。
即便如此还不够，因为如果这个RT是为了bloom等效果，那么downsample的方式，也就是说尺寸为screen.width/2甚至screen.width/4。
2）AA的设置一般建议要设置为None的，AA在移动端太耗了。
3）格式设置为ARGB32问题倒不大，主要是尺寸限制好了，大小就小很多了。
4）Depth Buffer也会影响RT的大小。大部分RT实现的效果都不需要Depth Buffer，所以还是要看题主的RT是用来实现什么效果。如果不用Depth Buffer，比如图中的第2个RT应该就没开Depth Buffer吧。一张14402560的RT也不超过144025632/(10241024* 8)=14MB，当然14MB也很夸张了...还是需要降低尺寸。
感谢UWA问答社区 @王烁 提供了回答，欢迎大家转至社区进行进一步交流：
https://answer.uwa4d.com/question/5a9e050a0b827e2c0bfdd0d4
内存管理
Q4：上图是三星S6上的数据，PSS比Reserved Total还小，而且升降很不一致。这个是正常的吗？我看在小米5s上倒是正常的。
三星S6：
小米5s：
UWA：上述两张都是对的，因为都是通过系统API来获取的数值。之所以在不同机型上会出现差异，在我们来看主要是统计的内容不同。在我们测试过的大部分Android设备中，PSS是会将GPU所用的一些显存统计进去的，但会有一些机型除外，三星S6就属于这样的设备。所以，就会出现类似上述的现象。
OS版本不同、设备不同，其统计的PSS也都是不尽相同的。PSS是统计设备内存使用情况的一个指标，但对于内存优化来说，意义不大，我们建议还是以Profiler中的Memory数值为准。
该回答由UWA提供，欢迎大家转至社区进行进一步交流：
https://answer.uwa4d.com/question/5aa161ea0b827e2c0bfdd0fc
今天的分享就到这里。当然，生有涯而知无涯。在漫漫的开发周期中，您看到的这些问答也许都只是冰山一角，像这样实用的知识点在UWA问答平台（answer.uwa4d.com）上还有一打！UWA欢迎热爱进步的你加入，也许你的方法恰能解别人的燃眉之急；而他山之“石”，也能攻你之“玉”。
互动话题
AssetBundle Diff Patch 方案是否可行？
除了比对AssetBundle文件的hash值直接替换整个AssetBundle和manifest来达到更新效果的目的，有没有其它方案类似diff patch，可以减小更新包体？如果可以做diff patch，资源颗粒度是不是就可以忽略了？
