关于游戏性能优化的一些感想

最近在做优化的时候越来越感觉到，优化并不是给游戏加一个全面的增益Buff，优化的本质是做取舍，一方面优化了，必然会带来另一方面的问题，它是一个零和的博弈。

比如我们常用缓存或对象池来提高游戏的性能，减少卡顿，这就是典型的用空间换时间。同时我们也会偶尔用压缩技术，压缩一个文件，或者数据表，比如AssetBundle就是压缩过的，然后在读取的时候再进行解压缩。这就是典型的用时间换空间。

我们总是在做时空转换，那有没有从空间到时间都得到性能提升的优化呢？也不是没有。但优化的代价可能是工程复杂度，更巧妙的代码通常也意味着不够直接，更难读懂，更难扩展和维护，同时也可能是针对特定情形的优化，使得解决方案的通用性降低。乍一看，这种优化似乎还可以接受是吧。那接下来我得举几个例子，我们好好讨论一下这个问题。

比如一个简单的排序，我们最开始用的是冒泡排序，后来改成了快速排序，我们假设快排就是无脑的比冒泡排序优秀，时间复杂度空间复杂度都更低。但同时我们也做了一个假设，就是快排的代码更难写，也更难读懂，接手的同学根本不理解这个算法怎么实现的，也不敢改，那后续来了需求要修改一下排序的某个逻辑，同学一下子就慌了，最后改了一个星期终于改好，硬着头皮上了。如果是用冒泡排序，相信这个同学很快就能满足新的改动需求。

这里只是举一个例子，但也足以说明一些问题。《代码大全》里说

程序员的第一技术使命是控制复杂度

每个人对这句话都有不同的理解，控制的是什么的复杂度，但在我的理解里，其有一部分就是代码复杂度，架构复杂度，工程复杂度。也许你用了很巧妙很先进的架构和算法，但是你自己无法完全把控，那么你对它来说就是缺乏了控制力，也许这个版本能跑的没有问题，但是你不能很好的面对其中的问题，未来的维护扩展，以及修改需求。

我并不是说不能写更优秀的算法。而是想表达，任何优化都是有代价的，只不过有的时候你没有意识到代价的出现形式，认为这不是优化带来的。

比如我在项目里曾经做了一个优化，该优化的结果是，所有的资源都需要重新跑一遍脚本进行重新修改才能够使用。结果导致打包处理时间过长，迟迟无法出包，影响了测试部分的验收，导致抱怨频频，最终我的脚本被回退，我不得不重新选择更谨慎的办法。

每一个项目都有其自己的管线，有项目成本，就比如我刚才的例子，测试部门的时间通常都被压缩的很紧，特别是临近上线或者版本更新，任何影响测试流程的行为都可能导致项目无法正常验收，进而造成项目延期或顶着Bug上线等严重的后果，这对于一个已经上线的成熟项目是绝对不允许的。

优化不只是一个技术活

之前我的前辈在离职前做了一版优化，导致游戏资源文件多了近两倍。最后导致游戏下载时间过长，被苹果拒审了。于是我接手的第一个任务，竟然是加班通宵认真回退前辈的优化代码，那个滋味可想而知有多么荒诞和无奈。

所以说优化是个取舍，因时，因人，因项目的不同而不同，要分析和明确优化的重点，以此又会牺牲什么为代价，确定好了再做优化是合理的。如果分析不清就盲目优化，就有可能取不到效果或进行负优化，同时还给自己的未来埋了许多不确定的坑。

比如游戏是重战斗体验的，那战斗不卡顿就是最需要保障的一部分，你可能会通过预加载，对象池，特效分级等技术来保证CPU和GPU的流畅。虽然增加了内存可能会导致低端机器闪退，但也总好过战斗对每个机器来说都一卡一卡的要好。在保证了游戏体验以后，再慢慢想办法去优化内存占用。其实时空换来换去最好是能把代价转移到外部存储上去。有些对IO时间消耗不敏感的，比如一些UI逻辑读取的数据，可以放到外部目录，而非放到内存里。根据最终的体验选择一个合适的度也不错。当然如果因此导致外部存储文件过多，而项目又有着复杂的热更逻辑，那也会带来另外的问题，还是要做取舍。当然如果你的游戏核心玩法没有那么硬核，像做了一个SLG，要求游戏不停的迭代新内容，打后期盈利，那么你对框架的设计就要更谨慎，框架的可维护性和可扩展性，响应迅速就成了一个项目的重点。因此不管时间还是空间，在不影响体验的前提下都要向架构让步，让架构变得更灵活好用。

所以优化问题说很大，其实最重要的还是弄清楚目标，想要优化什么。先确定项目的重心，然后选择优化的方向，再通过合适的工具分析出项目的瓶颈，再选择合适的方法进行优化。当然这个过程中还是要谨记那句话：

控制复杂度，做好取舍

搜索

复制