超越基准：采用基于指标的方法在真实设备上维持iOS长期的良好性能 文章

试想你有一个面向机组人员的移动应用：它没有备用服务器，在巡航高度没有WiFi，并且应用在服务过程中出现崩溃无法通过简单重启来恢复，因为它以引导访问(guided access)模式运行，恢复需要完全重启设备而非简单重启应用。机组成员执行的每笔事务（比如，餐饮订单、免税品销售、饮食偏好）都会写入设备并在飞机降落后与后端同步。库存通过蓝牙在机组设备间保持一致，任意时刻会选举一台设备为主设备。我曾经是负责让该应用在18小时的飞行中保持可靠的核心性能团队成员。早期版本曾在现场令某位机组成员遭遇失败：屏幕冻结、用餐服务还在进行中、没有崩溃日志、无法恢复。正是那次事故促成了我在此处描述的方法论的诞生。一个应用可以通过所有基准测试（比如，冷启动低于2秒、API延迟低于400ms、十次测试无崩溃），但在真实使用四小时后仍可能出现降级且易崩溃的体验。本文记录了这种失效模式，解释为何系统性的理念会被忽视，并描述用于检测与预防它的架构方法以及Xcode Instruments分析技术。通过基准效能测试所造成的误解移动性能工程中常见的模式是基于孤立的测量来标记应用“性能良好”，例如，Screen X在320ms内渲染、API Y在400ms内响应、冷启动1.8秒。只要仪表盘变绿，应用就能发布。但在机组18小时飞行的第6小时，应用可能会面临冻结的风险。这种模式属于时点采样(point-in-time sampling)，也是最常见的机制，即团队发布的应用在真实使用中会降级。用户会浏览、滚动、后台、恢复、切换上下文，并在远远超过基准窗口的会话中反复使用。会话期间的性能是由CPU负载、内存状态、热调节、操作系统调度与后台进程竞争共同塑造的动态系统行为，这些在一小时的基准测试中是无法完全暴露的。相关研究也支持这种模式：谷歌的移动性能研究发现，当加载时间超过3秒时，53%的移动访问会被放弃，这一结论影响了业界对性能的认知。但是，该研究仅关注初始加载，测量的是用户是否决定留下的瞬间，而非随后数小时内发生的状况。对于在持续使用环境中运行的原生应用来说，这种表述完全错过了我们所述的失效模式。用户对性能的敏感是确凿且有证据的，但在长会话应用中，降级是累积性的，并非在首次加载时就显现。它在数小时内悄然累积，直到无法忽视。为什么针对真实设备的测试是不可妥协的模拟器在功能测试中有其合理的用途，但在性能测试中则是不

摘要可能不完整，可查看原文