技术分享连载（五十一）

本期话题：为什么Deep Profiler的数据不精准、UGUI文字花屏怎么解决、如何动态修改SkinnedMeshRederer中的Mesh、为什么要严格控制实例化材质...

---

精选5个性能优化问题，建议阅读时间15分钟，认真读完必有收获。如果您有任何独到的见解或者发现也欢迎联系我们，一起探讨。

UWA QQ群：793972859

---

内存管理

Q1：我最近用Deep Profiler发现项目里有一个直接调用Color != Color的接口耗时很高，而且百分比也很高（不管是Self还是Total）。但是如果用Profiler.BeginSample显示时，其耗时又很低，百分比也很低几乎等于0。这样的情况下是Deep Profiler出问题了吗？

针对上图具体例子来看，Deep Profiler中RoleRender_ChangeColor.get_running的CPU开销虽然较高，但其参考意义不大。因为不开Deep Profiler模式，此处开销是不会这么高的。这是因为，图中的开销实际上是操作了200次循环且获取时间戳的开销，也就是说，当循环或者操作大量次数时，Deep Profiler模式中本身统计耗时操作的时间占比很大，所以此处反馈的时间其实并不是研发团队想看到的真正代码耗时。这也是为何很多团队反馈Deep Profiler统计不算准确的原因。

---

内存管理

Q2：Unity中修改了Material的一个属性后，该Object就会单独实例化出一个Material，所以它就不能被动态Batching了，是这样吗？

是的，所以我们在Material使用详情中对内存中驻留的Material进行了详细的检测和分析，如下图所示。

图中后缀为（Instance）的材质均为修改材质属性而生成的临时材质，对于这种情况，我们建议研发团队应严格将Instance材质数量控制在尽可能小（<10）的范围内，而对于过高数量的Instance材质，建议研发团队考虑是否可以通过动态更换Material的方式来代替修改材质属性的方式，从而来减少不必要的Instance材质，进而提升物体动态合批的几率。

---

UI 输入

Q3：对于UGUI文字花屏问题，有什么推荐的解决方法吗？

对于UGUI字体花屏的现象， 很有可能是字体的UV不准确导致。对此，我们推荐两篇博文，大家可以通过其中的具体做法来进行解决。

1. 关于UGUI字体花屏和乱码：http://www.cnblogs.com/yaukey/p/unity_ugui_font_texture_uv_wrong.html

2. UGUI研究院之Text字体花屏（二十二）：http://www.xuanyusong.com/archives/4259

---

其他

Q4：SkinnedMeshRenderer的Mesh是不是不能动态修改？属性里只开放了SharedMesh。

如果需要动态修改 SkinnedMeshRender 对应的 Mesh，则可以通过读写 SharedMesh 来实现，类似于 MeshFilter.sharedMesh 的用法，参见：
https://docs.unity3d.com/ScriptReference/MeshFilter-sharedMesh.html

但文档中的例子会修改原 Mesh，如果不想改动原 Mesh，那么则可以先通过 new Mesh 或者 Instantiate 来拷贝一份后，再修改并给 SharedMesh 赋值。在 UWA 的 Blog 中有一篇介绍动态合并多个 SkinnedMeshRender 的文章，其中则是通过 new Mesh 来做合并，最终赋给SharedMesh，可作参考：http://blog.uwa4d.com/archives/avartar.html

---

粒子系统

Q5：粒子系统里面使用到的模型，是不是读写开关必须要打开，否则会崩溃？

在Unity 5.3早期的版本中，我们确实收到过类似的反馈，在某些特效上使用了没有设置 Readable 的 Mesh 时就会触发崩溃，且在崩溃日志中会出现ParticleSystemRenderer::UpdateCachedMesh的堆栈。但目前我们在较新的版本上（例如4.7.2，5.3.5 等版本）进行了各种情况的测试后，尚未复现出这一现象。因此，我们建议研发团队可以尝试关闭 Readable选项。

今天的分享就到这里。也欢迎热爱进步的你加入UWA的QQ群（793972859），也许你的方法恰能解别人的燃眉之急；而他山之“石”，也能攻你之“玉”。 比起闭门造车，我们更乐意与大家各抒己见，畅所欲言；比起形而上的泛泛而谈，我们更乐意与大家直击痛点，对症下药。