Unity游戏开发客户端面经——性能优化（初级）

前言：记录了总6w字的面经知识点，文章中的知识点若想深入了解，可以点击链接学习。由于文本太多，按类型分开。这一篇是 性能优化 常问问题总结，有帮助的可以收藏。

---

性能优化，主要聚焦在 内存、 CPU、GPU 三大方向上。

1. 内存

1.1 详细介绍

   Unity内存占用组成

1. Unity（基本所有的Unity的使用的内存，Native）
2. Mono（C#代码，可以被GC回收）
3. GfxDriver（显卡驱动，渲染时的纹理，渲染目标，shader，Mesh（顶点、法线等）等）
4. FMOD（声音资源）
5. Profiler（自身，把采样的数据的缓存下来）

1.1.1 Mono方向

        （1）编程语言：字符串拼接，减少频繁扩容，合理用new，减少内存碎片的产生（将大额内存进行预处理）等一系列降低GC的操作。尽量用结构体取代类（值类型不占用堆，不需要GC）。

        （2）配置表优化：延迟加载，具体表现为：

        1.protobuf主要用于网络传输，或者将一些数据（比如聊天数据）序列化在存本地，下次启动文件再反序列化过来就可以了。

        2.一个字典存储了所有的配置表信息，key是配置表的文件id，value是一个字典存储的配置表中的配置信息，其中key是配置ID，value是行数据偏移信息（配置行的起止位置）。

        3.序列化的时候先只需要储存索引，要用到的时候按照索引再去现场序列化即可，这样可以不在游戏开始就序列化所有数据，大大的降低内存占用。

        

        C#侧优化方案-用MessagePack压缩

        MessagePack for C＃（MessagePack-CSharp）是用于C＃的极速MessagePack序列化程序，比MsgPack-Cli快10倍，与其他所有C＃序列化程序相比，具有最好的性能。 MessagePack for C＃具有内置的LZ4压缩功能，可以实现超快速序列化和二进制占用空间小。

        详细请看：MessagePack for C＃ - HackerVirus - 博客园MessagePack for C＃ 快速序列化组件MessagePack介绍 简介 MessagePack for C＃（MessagePack-CSharp）是用于C＃的极速MessagePackhttps://www.cnblogs.com/Leo_wl/p/8143259.html

1.1.2 Native方向

        美术资源，模型面数，密度精度，贴图格式，限制等。

1.1.3 对象池

        管理unity对象

1.1.4 AssetBuildle

        1. 资源冗余（重复资源）

        2.避免运行时资源泄露。

  为什么会资源泄露

1. AssetBuildle资源卸载会产生，关联资源管理器。
2. lua 持有了unity 的对象，释放对象会产生。

2. UGUI优化—— DrawCall

UI优化核心就是一点：减低DrawCall

2.1 DrawCall介绍

        CPU准备好需要绘制的元素，对底层图形程序接口进行调用的过程。

        也可以理解为：CPU向GPU发布一条渲染指令，就是一次DrawCall的过程。简称DC。

2.2  降低DrawCall

1. 动态合批
2. 静态合批
3. 降低shader的等级特性
4. 场景优化策略——遮挡技术。
5. rectMask2D替代Mask

2.3 合批

        一次Draw Call中批量处理多个物体。只要物体的变换和材质引用相同，GPU就可以按完全相同的方式进行处理，即可以把它们放在一个Draw Call中。

        注意：简单来说在一个Canvas下，需要相同的材质，相同的纹理以及相同的Z值。例如Ul上的字体Texture使用的是字体的图集，往往和我们自己的UI图集不一样，因此无法合批。还有UI的动态更新会影响网格的重绘，因此需要动静分离。

  2.3.1 静态合批

        将static的静态物体（永远不会移动、旋转和缩放） ，如果相同材质球，面数在一定范围之内。unity会自动合并成一个batch送往GPU处理。

     1.需要做的事情

        把要进行静态批处理的GameObject在Inspector面板右上角的Static勾选(实际上只需要勾选Batching Static即可)

     2.优点

        因为只需要进行一次，所以性能会比动态批处理要好。

     3.缺点

        使用静态合批需要额外的内存开销来存储合并后的几何数据。

        因为需要额外维护多一份数据，所以包体会变大，占用的内存也会变多（不能有超级大量的相同模型（如：森林里的树））

        无法移动

        进行了静态批处理之后的GameObject不能在游戏运行时改变位置或者是跟渲染有关的属性。并且因为把所有要静态批处理的GameObject都合并成一个大网格保存起来，所以这实际上相当于即使是同一个GameObject，也需要复制一份网格数据一起保存在这个大网格的顶点数据里面去，这样就导致了占用的内存变多了。

        静态合批就是多渲染一套合并后的网格 ，提前存在内存里，内存当然就大了。

     4.原理

        在开始阶段把需要静态批处理的GameObject进行一次网格合并操作，然后把这个合并之后的大网格保存起来，后续都是用这个网格而不需要再进行合并。

        在预处理阶段，把一些材质相同的模型的顶点统一变换到世界空间坐标下，并且新构建一个大的VB把数据保存下来，在绘制时，就会把这个大的VB提交上去，只需要设置一次渲染状态，再进行多次drawcall绘画出每个子模型。 所以Static Batching是不会减少drawcall的，但由于只修改了一次渲染状态依然可以减少CPU的消耗。而且在渲染前，也可以进行视锥体剔除，减少顶点着色器对不可见的顶点的处理次数，提交GPU的效率。