“如果你无法衡量它,那么也无法改善它。“
– Lord Kelvin
性能优化就是在各种限制条件下达到极致的过程。
性能测试是优化的前提和基础，也是性能优化结果的检查和度量标准。
性能测试的第一步，先定义性能指标，从客观性能的角度来看，性能指标包括：
- 响应时间
- 客户端程序最直观的体现就是卡不卡
- 服务端程序最直观的体现就是从发出请求到收到最后的响应数据所需要的时间快不快
- 并发数
- 客户端程序没有并发数的概念，而且线程、链接等资源也不是越多越好
- 服务端程序所能扛住的并发用户数，区别于总用户数和在线用户数
- 吞吐量
- 服务端程序单位时间内系统处理请求的数据，体现的是系统的处理能力
- FPS
- 衡量客户端程序是否流畅的指标，60为佳
- 启动时长
- 通常用于判断客户端程序冷启动是否在合理的区间内，和用户流失率息息相关，影响用户体验
- 性能计数器
- CPU 使用率、内存使用、网络 IO 等指标，用于监控系统的负载，如果指标太高，通常也预示性能可能会出现问题，一般会设置一个报警值
测试方法对于客户端和服务端差异就大了，服务端：
- 负载测试
- 压力测试
- 稳定性测试
服务端侧重于提高系统容量，以满足更大的用户群体需求；客户端侧重于平衡系统的资源（不可伸缩），适当做一些妥协，避免给用户带来不良体验：
- 页面渲染所花费的时长
- 打开 WebView 所花费的时长
- 电量耗损率
- 流量
- …
除客观性能外，客户端还可以在主观性能上下功夫，通过交互、动画改善用户的直观感受，让用户觉得舒服。
再说优化。
优化并不是某一层的事情，要用分层思维考虑系统的优化，如：
- 硬件优化
- 机房与骨干网络优化
- 服务器与硬件配置优化
- 客户端应用在这一层可以做 DNS 优化
- 中间件优化
- 操作系统优化
- 虚拟机优化
- 基础组件/应用容器优化
- 客户端应用在这一层可以做与服务器通信之间的优化
- 其次是架构优化
- 缓存 - 缓存被大量用于系统的各个层级，减轻数据通信之间的负载压力
- 异步 - 异步架构可以大幅降低响应时间；同理异步渲染也可以减轻卡顿现象
- 集群
- 最后是代码优化
- 设计模式 - 设计模式作为最佳实践可以避免烂代码、耦合等问题；帮助实现清晰、灵活、健壮的代码，为代码优化提供一个长期基础
- 多线程 - 如一写多读提高读取性能等
- 资源复用 - 对珍贵的资源（如线程、连接、View等）实现复用，避免创建、销毁产生的开销
- 数据结构 - 在场景里利用正确的数据结构（特性）管理数据可以提高性能
从纯代码角度来看，优化程度往往有限，相比之下，代码拥有清晰、易维护、易懂、简单灵活的特点好处更大，在实际工作中只要用正确的数据结构、设计模式进行编程指导即可。
性能优化的时候需要建立整体思维，要从整体系统的层面去思考优化，而不是只是仅仅关注自己的代码，或者是自己设计的架构。