Facebook客户端的启动是如何提速65%的？（Facebook的加速器）_facebook知识

译者：轮盾译者 | 来源：开发人员技术前线

英语：rom://http://greenrobot.me/devnews/facebook-engineer-improve-android-app/背景

作为世界上最大的SNS互联网，Facebook的Android应用领域程序面临着各式各样的采用自然环境（地理自然环境、Android电子设备和移动互联网等自然环境的差异）。也正是那个其原因，为了检测自家Android应用领域程序在发展中国家的性能整体表现，Android的产品经理、技师在2013年的时候去了一趟西非。

这群Facebook的技师来到西非后，并在该地采用Facebook的最新版的Android应用领域程序。试验的结论的确让她们第一印象真切：

该地的互联网自然环境十分差劲，App时常受阻互联网连接。该地人民采用的Android电子设备缓存小，引致App读取缓慢，而且时常崩盘。她们的月流量在40两分钟之内就用完了。经过那个让人第一印象真切的测试的后，Facebook的技师们已经开始对她们的Android应用领域程序进行了一系列的强化。她们发现在西非打开 Android 版 Facebook app 时，因为驱动程式限制，再加上互联网带宽狭窄，因此资料写入得非常快，app 也常常停止运转。结论，她们用了 Facebook app 40 两分钟就付之一炬她们Saverdun月的所有数据了！那个经验令到她们沙泽莱，因此在返回基地后，她们下定决心要将 Android 版 Facebook app 的运转整体表现改善。她们指出 Facebook 的目标并不只是那些加进低阶智能手机和高速互联网的人，而是将 Facebook 领略到其他人，把「馀下的 50 亿人」联络人。因此，她们买了两部不同的 Android 智能手机来做一个 Facebook app 大试验，至于这些智能手机是在哪里买，型号是什麽他们并不清楚，只晓得它们缺乏内建存储空间，本该是一些西非人常用的低阶智能手机吧。开启强化UAC。指的是当应用领域还没准备好运转时，他们必须读取和构筑整个应用领域。这主要包括设置萤幕底部的列举如下工具栏，确保采用者是否被合适地登入，和处理其他更多的事情。“引导”程序是在applicationDidFinishLaunching:withOptions:方法中已经开始的。热开启。指的是应用领域已经运转但是在后台被挂起（比如采用者点选了 home 健），他们只须要晓得在何时应用领域进入后台。在这种情况下，他们的应用领域通过 applicationWillEnterForeground: 转交到后台的事件，紧接著应用领域恢复。他们下定决心主要强化UAC，主要有两个其原因。首先，UAC其实是主要包括热开启的（UAC调用应用领域并赢得全文；热开启只赢得全文），因此有更多的地方须要强化和松动。其次，UAC须要做附加的调用工作，因此相较而言非常快，引致须要较长的开启等候时间。强化UAC体验他们把UAC问题分解成三个阶段，进而他们可以有针对性地解决。每个阶段都有一些列变数和挑战。请求时间：从应用领域开启到全文请求离开电子设备（译者：应该是向服务器发送URL请求算结束时间）的时间。互联网时间：从全文请求离开电子设备到服务器响应返回的时间。响应处理时间：从响应返回到新数据展示在萤幕的时间。他们直观上认为UAC性能主要被互联网请求和响应处理影响了。那个结论是由于他们假定他们在应用领域程序花的时间比较少，并且他们设法让请求的获取更加快速。然而，当他们用 instrument 去检测时，他们发现数据非常出人意料。它展现出了完全不同的结论，他们发现全文请求花了大部分时间。另外，响应的处理时间也非常短。因此，他们重新把强化的焦点放在调用阶段。性能强化这里主要是改进了App在低端机上的性能问题。

问题：单核的Android智能手机在开启Facebook的时候非常快，这是因为app在开启的时候并行调用了多个模块。解决方案：在单核智能手机上延缓这些调用过程到开启后，甚至只有在某个模块要被采用的时候才已经开始调用那个模块。

问题：信息流在互联网自然环境差时读取速度慢。解决方案：尽早地从服务器抓取信息流数据，用更多的时间来建立连接，并下载信息流的内容。

最终的效果是App的开启时间减少了50%。

数据处理效率的强化

西非的旅程让技师们发现流量在发展中国家非常昂贵，而且作为Facebook重要体验一环的照片则是流量花费的大头，于是为了让人民在不担心流量的前提下安心享用Facebook，技师们下定决心对App里面的照片动刀：

寻找现有图片格式的替换者。经过技师们的调研，在众多的图片格式中，最后技师选择了Google的WebP。其原因很简单：压缩效率高，而且对Android的支持好（毕竟就是Google提出来的）。采用 WebP 后，相对于JPG格式的图片，流量省了将近 25% 到 35 %；相对于 PNG 格式的图片，流量省了将近80%。最重要的是采用WebP后图片质量还没改变。

按照电子设备处理图片的能力来读取图片。在之前，Facebook的App都是统一读取最大分辨率的图片，这样做是为了让采用者可以自由的缩放图片。后来改进后，app最先读取的图片大小适合显示那个图片窗口大小一样。如果须要缩略图，app就只读取缩略图大小的图片，采用者须要更高分辨率的图片，app也能读取，而且之前的统一读取最大分辨率的图片了。

调整缓存和重用图片的策略。技师试验了不同的缓存策略，不同的缓存大小，最后综合出最优方案。

最后的效果也是讲流量花费减少了50%。

互联网强化

由于许多地区的互联网自然环境比较差，这让Facebook的App的体验也变得十分差劲，于是技师也对app的互联网效率和可靠性进行了一番改进。

采用OkHttp。Facebook 很早就已经开始采用Square公司开发的OkHttp（一个开源的互联网协议栈）了，现在Google 官方也从Android 4.4已经开始采用 OkHttp作为HttpURLConnection的默认实现了。OkHttp 支持在差劲的互联网自然环境下面更快的重试，并且还能利用 SPDY 协议进行快速的并发互联网请求。

利用Okhttp调整图片的预先抓取算法，确保app中下载队列前面的图片被优先处理，防止队列阻塞时间过长。

Feed强化Feed请求发送的调用因此为什么那个阶段花费了那么多时间呢？很多 iOS 应用领域并没有这样一个问题——她们在那个阶段并没有很多工作须要做，除了调用视图控制器和发送互联网请求。然而，对于 Facebook 来说，大部分时间被用来已经开始的时候去设置不同功能块。下面是他们应用领域中的主要功能块的流程概览。

这看起来好像是很复杂的应用领域开启设置。但须要重视的是，这些功能块对于 Facebook 应用领域来说是非常重要的提升，可以提高应用领域体验，并且使得技师能够在不同的应用领域规模下更快地开发。正如他们所关注的那个流程，他们通过强化独立的部分赢得了一些主要的成果。然而，由于未来支持新特性的调用和附加提供支持的基础设施，这些成果会慢慢地抵消掉。这使得他们重新考虑如何去解决问题。但他们重新已经开始，他们认为那个阶段的目标是简单地发送全文的互联网请求。但是为什么全文请求发出去得这么慢？这是由于很多依赖被添加到全文的调用中了。然而，她们并不都是必要的 — 对于全文请求来说，最少的须要一个有效的验证 token 和全文光标（新闻全文的位置）。因此，他们减少了全文请求的依赖，让它逐渐地更加接近应用领域的开启。这允许应用领域的剩余部分在全文响应的同时进行调用。由于这些重构，他们赢得了显著的收益。根据他们在第一阶段的经验，他们继续把那个阶段分解成更小的部分。互联网请求/响应看起来像这样：

他们注意到，一旦请求正在排队，发送请求出去后就有一个时间间隔。这很好解释 — 在UAC中，互联网连接并不是一个开放的、安全的 TCP 连接。一个连接的建立须要三次握手，平均为几百毫秒。当全文请求第一次发送时，无法避免要花掉这些时间。长远来看，这可以通过缓存 SSL 证书来解决。但是再次强调，他们退回来的目的并不是为了发送 TCP 请求，而是为了从服务器通过任何可能的方式赢得请求信息。他们提出了一个创造性的解决方案 — UDP 开启。本质上，他们在通过 TCP 发送全文请求时，先发送一个编码过的包含全文请求的 UDP 包到服务器。这样做的目的是唤醒服务器更早地去获取和缓存数据。当真正的全文请求通过 TCP 到达时，服务器只需见到地从缓存内容中构造出响应，并发回应用领域程序。那个技术使得他们可以减少几百毫秒的耗时。当他们持续深入研究服务器端时，他们已经开始尝试采用层-取（story-fetching）策略。过去他们已经做了一批全文请求的 3+7 层。其原因很简单：下载次数和被下载的层成正比。因此，把请求分割成两块，允许已经开始的三层先进来，其余的七个随后进来。通过提升他们的基础设施，他们已经能够升级为 1+1+X 策略，这已经接近于流了。这样就减少了服务器必须处理第一层的时间，并且能够减少下载的时间，使得可以在最快的时间内与采用者交互。通过这样的努力，这样他们又减少了几百毫秒的耗时。Feed响应处理正如在前面提到的那样，他们以为在开启时会在这里花费大量的时间。但是那个想法被证明是错误的。更加使人好奇的是，他们注意到时间并没有花在处理和加工层上面。时间被花在运转应用领域服务和竞争资源上面。他们注意到这是他们强化互联网和服务器时间的副作用，因为全文请求返回得太早了。尽管大多数的服务是不重要的。因此，他们开发出一个简单的机制去序列化这些工作直到应用领域完成开启，并且采用先进先出的方式去执行。这样可以用更少的连接去处理所有层，大大地减少了赢得响应和展示在萤幕之间的时间。详细请看：Facebook APP Feed流的缓存强化实践经过强化后，图片读取慢或者读取失败的反馈少了将近90%。