Unity | 游戏开发中的优化思维
目录
一、优化三板斧：
第1步：定标准
第2步：重数据
第3步：严测试
二、流程和性能的优化
1.定标准：
2.重数据：
三、交互和表现的优化
1.卡顿和延迟
2.手感硬
四、沟通和学习
一、优化三板斧：
优化的开门三板斧：“SDT（Standard-Data-Test）”模型：定标准、重数据和严测试。
第1步：定标准
就是要求在重事实的前提下，进行同标准下的问题沟通。相对应地，在做性能优化的量化分析中，我们经常会将设备一致和流程一致等作为前置标准，以确保分析和研究使用数据的确定性、可比性和可重现性。只有这样，我们在进行定性和定量分析的时候，才能最快达到逻辑条件的覆盖，否则容易陷入盲猜原因的冗余测试中。
第2步：重数据
优化的本质就是改善数据。数据来源：
- 既定事实：如项目大小，文件数量，代码行数等。
- 人工统计：如人工计时统计等。
- 代码逻辑：如代码 Loop嵌套循环遍数等。
- 工具测试：如UWA工具统计的各种运行时开销等。
- 官方文档：如Unity官方文档，iPhone/Android手机官方文档等。
第3步：严测试
优化调整的正确性、完整性和安全性是我们追求的胜利结果，切忌看到一点小胜后就盲目乐观与大意，要胜就要大胜完胜，优化后的严格测试环节就是确保大胜完胜的必备基础和先决条件。
二、流程和性能的优化
1.定标准：
- Android设备的闪退以系统当前PSS值（Proportional Set Size）作为阈值参考。
- 1G运存的iOS设备闪退阈值大约在645m左右。
- 运存越大的安卓系统设备，APP相对应的PSS值中缓存比例也越大。
2.重数据：
在1G运存的iOS设备上初始号半小时内的相关内存峰值低于645m。
用数据说话： 升级机器配置很重要！但是有多重要？数据说话：启动项目耗时对比数据
三、交互和表现的优化
1.卡顿和延迟
玩家通常会把有掉帧表现的卡顿和延迟混在一起说，我们知道它们有本质上的不同：
- 卡顿：单秒的渲染帧数不满足设定的标准帧率，尤其在连续的时间内实际帧率波动太大，卡顿表现就会尤为明显，卡顿必然伴随着处理的延迟。
- 延迟：操作的反馈比预期要来得晚，原因可能有多种，消息阻塞了，逻辑卡顿了，网络耗时长，响应灵敏度低等等。
【定标准】我们要将游戏操作的延迟控制在可接受范围之内。
2.手感硬
如果是对操作要求非常高的即时类游戏，如若采用状态同步，则策略通常是以前端的表现优先，即操作的响应先行，不依赖于服务端的逻辑判断，但操作的最终结果则需要在服务器进行校验，若采用帧同步则需要等待服务器转发后，各端再同时进行表现。不同的游戏类型对于延迟的要求和处理方案均不同，需细心处理对待。
操作的响应反馈过程是交互的重要一环，我们对于一次交互产生的感觉以及交互质量的判断均取决于此。例如当我们说操作过程给人感觉比较硬的时候，一般说的是在这次交互过程中的响应反馈过程是偏硬的，而硬这种体验从现实来说，就是缺乏过程或过程转换太快的一种描述（软通常就伴随着有弹性和形变过渡）。
【定标准】游戏操作的手感不要太硬。
四、沟通和学习
1.沟通
在心理学上有一个叫自利归因偏差的理论，说的是在我们的潜意识里，有归因的倾向性。成功的事都归因于自己，失败的事都归因于别人。这是大脑的一种自我保护机制，这种自我保护通常会让我们无视既定事实，会有缺乏理性的冲动。
【定标准】确保我们的沟通可以客观，克制本能的下意识自利冲动。
2.学习
【可量化】学习不仅仅要求知识和技能成长，更要重视学习思维与方法的训练与成长。