Facebook：如何让应用适合所有系统、带宽以及屏幕

Facebook：如何让应用适合所有系统、带宽以及屏幕

在Facebook规模下，想在所有设备上保持一个完美的体验并不容易。基于设备屏幕大小、性能高低及网络带宽不同，他们需要做大量的调整。这里，我们看Facebook在@scale大会上的分享。

如果你的移动应用程序只能在某个地区（比如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。

 

视频请访问上文链接（YouTube） 

总体来说，在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等级、屏幕大小和处理器架构。