拖公司的福，有幸去了一趟北京参加了一场Unity3D的交流盛宴，在为期两天的时间内，不仅有着技术上收获，也有心灵上的震撼。现在先来说说技术方面的一些比较重要的知识，但是会跳过Unity3D后续版本的一些新功能介绍，比如新的GUI、动画系统的加强、以及新的AssetBundle打包工具。因为等之后版本出来后，自然会有更加详细的文档以及说明出来。
项目开发、管理和发布策略
四大准则
- 准则一：美术资源量对于程序发布包大小、性能优化、内存占用量的影响，往往超过其他各种因素
- 技术美术和关卡设计师对于游戏性能承担着非常重要的责任
- 程序员往往无法补救由于滥用美术资源而造成的性能问题
- 准则二：项目团队应该通过编写工具来保证美术资源的合法性
- 美术规范文档无法在实际上保证美术资源的合法性
- 程序员应该通过Unity编辑器扩展技术，为美术师实现完整的美术资源合法性检查工具
- 准则三：对渲染效率和内存占用的优化应该在项目实施过程中反复进行
- 针对CPU端/游戏逻辑的优化往往能够比针过GPU端/Shader的优化取得更大的作用
- GPU/Shader的性能优化应该放在最后进行
- 善用Unity Profilers (这点非常重要，后面会有对这个功能的详细讲解)
- 准则四：从反向工程的角度理解项目开发，以最终需要达到的目的来决定程序的架构设计以及关键技术的方案选择
- 是否需要进行代码的增量更新
- 是否需要严格控制程序发布包的大小
- 是否需要支持低端移动设备等等
Mipmaps
-
凡是3D场景，都应该尽可能启用MipMaps
耗费内存，提升CPU
硬件分级策略
- 为什么进行分级
- 移动GPU之间的性能差距可能高达10倍以上
- 效率和效果之间永远存在着矛盾
- 怎么分级
- Resolution分辨率
- Post-processing 后期特效
- MSAA 反锯齿
- Anisotropy 异向纹理
- Shaders
- Fx/particles density, on/off 粒子发射器的数量、密度。单人和多人的不同处理
初级内存管理策略
一个游戏可以使用的内存容量简单的可以理解为：可用内存为整个内存的%50。比如512M的内在可以使用256M。
- 控制贴图大小
- 选择合适的压缩格式
- PVRTC，DXT，ATC，ETC
- 使用Prefabs
- 用好AssetBundles
- 编写自己的ObjectPool和LoadManager
- 通过对象池来避免内存的频繁操作，从而避免内存碎片影响到大内存块的申请;切换场景时不释放公共的UI资源
- 通过LoadManager，保证在同一时间段内公载入一个www对象，实现顺序加载
AssetBundle
老的AssetBundle打包的时候有比较多的弊端，依赖打包的时候很麻烦。一个包改变了，相关联的包都要重新打一次包，这个过程会严重的影响开发效率。这个问题在Unity 5.0会得到解决
AssetBundle的效率比Resources效率要低。这是没办法的事
Profiler 性能分析器
Unity3D提供了一个非常强大、非常易于使用的性能分析器，在平常的使用过程中或多或少都会碰到一些搞不明白的地方，这一次官方给了一个比较详细的解答。一些简单的功能就不在此介绍了，一看就懂。
重要的参数指标：
-
GC Alloc
记录了游戏运行时代码产生的堆内存分配，这是一个非常重要的参数，甚至比Time更加重要。ManagedHeap的增大，会加速GC回收的到过。如果这个参数有一个比较高的值或者出现在每一帧中，那么就要引起重视。以下是一些不太引起注意的地方引起的GC分配：
- GameObject.GetComponet()会引起GC的分配
- 尽量缓存组件
- Object.get_name()
- 如果每一帧都需要比较，可以缓存名字
- foreach循环
- 每次foreach会产生一个enumerator
- 尽可能避免使用LINQ
- 部分功能无法在某些平台上使用
- 会分配大量GC Alloc
- 协程Coroutine
- 开启一个协程，至少分配373的内存
-
String连接
- 使用StringBuilder或String.Format来代替而不是用”+”来进行连接
关注原则：
检测任何一次性内存分配大于2KB的选项
- 检测每帧都具有20B以上内存分配的选项
- GameObject.GetComponet()会引起GC的分配
-
Time
记录了游戏运行时的每帧cpu战胜。当然是越小越好，如果占用过大那就找原因吧。
-
CPU Usage
- WaitForTargetFPS
- vSync功能所致或者帧数限制
- Overhead
- 所有无法统计的时间总和，理论值应该为0.
- Physics.Simulate
- 物理模拟占用的CPU
- Camera.Render
- 相机渲染准备工作的CPU占用量
- RenderTexture.SetActive 设置RenderTexture操作（和相机数一致）
- 比对当前帧与前一帧的ColorSurface和DepthSurface
- 如果一致则不生成新的RT, 否则则生成新的RT，并设置与之相对应的Viewport和空间转换矩阵
- GUI.Repaint
- GUI的重绘，使用的Unity3D自带的GUI，极度不推荐使用
-
Cleanup Unused Cached Data
清空无用的缓存数据，主要包括RenderBuffer的垃圾回收和TextRendering的垃圾回收
-
RenderTexture.GarbageCollectTemporary
存在于RenderBuffer的垃圾回收中，清楚临时的FreeTexture
-
TextRendering.Cleanup
TextMesh的垃圾回收操作
-
-
Application.Integrate Assets in Background
遍历预加载的线程队列并完成加载，同时，完成纹理的加载、Substance的Update等。主要是加载场景的时候会用到，多线程加载
-
AssetBundle.LoadAsyncIntegrate
多线程加载AssetBundle的资源
-
Loading.AwakeFromLoad
在资源加载时会用到，对每种资源进行处理
- WaitForTargetFPS
-
GPU Usage
-
Mesh.DrawVBO
GPU中关于Mesh的Vertex Buffer Object的渲染耗时
-
Shader.Parse
资源加入后引擎对Shader的解析过程
-
Shader.CreateGPUProgram
根据当前设备支持的图开库信息来建立GPU工程
-
-
Profiler需要时刻关注的参数
- CPU—GC Alloc
- CPU—Time
-
MemoryProfiler—Other
-
ManagedHeap.UsedSize
移动游戏建议不超过20M
-
WebStream
通过WWW加载留下的东西，一般会比SerializedFile大得多。包括压缩和解压的东西
-
SerializedFile
通过WWW等方式加载本地的AssetBundle的留下的序列化文件，看是否被卸载掉
-
- MemoryProfiler—Assets
- 查看是否有重复的资源
- Device.Present
- GPU的Presentdevice确实非常耗时，一般出现在使用了非常复杂的Shader等；
- GPU运行的非常快，而由于Vsync的原因，使得它需要等待较长时间;
- 同样是VSync的原因，但其他线程非常耗时，所以导致该项等待时间很长，比如过量的assetbundle加载时容易出现该问题
- Shader.CreateGPUProgram
-
StackTraceUtility.PostprocessStackTrace() StackTraceUtility.ExtractStackTrace()
Debug.Log()调试信息造成，这是一个很耗时间的操作。发布的时候尽量去掉
-
GarbageCollectAssetsProfile
引擎在执行UnloadUnusedAssets操作
-
总结
授人以鱼，不如授人以渔。技术的进步是无止境的，大部分的时候都需要我们自己去解决问题，只有方法才是真正的解决问题之道。
-
善用、活用Profiler!
- 经常使用Profiler为项目来进行体验
- 通过Profiler.BeginSample和Profiler.EndSample来自定义检查范围
-
关注CPU & Memory Profiler
- GC Alloc、 Time、 Assets、WebStream…
其他
-
- Andriod版本无法连接Profiler调试
- adb forward tcp:54999 localabstract:Unity-\
- 再次选择AndriodProfiler(ADB@127.0.0.1:54999)
