目录
一、优化三板斧:
第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.学习
【可量化】学习不仅仅要求知识和技能成长,更要重视学习思维与方法的训练与成长。