Facebook：如何让应用适合所有系统、带宽以及屏幕_最新动态_新闻资讯_程序员俱乐部

　　英文原文： How Facebook Makes Mobile Work At Scale For All Phones, On All Screens, On All Networks

　　如果你的移动应用程序只能在某个地区（比如 US）运行良好，那么该如何改善？在@scale conference 上，Facebook 多次谈及了这个问题。那么如何才能设计出一个更适合用户需求的应用，这里我们看向 Facebook 项目经理 Chris Marra 的 Developing Android Apps for Emerging Market 演讲视频综述。

Youtube

　　在移动网络上，Chris 表示，因为地区差异，用户在网络连通性上存在着巨大的差异。USA 的 3G 覆盖率是 70%，平均延时为 280 毫秒。而在印度，3G 覆盖率是 6.9%，延时达 500 毫秒。在巴西，3G 覆盖率是 38.6%，延时则超过 850 毫秒。

　　同时，Facebook 还在用户使用的设备上做过综合调研：不是所有用户的设备都很快，不是所有设备的屏幕都很大，同样不是所有人都在一个很快的网络下。结果显示，大部分用户使用的设备都是 2011 年左右生产，双核心及拥有 1GB 以上的内存。开始时，Facebook 应用只针对高端用户设计，因此那些低端设备拥有者的使用体验非常差。

　　为了满足这些用户的体验需求，Facebook 专门建立了独立的应用——使用针对低端设备的轻量级动画等策略。而针对那些小屏幕手机的拥有者，Facebook 更设计了匹配不同屏幕大小的应用程序。

　　当下，Facebook 已经衍变为以产品为中心的架构：垂直团队负责对应的产品，而不是统一而论，比如，一个 Android 团队负责所有 Andriod 产品。当然，同样存在一个垂直团队，他们致力提升整个 Android 平台上的产品体验，深入研究这个平台的技术细节。

　　每个团队都负责终端到终端的性能，及所负责产品的可靠性。这里同样存在一个核心团队，负责关注、分析和帮助解决性能问题。

　　不管是核心团队还是产品团队都是必不可少的。核心团队善于检测和识别问题，并与产品团队一切合作来解决这些问题。对于移动开发来说，端到端的控制整个产品至关重要，包括核心参与指标（core engagement metrics）、核心可靠性（core reliability）及核心性能指标（core performance metrics ），而核心性能指标又包括日常使用情况、冷启动时间及可靠性。

　　在如何解决网络性能瓶颈上，Facebook Engineering Manager 发表了题为 Tuning Facebook for Constrained Networks 的讲话。Andrew 表示，解决这个问题主要从以下 3 个方面着手：Image Download Sizes，Network Quality Detection，Prefetching Content。　　

　　总体来说，在 Facebook 规模，面面俱到并不是一件容易的事情。用户设备不只是覆盖 Andriod 和 iOS 两个领域，工程师必须针对各种手机进行对应的设计。

　　减少图片大小——JPEG 降低 30%，PNG 降低 80%

　　大部分从 Facebook 应用程序下载的数据都是图像：占 Android 设备下载总数据的 85%，占 Facebook Messenger 下载总数据的 65%。因此，缩减图像的体积可以减少客户端的下载量，从而减少下载时间，特别有益于高延时网络。

　　为显示层返回一个适当大小的图片

　　1.   在服务器上压缩大小。杜绝给客户端发送大的图片，然后让客户端去压缩。这将浪费大量的带宽，并且占用更多时间。

　　2.  发送一个缩略图（用于描述图片）以及一个预览图片（比如 newsfeed），在用户要求访问后再发送完全体积的图片。同时在大部分情况下，用户的需求也只是一个缩略图或者一个小图片。

　　3.   随着屏幕的变大，图片缩放并不如以往那么效率，但是仍然可为，区别只是回报不同而已。

　　改变图片的格式

• 90% 发送到安卓的 Facebook 和 Messenger 图片都会被转换成 WebP 格式。
• WebP 格式 2010 年由谷歌发布。
• 同等质量下 WebP 节省 JPEG 格式7% 的下载体积。
• 质量和参数调优后，在无明显差异下节省 JPEG 格式 30% 的下载体积。
• WebP 同样支持透明度和动画，这个特性被用于 Stickers 产品。
• 在相对旧的安卓设备上，图片会通过 WebP 传输，而在客户端上会被转码成 JPEG 用于渲染。

　　网络质量检测——特定网络相对的调整

　　1.  同等网络制式下（2G、3G、LTE、WiFi 等），US 的网络速度会是印度和巴西的两到三倍。

　　2.   LTE 通常情况下会快于 WIFI，因此你不能只基于传输技术的速度做调整。

　　3.   为客户端添加以下功能

• 测量所有大型传输的吞吐量
• Facebook 服务器在每个响应的 HTTP header 中提供了一个 Round Trip Time（RTT）估算。
• 客户端会测量传输的平均吞吐量和 RTT 时间，从而确定对应网络的质量。

　　4.  连接质量被分为以下几组：150kbps 以下的“Poor”、150-600kbps 的“Moderate”、600-2000kbps 的“Good”以及大于 2000kbps 的“Excellent”。

　　5.  功能开发人员可以根据网络的质量来调整行为。

　　6.  基于质量问题存在的一些调整：

• 增加/减少压缩。
• 调整并行网络请求数量，不会占用全部带宽。
• 禁用/允许自动播放视频，不要在慢的网络下造成更多的数据传输。
• 预取更多的内容。

　　7.  Facebook 开发了 Air Traffic Control 工具以支持不同流量的配置文件模拟，每个配置文件可设置的参数包括 bandwidth、packet loss、packet loss-correlation、delay、delay correlation、delay jitter。

　　预取内容

• 在内容被真正需要之前建立请求并传输。
• 在高延时下，预取内容非常重要，因为用户在漫长的等待中能得到的只是一个空白屏幕。
• 在应用程序启动的过程中为 feeds 建立请求，因此在 feed 展示时所有数据都会就绪，数据下载的过程可以与其他初始化任务并行发生。
• 为网路请求保存一个优先级队列，不要因为后台网络请求阻塞前台的网络请求，或者因为用户看不到的数据而影响用户当前感兴趣的数据。
• 监视过度获取以及设备资源的过度消耗。过度获取可能耗尽磁盘空间，或者耗费大量的用户流量。

　　前台参数

• 客户端上传到服务器。这里的思想是尽量上传更少的数据到服务器，这就意味着在发送到服务器之前调整图片的大小。如果上传重试失败的很快，通常是因为网络问题。
• Facebook App 大概有 20 个不同的 APK（Andriod 应用程序包），主要基于 API 等级、屏幕大小和处理器架构。