技术分享连载（一）

本期话题：Texture占用内存总是双倍、影响Overhead的因素、Reserved Total 和 Used Total之间的关系、纹理Atlas的合成建议、Unity升级后是否需要修改粒子的设置...

上周，我们推出了UWA性能诊断与优化工具，并收到了一些开发者朋友的积极反馈。在UWA的QQ讨论群里，大家不仅对产品各抒己见，对各自项目开发中遇到的问题也群策群力。如果你也是个热爱分享、愿与大家抱团进步的程序员，欢迎加入UWA的QQ群：793972859，与我们奇文分享，疑义相析。

今天，我们整理了几个上周大家讨论比较激烈的问题，分享给大家：

---

Q1：Texture占用内存总是双倍，这个是我们自己的问题，还是Unity引擎的机制？

出现这种情况的原因有两种：一种是你在真机运行时开启了Read&Write。另一种可能是Unity的Bug，目前的Unity 5.2.3 release note如下 ：
(735644) - OpenGL: Fixed texture memory usage reporting in profiler, was twice the actual size for most textures.
开发者需要关注下自己的开发版本，5.2.3以前类似情况的项目可以参考一下。

---

Q2：我现在发现两个因素直接影响Overhead，一个是Shader的复杂度，一个是空Update方法及其同类空方法，不知道是否还有其他因素？

Overhead的计算方法是：Profiler当前帧统计的总耗时时间减去所有已知选项的累加时间，即引擎当前还无法识别模块的耗时时间。Overhead数值理论上是趋向于0的，但是由于目前市面上的硬件设备、系统框架过于丰富，所以引擎可能无法识别所有模块的CPU开销。
就我们目前遇到的大部分案例而言，Overhead数值较高一般是由硬件设备的垂直同步算法无法识别而引起的。所以，一般情况下，Overhead的数值其实并不需要开发者特别关注。
在UWA的性能分析中，我们并没有将Overhead计算在内，一方面是其本身数据的统计意义对目前大多数项目的性能优化帮助不大，另一方面是即便知道了它的CPU数值，也无法知道到底是哪些地方引起的，上层很难有针对性地进行优化。
当然，我们会持续对Overhead进行实验和研究，分析其CPU耗时规律、与已知选项的关联性等。后续有任何相关发现，我们都会总结成文，及时分享给大家。

---

Q3：在Unity的内存管理机制中, Reserved Total 和 Used Total之间的关系是怎样的？

Reserved Total 和 Used Total为Unity引擎在内存方面的总体分配量和总体使用量。 一般来说，引擎在分配内存时并不是向操作系统 “即拿即用”，而是首先获取一定量的连续内存，然后供自己内部使用，待空余内存不够时，引擎才会向系统再次申请一定量的连续内存进行使用。所以，从图表中可以看到，Reserved Total 的内存占用量略大于 Used Total， 且两者走势基本一致。

注意：对于绝大多数平台而言，Reseved Total内存 = Reserved Unity内存 + GFX内存 + FMOD内存 + Mono内存。（关于Unity的内存管理机制，请“阅读原文”跳转至“UWA文档”了解更多。同时，我们也会在以后的推送中开设内存专题，欢迎关注！）

---

Q4：纹理Atlas是建议合成一张2048（尺寸）的纹理还是四张1024的纹理？

在其他设置一致的情况下，这两种方式无论在加载还是渲染方面其实并没有实质上的差别。在我们接触到的大多数案例中，纹理资源方面的问题除了尺寸外，纹理格式、Mipmap设置和Read&Write功能同样是需要研发团队时刻关注的。

---

Q5：在把Unity升级到5.3之后，项目中缓存的粒子特效无法正常播放了（只能播放一次），是否还需要修改粒子的设置呢？

这个问题是Unity的Bug，5.4.0B3 release note 为：

Particles: Fixed particle system only playing once.（会在新版本5.4修复）

目前我们推荐通过另一种方法可以暂时绕过该 Bug：

particleSystem.Stop(); 
particleSystem.Clear(); 
particleSystem.Simulate(0.02f); 
particleSystem.Play();