Dave LaMacchia 和 Jason Patterson 撰写的这篇文章对拥有数十亿用户的应用程序的有效性能工程是什么样子提供了令人难以置信的深入见解。
我总是喜欢听到带有自己的缩写词的自定义性能指标。这里我们介绍%FIRE – 经历过令人沮丧的图像渲染体验的人的一部分（基于用户将图像滚动到视口后图像加载所需的时间）， TTNC （网络内容时间）测量从应用程序启动到提要中可见新内容的时间和cPSR （创建发布成功率）表示用户设法发布他们开始创建的内容的频率。
这篇文章向我介绍了边界测试的概念，描述如下：
边界测试是我们测量边界的最末端以了解效果的一种测试。在我们的案例中，当一小部分用户导航到用户个人资料、帖子的转化视图或他们的活动源时，我们引入了一点延迟。
通过这种延迟，我们可以推断出如果我们同样改进向这些视图交付内容的方式，将会产生什么效果。
[…]
我们了解到 iOS 用户不能容忍过多的延迟。我们添加的越多，他们启动应用程序的频率就越少，停留在其中的时间也就越少。使用最小延迟注入时，对某些视图的影响很小或可以忽略不计，但最大的注入会产生全面的负面影响。人们阅读的帖子会减少，自己发帖的频率也会减少，并且总体上与应用程序的互动也会减少。请记住，我们也没有在核心提要中注入延迟；而是将延迟注入到核心提要中。只需进入个人资料、永久链接和活动即可。
其中还有更多内容，包括他们的自定义内部性能记录器（SLATE，“系统延迟”记录器）的详细信息，以及在其指标和工具的帮助下实现令人惊讶的性能改进的几个案例研究，以及一些关于如何实现的结束语Swift 并发正在整个 Meta 中得到采用。
通过拉夫·科尔伯恩
原文： https://simonwillison.net/2024/Dec/29/threads-ios-performance/#atom-everything