Unity的性能优化大家一定很熟悉了。
我在Unity4~5的时期，做过多款大型在线射击对战类网游，超大地形加载优化。对性能分析优化工作和在使用Profiler的过程中总结了一些经验。今天才有空分享出来，欢迎大家讨论，和提出不同的见解。给Unity优化工作的朋友一些启发和帮助。
写本文的目的不是教你怎样使用Profiler，而是在工作中发现和看到了一些问题，引发了一些思考。在这个基础上产生的一些想法，本文没有技术层面的知识，只是总结的思想、方法。
性能测试需持严谨的态度，理性的看待问题
了解和使用过的小伙伴们，都知道就是使用Profiler能看到哪些地方比较耗费CPU，GPU效率，吃内存。在项目进行到一定阶段的时候，一定会进行的任务。
一些又责任心的程序会自己筛查自己的、甚至发现他人的有性能问题，内存问题的代码。
在工作过程中，有时发现有些程序在分析性能和得出结论可能是完全错误的，如果不够慎重处理，小的来说影响了几天工作，大的来说，可能会影响了整个项目组的工作方向，导致产品开发的失败。所以性能的测试分析结果是要非常认真对待的一件事情。
对待性能问题，要保持初心，要经过反复的对比测试，穷举测试，保持测试结论的科学严谨性。不能凭直觉和应该觉得就拿出一个结论。
举例说明，假设游戏开发阶段要对模型进行减免，游戏里大概有50多种怪物模型需要减免，如果一个不严谨的测试，得出结论把10000面减少到5000面，游戏就可以流畅了。那么整个美术组同事要数月时间修改模型，调整蒙皮，动画。最后的发现并不是和当初设想的一样。那么这就是严重的问题了。所以性能测试需要一个严谨的测试态度，多方面，多维度的考虑事情，切忌草率。
例如：你想象一下在相机视角内有10个带动作的3D人物模型，站在一个平面地形上。帧率只有20左右，那么你首先想到的是什么，可能很多人第一直觉是：
- 肯定是模型的面太多了，减面就解决了。
- 肯定是贴图太精细了，把图缩小就解决。
上面的可能不是优化性能的重点，甚至是可能是错误的方向，人物模型面数可能不能随便减少，还要看游戏品质需求，贴图2048的换成256的，你的性能真的提高了吗？
其实还可以列举一些还可能性能有影响的地方：
- 骨骼模型节点太多了。
- 人物IK脚本肯定有问题。
- 人物动画可能太复杂了。
- 环境光照，Shader等的问题。
- 测试游戏环境问题，够不够干净。例如那个平面地形有没问题。
- 你自己的测试环境（电脑）有没问题。
- 等等其他类似布料，头发等因素
那么，可能接下来。
你可能又说，当然不能乱猜了，要进Profiler跑一下测试。看看到底是哪里占用消耗大。
没错，我们要理性的看待问题，到底什么在卡，我们要进入效率测试，看看到底是什么。
But，这里要注意一件及其重要的事情 - 用户对象群体
用户对象群体和性能测试
首先大家可曾遇到过这样的问题？
项目开发完了，感觉整体流畅表现不错。但是装到手机、主机等其他平台，怎么卡的动不了，或者这手感……没法玩啊……是不是天上一群马飞过，有没有类似的经历？
明明发布前性能分析过了，没什么问题。
一些人明白了过来。我去，运行平台都不同执行效率当然就不同了。
那么你用一台I7最高配的CPU，2080的显卡作为测试效率的机器，你可能看出什么？据我所知Profiler并不能自定义CPU，显卡，来测试性能。加上其他干扰 - Scene窗口的干扰，Log输出的干扰等，都会导致你测试准确性翻天覆地的不同，得到错误的结论，这些干扰因素后面再谈。
所以首先要确定用户对象群体，如果是主机游戏开发，那么简单了，配置都一样。如果是网页游戏，手机游戏，那么你就要在游戏质量上做一定取舍，或者分不同挡位去设计。
思考一个问题，如果你的开发机是最高配的CPU，用的是几年前甚至更早的集成显卡。又或者你用了一台十年前的双核心电脑开发，装的是一个还算不错的3D显卡。
在Profiler的性能显示上会出现什么情况。
前者 高配CPU，低配GPU
CPU usage 面板 可能跑到了200FPS
GPU usage 面板 可能只能到勉强的30FPS
后者 低配CPU，高配GPU
结论和前者是相反的。
不够平衡的CPU，GPU 会相互拉低你的最终FPS表现，本应当优化CPU的你优化了GPU部分，优化不理想，FPS得不到提升。
总的来说也就是说你的性能测试平台选择很重要，不能够选择性能强劲的机器和不平衡的机器来测试。
具体来说：
如果是手机游戏优化，在游戏效率优化阶段，就要找一台配置比较低端的机器（例如2核心，4核心），集成显卡，目的就是要趋近于用户低端机器配置。最然性能不高，但是得要稳定。能够和用户最低端手机性能能够对应起来。
再进行CPU，GPU的优化就能得到一个比较科学相近的数据。
还有一个办法，在BuildSetting界面里的Adutoconnet Profiler选项，程序发布后，可以透过网络方式反应到电脑的Profiler里。这也是一种性能分析方法，方便真机测试。因为是网络的，不能暂停程序，所以也又很多不便。和上面的方法相比各有利弊。
有了合适的性能分析的机器再做性能分析，准确性会更高一些。
当然并不是否定高端机来性能分析，如果只是提高和优化代码的效率也是可以的。用合理配置的机器会更加事半功倍，并且能够得到更加合理的配套解决方案。
性能优化方案和综合因素考虑
为了能让程序运行的更加效率，Unity作出了很多技术点。例如：静态烘培， drawcall动态合并，剔除，LOD，还有Quality里的各种参数，Terrain里的很多参数。目的都是为了提供挡位让低配机器能够运行，让高配机器发挥性能提高画面质量。
首先我抛出一个问题，大家思考。
地图制作需要放置 10000个模型（随便什么，桌子模型就行） ，或者更多（取决于你的电脑配置，好就多放，差就少放），相机中一眼望去要全部能看到，都在相机视野中。
当FPS降低掉60FPS以下的时候。
如此数量庞大的Mesh需要相机渲染，是很费性能的。
减面操作会影响距离相机比较近的桌子模型变的难以入目。
使用LOD ？如果10000个LOD在工作，只是那10000个LOD脚本就能让CPU耗费很大力气。也不是一种最优的方式。
还有一个办法就是模型合并，例如按照远近距离把每100个或者一个区域的桌子全部合并模型成1个模型，那么100个桌子就是一个模型，整个场景就只有100个模型了。甚至可以把桌子模型面数减少，1000个桌子一个模型。那么几乎就不存在渲染压力了，只有10个模型。
那么再根据地图距离，让远处的一片一片（合并的桌子）的显示最低模，近处的是独立的桌子，控制一个平衡点，总体的渲染数量减少了，极大降低了面数，动态drawcall负担，LOD负担，达到最优的负载。 这种可以应用在超大地图处理。要把多种优化方式综合起来一起应用才是最优化方案。
当然不同的游戏，不同的环境，优化的方案也是不同的。总有不同的最优的方案，需要我们不断的挑战和尝试。效率的优化不是一成不变的，随着Unity版本的提升，技术的变革，优化的方案方式也会渐渐的不同。
我们不能一说优化就LOD，就减面，合并Drawcall，我们需要综合考虑所有因素，制定符合游戏的优化方案。
性能测试记录工作的重要性
我们在多年游戏性能测试中发现，形成对实验数据记录是非常重要的。在早期没有这种观念，每次性能测试都有一个目标，这样的目标很简单，测试完毕后有了结论就认为可以了。
后来发现，每次都有重复的东西需要测试，或者甚至放了一段时间后，测试的结论都记忆不清楚了，又得重新测试。
举个例子：
第1次测试：人物减面，从15000减到3000，性能是怎样的？
提高了多少？提高了不少，再往下减面的话发现就不能看了，所以得出结论（当时的结论）- 只要都减到3000就行了。这时候会觉得也不用记录什么了，反正减到3000就可以了。
后来发现还是想提高承载能力，继续想办法优化。加上LOD怎么样。远处的模型给他100个面其实也看不出来。那么测试下100个面吧。
于是第二次测试开始了，从3000到100面性能提高了多少ms，15000到3000提高了多少？这时候因为没有记录无法对比了，这时候则是需要再次进行15000-3000减面的再次测试，进行对比。
后来又发现骨骼数量，蒙皮渲染器的数量等等对性能也又一定影响
那么又有测试的想法了，到底是把原来的5个蒙皮渲染器优化成1个提高的效率高，还是减少到3000面的效率高？又或者把骨骼数量从100根减少到30根提升的效率多还是减少面的提升的效率多？
游戏的优化过程总是在游戏表现和游戏性能之间取舍，我们总是想把最好的留给玩家，用最小的代价表现更丰富的游戏画面。这样复杂的测试是需要通过每一步测试要记录成详细的图文记录，或许后面又有新的优化想法，只需要在补充测试就可以了。这样的一个系统的记录，将形成一个宝贵的资料，可能半年一年后记不清楚某些性能优化点，可以翻阅测试记录来参考。否则的话你将面临一遍一遍的寻找性能优化解决方法。
早期我重复做过大量的重复的测试工作，还不是没有记录，而是记录的不够全面，例如上次结论和这次怎么又不同？是模型不同吗？忘了记录当时测试的模型是那个？截图找不到了，有截图就好了？是优化后2000面的？还是4000面的？是减少骨骼的？还是蒙皮渲染器减少的？当时的测试机器是哪台？是否换了机器，结论不一致？
所以，你想一下，测试记录重要不重要。所以需要能记录多细致就多细致，需要记录Unity版本，时间，测试模型名称，面数，骨骼，动画，环境因素（光照等），测试环境的一致性，测试机参数，甚至测试机温度，是否存在问题。
记录的全面性会让你能有一个清晰的优化思路形成方案。
最后
因时间有限，文中并没有详细的案例，只是一些经验和方法的，希望能带给你一些思考方式。
早些时候有一些测试文档和图文记录，大概几十个G，经过多次搬家更换主机也都丢失了。
如果单独为了这个博文去做用例，那可能时间太久了。
后面如果有机会系统的进行测试的工作，我会再分享一些现有的案例来具体说明。
