楼主:
yekdniw (yekdniw)
2019-07-10 13:27:23网页版
https://yekdniwunrealengine.blogspot.com/2019/07/ImproveCPUTimeConcept.html
主旨
笔者过去被指派多次改善CPU效能的项目，累积了一些心得可以分享
因此本系列将以UE4为范例，预计提供一些观念，标准流程，技巧给大家参考
让大家都可以更快的入门，避免走一些曾经走过的冤枉路。
本篇不会提到太多UE4相关的技巧，会以效能分析与改善的观念为主。
随时审视自己的行为
在作效能改善的过程中，一定要随时知道自己在改善什么，
做了这个项目在最佳情况可以改善多少。
不要一股脑儿的投入某个细项，结果其实改善微乎其微。
CPU bound? GPU bound?
本系列要提的是CPU效能的改进，不会提GPU 改进的相关部份。
不过先了解自己的游戏到底是CPU bound还是GPU bound
绝对是首先最重要的事情。
如何知道游戏是不是CPU Bound?
在UE4要知道这件事很容易，将你的游戏放到目标平台上
使用console command "stat unit" 并观察CPU与GPU占用的时间
CPU过高就是CPU bound，GPU过高就是GPU bound。
都很高的话，就挑严重的先处理吧。
谨记80/20原则
80/20原则是个概念，可以套用在很多的事情上(可以无限上纲的意思)
在这边提的意思是，大多数程式执行的总时间只在执行少部分的程式码。
所以我们在做效能改善的时候，只处理少部分的程式码就可以改善最多的效能。
不要用猜的来改善效能
改善效能的流程请务必从量测效能开始，
偷懒跳过这个步骤，用"直觉"来改善效能的话
下场就是很容易成为80/20原则的反向教材，
花了80%的时间只改善效能的20%。
这是经验谈，就算是有经验的老手也会中招。
毕竟一个游戏系统很大，每个人都会知道自己经手的系统哪里效能不佳。
如果直接分配一段时间(例如一周)，让每个人改善自己的系统效能。
这种作法是最浪费，最没有效率的，因为效率瓶颈可能根本就不在某人上。
又例如说某个系统有一段写法很暴力或是用了很多层循环，
花了大把时间去改善，结果这段程式码只执行一次，也不会影响画面卡顿。
那么这个时间应该要省下来去作别的项目。
借由量测效能估算极限
先从量测效能开始的另一个好处是可以很快知道极限在哪里。
拿到效能数据，有经验的话很快就可以预测出要让fps达标，
总共需要改善多少系统。
就算没有经验也可以推估一个大概的方向。
举例来说，根据量测的结果，现在距离fps达标还有3ms要改进。
占用前几名的A系统占用3ms，B系统占用1.5ms，C系统占用0.5ms
寻找各系统的开发者，询问他们
系统改进方案，是属于可移除/可改善？
改进难度，是属于极难/中等/极简单？
假设评估结果
A是极难/可改善，B系统是中等/可改善，C系统是可移除/极简单
那么就可以稍为订出目标为改善B与C
估算ABC三个系统大概可以改进(0.5+0.5)，代表还有2ms需要找其他系统改进。
亦或是要花时间投资在A项目上。
时间宝贵 更要斤斤计较
很多时候我们没有太多的时间可以作效能改善
游戏说不定只有一个礼拜或两个礼拜就要发了才跟你说现在要调效能
(这不是经验谈，只是假设)
注意量测的目标平台
特别注意你现在的目标是哪个平台，请针对平台处理。
完全不建议在编辑器量测平台，除非你明确知道编辑器与打包后的差异。
如果是server/client架构的话通常效能瓶颈也会差很多，
例如UE4的架构AI几乎只能在server执行，client不会有AI。
如果现在在意的是client端的FPS，那就直接忘了AI很贵的存在吧
至于有没有要每次都在目标平台做分析，这个我反而持保留的态度。
因为很多平台的出版本很耗费时间，不利于频繁地来回测试与验证。
这时候我会建议一开始用同一个版本出各个目标平台。
例如(PC, iOS, Android)
然后以相似的测试条件录制效能报告。
比对不同平台的测试报告，确认系统的瓶颈是不是大同小异
例如说各系统所占的CPU比例在所有平台都差不多，只是绝对值的差别。
(PC 0.1ms，iOS 1ms之类的)
如果差不多，那可以先专注在PC改善就好。
如果有平台特别异常的项目，就要纪录下来，纳入改善的考量。
标准作业流程
首先大家要清楚知道在调整效能的时候是大家都需要帮忙的
但是瓶颈分析可以一个人做就好。
其他人依照分析的方向作改进会比较有效率。
所以这边分享一下之前试过一次，
觉得不错的一个作业流程 经过几次的调整就可以有效率的达到目标)
1. 录制多平台，每平台多个效能档
2. 使用分析工具确认效能瓶颈没有受到不同测试环境而有极大的差异
3. 列出应该调整的瓶颈项目
4. 询问项目开发人员改进方案与难易度
5. 制订改进目标
6. 分发工作项目
7. 着手进行改善
8. 回到步骤1验收
项目1与2目的是避免只录一次会有偏差，
我曾经遇过只对某一次测试结果分析，结果某个很贵的角色在该次测试没出现
最后多花了时间处理这个角色。
项目3就比较偏向如何使用工具来找瓶颈，比较偏一些心得与技巧，
会在之后的文章介绍。
项目4,5,6,7 就是前面提到的项目，重点就是挑风险低，改善多的项目先下手。
结论
以上讲了一些过去的心得与自己的观念，
之后预计会介绍如何在UE4 Profile CPU，如何使用Unreal Frontend。
Blueprint(BP)转C++的衡量，以及一些曾经遇过常常是瓶颈的项目。
不过我只列出大纲，时间都未订就是了XD