如何做好Unity项目性能优化
在面试中，我们经常会被问各种”莫名奇妙”的问题, 比如这道:”你是如何做好Unity项目性能优化的?”。“这个问题也太泛了吧，没有具体的优化点,这怎么回答?” 瞬间跃入脑海。做面试复盘的时候，你可能会想这个面试官是不是什么都不懂，是个”青铜”啊。没错，能问这道问题的面试官要么是个”青铜”, 要么就是”王者”。说他是青铜，可能真的什么都不懂,只是他听人说Unity 项目做性能优化的时候比较麻烦,所以就来问你，看你如何处理。还有一类是王者，就是来考你各方面的综合能力，接下来我们从
(1)从项目技术管理的角度来杜绝性能问题;
(2)性能问题定位与分析;
(3)性能问题的常用解决方案;
这3个方向来回答这道很泛的面试题，让面试官对你”刮目相看”。
对啦！这里有个游戏开发交流小组里面聚集了一帮热爱学习游戏的零基础小白，也有一些正在从事游戏开发的技术大佬，欢迎你来交流学习。
1: 从项目技术管理的角度来杜绝性能问题
“性能优化”最重要的方式(没有之一)，不是任何的编程技术与技巧，而是从”项目管理”上防止”游戏做完马上要上线”时出现的性能问题。在日常项目管理中，把性能监控起来，问题尽早发现，尽早动态清零，这样才能做到项目从性能风险上是可控的。我的一些经验如下:
a:用心做好技术调研
我们很多小伙伴不重视技术调研，或者技术调研做的非常的马虎，导致对游戏的性能预估不足。比如我们做渲染管线定制，编写了Shader,效果出来自己比较满意，渲染这块的技术调研就结束了。其实不然，这个事情才做了1/3不到，还要注意必须要最快的速度尽早多平台测试(有些同学的项目真的好笑，到了上线前一晚才发布到不同的手机真机上跑)。你在项目开始就上多平台，才能发现各个平台不同的差异，尽快解决这些差异与问题。同时还要构建游戏核心玩法中的极限情况模拟，来应对项目后期大量战斗单元出现导致的性能问题。
b: 从项目正式开发的第一天起就引入多平台测试与完整的测试机制;
这个强调多少次都不为过，什么时候，哪个改动,引发了哪个问题,什么时候出现了一个什么样的问题，如何解决的,作为项目管理者，要一路对这个过程非常的熟悉，只有这样你才能真正了解你这个项目的稳定性。
c: 留出专门时间与专人review代码;
开发项目的时，我们需要有专门的技术负责人review整个项目的代码，了解团队成员的实现思路与代码设计，把控项目质量,确保没有太大的问题，技术负责人都知道具体是如何实现的。这样有非常复杂bug的时候，团队至少有人能从整个全局来了解整个项目和代码。出现性能问题的时候，能从大局着手,进行分析组织大家攻关。
d: 了解运行中技术参数的变化，做好技术参数统计;
开发项目时，每次有功能完成提交测试后，我这边会让测试出一些性能参数的统计，比如main thread多少，render thread多少, batches多少等。每次数据的变化，结合review代码，看下是否合理，能够做到什么时候引入了哪个功能，让drawcall增加了几十，是什么引起的项目中作为管理者都要清楚和关注。
总之完整的工程管理机制，与测试共存, 动态清零包含性能在内的问题,是做好性能优化的最重要的手段。做项目是一个工程问题，质量靠管理，不靠程序员的”天分”。(注:防疫动态清零也是个工程问题)
2: 性能问题定位与分析
当项目开发过程中发现性能问题后，如何定位性能问题，定位到具体是哪里引发的，这个就变得非常重要了目前主要的手段如下(按照我认为的重要程度):
a:代码算法与系统底层功底: 为什么大厂老要求算法，OS底层，数据结构，引擎底层,只有对这些基本的原理原则了解了，思考问题的时候才知道如何分析与解决。比如算法的时间复杂度，空间复杂度，比如Drawcall合批所带来的性能提升与性能开销的权衡等。
b:工程管理手段: 通过工程手段测试出来了性能问题，我们可以比对上一次测试与本次测试的开发记录，看看是引入与编写了哪些代码导致的性能问题，频闭掉可疑的代码,反复确定,这样能帮助我们瞬间就定位到出现的性能问题。(注：95%以上的问题我都是通过这种对比发现的，通过开发记录对比可疑代码，屏蔽可以代码确认，从而分析问题最后解决)
c: 打印: 没有打印解决不了的问题，如果有继续打印，linux 内核的开发与调试基本就靠打印，因为复杂的多线程调度环境，任何工具都不好定位，所以没有打印解决不了的问题。
d: 性能工具剖析手段: 通过Unity提供的性能剖析工具,来进行问题定位与分析。Unity引擎运行中会提供很多API与性能参数给用户获取，而Unity引擎自带的工具也是调用这些API获取游戏的性能,比如stats统计与Profiler统计。同时还有一些第三方的插件，也是做性能监视的，本质也是读取Unity引擎提供的性能参数API，把自带工具没有显示出来的重要性能参数显示出来给用户。注:不要迷恋工具，要从管理+数据+执行流程上对程序进行分析，性能工具是做这些分析的方法之一，甚至不是最重要的
3:性能问题常用的解决方案
说到这里了，才是我们很多面试的同学一开始就回答的,可以用xxxx手段来解决xxx问题。可能我们说的都对，但是在”王者”面试官看来，他出这个面试题,目的就是看你是否从系统上去思考如何把控游戏项目的性能。定位到了是某方面的问题，再去应对一些常用的手段，这里我就把一些常用的列举一下，可能有遗漏。
Drawcall优化: 确定是Drawcall问题后，根据游戏项目选择一种合适的合批技术，为这个技术创建可合批的条件，做好合批,具体可以参考我写的《Drawcall优化系列》教程详细的分析了Drawcall合批的技术手段与原理，性能与开销(what?合批还有开销？没有错)。
渲染优化: 看下pass的次数与set pass 次数, pass 次数，比如阴影这些都会导致多次pass,多光源这些会导致多次pass, 我们可以通过定制渲染管线,优化shader代码, 优化光照计算等，从Shader+渲染管线级别来做好渲染优化，现在比较火的UPR渲染，也可以参考我写的《URP 实战系列》的教程。还有LOD优化，远处用的面数少，近处用的面数多。抗锯齿算法优化等。
物理引擎优化: 这块化没有太多的空间了，用其它的技术去替代不用物理引擎，减少物理引擎的迭代参数,减少计算量，减少物理刚体的数目。
网络优化: 异步IO代替同步IO，多线程处理网络消息, protobuf序列化与反序列化优化网络包体体积。KCP 替换传统的TCP。
包体优化: 优化图片，声音体积，通过改变压缩参数来降低这些资源的体积大小。可以使用服务器上部署资源包来实现打空包机制进一步减少包体体积。
热更新优化：版本管理，增量下载，断点续传等。
内存优化: 减少资源的内存占用，不用的资源卸载掉，吃入显存的纹理可以采用平台支持的压缩格式。缓存池,减少内存碎片,减少对象的反复构建，避免GC峰值冲击等。具体可以看下《性能优化-内存篇》。
模型优化：通过细节增强,法线贴图，高度贴图，凹凸纹理等减少模型面试的同时获得很好的效果。
寻路导航优化: 优化算法，流场寻路等，多线程优化寻路算法。
代码写法优化: for循环内部不要过多跳转打乱CPU Cache等。……
其它的一些具体的优化手段，针对不同的问题来做一一的处理就可以了。具体问题具体分析。
如果你是面试官，看到一个年轻的小伙,能系统的思考”性能优化”这个工程问题，你会录取么？
