非死book：如何让应用适合所有系统、带宽以及屏幕
英文原文： How 非死book Makes Mobile Work At Scale For All Phones, On All Screens, On All Networks
如果你的移动应用程序只能在某个地区（比如 US）运行良好，那么该如何改善？在@scale conference 上，非死book 多次谈及了这个问题。那么如何才能设计出一个更适合用户需求的应用，这里我们看向 非死book 项目经理 Chris Marra 的 Developing Android Apps for Emerging Market 演讲视频综述。
在移动网络上，Chris 表示，因为地区差异，用户在网络连通性上存在着巨大的差异。USA 的 3G 覆盖率是 70%，平均延时为 280 毫秒。而在印度，3G 覆盖率是 6.9%，延时达 500 毫秒。在巴西，3G 覆盖率是 38.6%，延时则超过 850 毫秒。
同时，非死book 还在用户使用的设备上做过综合调研：不是所有用户的设备都很快，不是所有设备的屏幕都很大，同样不是所有人都在一个很快的网络下。结果显示，大部分用户使 用的设备都是 2011 年左右生产，双核心及拥有 1GB 以上的内存。开始时，非死book 应用只针对高端用户设计，因此那些低端设备拥有者的使用体验非常差。
为了满足这些用户的体验需求，非死book 专门建立了独立的应用——使用针对低端设备的轻量级动画等策略。而针对那些小屏幕手机的拥有者，非死book 更设计了匹配不同屏幕大小的应用程序。
当下，非死book 已经衍变为以产品为中心的架构：垂直团队负责对应的产品，而不是统一而论，比如，一个 Android 团队负责所有 Andriod 产品。当然，同样存在一个垂直团队，他们致力提升整个 Android 平台上的产品体验，深入研究这个平台的技术细节。
每个团队都负责终端到终端的性能，及所负责产品的可靠性。这里同样存在一个核心团队，负责关注、分析和帮助解决性能问题。
不管是核心团队还是产品团队都是必不可少的。核心团队善于检测和识别问题，并与产品团队一切合作来解决这些问题。对于移动开发来说，端到端的控 制整个产品至关重要，包括核心参与指标（core engagement metrics）、核心可靠性（core reliability）及核心性能指标（core performance metrics ），而核心性能指标又包括日常使用情况、冷启动时间及可靠性。
在如何解决网络性能瓶颈上，非死book Engineering Manager 发表了题为 Tuning 非死book for Constrained Networks 的讲话。Andrew 表示，解决这个问题主要从以下 3 个方面着手：Image Download Sizes，Network Quality Detection，Prefetching Content。
总体来说，在 非死book 规模，面面俱到并不是一件容易的事情。用户设备不只是覆盖 Andriod 和 iOS 两个领域，工程师必须针对各种手机进行对应的设计。
减少图片大小——JPEG 降低 30%，PNG 降低 80%
大部分从 非死book 应用程序下载的数据都是图像：占 Android 设备下载总数据的 85%，占 非死book Messenger 下载总数据的 65%。因此，缩减图像的体积可以减少客户端的下载量，从而减少下载时间，特别有益于高延时网络。
为显示层返回一个适当大小的图片
1. 在服务器上压缩大小。杜绝给客户端发送大的图片，然后让客户端去压缩。这将浪费大量的带宽，并且占用更多时间。
2. 发送一个缩略图（用于描述图片）以及一个预览图片（比如 newsfeed），在用户要求访问后再发送完全体积的图片。同时在大部分情况下，用户的需求也只是一个缩略图或者一个小图片。
3. 随着屏幕的变大，图片缩放并不如以往那么效率，但是仍然可为，区别只是回报不同而已。
改变图片的格式
- 90% 发送到安卓的 非死book 和 Messenger 图片都会被转换成 WebP 格式。
- WebP 格式 2010 年由谷歌发布。
- 同等质量下 WebP 节省 JPEG 格式7% 的下载体积。
- 质量和参数调优后，在无明显差异下节省 JPEG 格式 30% 的下载体积。
- WebP 同样支持透明度和动画，这个特性被用于 Stickers 产品。
- 在相对旧的安卓设备上，图片会通过 WebP 传输，而在客户端上会被转码成 JPEG 用于渲染。
网络质量检测——特定网络相对的调整
1. 同等网络制式下（2G、3G、LTE、WiFi 等），US 的网络速度会是印度和巴西的两到三倍。
2. LTE 通常情况下会快于 WIFI，因此你不能只基于传输技术的速度做调整。
3. 为客户端添加以下功能
- 测量所有大型传输的吞吐量
- 非死book 服务器在每个响应的 HTTP header 中提供了一个 Round Trip Time（RTT）估算。
- 客户端会测量传输的平均吞吐量和 RTT 时间，从而确定对应网络的质量。
4. 连接质量被分为以下几组：150kbps 以下的“Poor”、150-600kbps 的“Moderate”、600-2000kbps 的“Good”以及大于 2000kbps 的“Excellent”。
5. 功能开发人员可以根据网络的质量来调整行为。
6. 基于质量问题存在的一些调整：
- 增加/减少压缩。
- 调整并行网络请求数量，不会占用全部带宽。
- 禁用/允许自动播放视频，不要在慢的网络下造成更多的数据传输。
- 预取更多的内容。
7. 非死book 开发了 Air Traffic Control 工具以支持不同流量的配置文件模拟，每个配置文件可设置的参数包括 bandwidth、packet loss、packet loss-correlation、delay、delay correlation、delay jitter。
预取内容
- 在内容被真正需要之前建立请求并传输。
- 在高延时下，预取内容非常重要，因为用户在漫长的等待中能得到的只是一个空白屏幕。
- 在应用程序启动的过程中为 feeds 建立请求，因此在 feed 展示时所有数据都会就绪，数据下载的过程可以与其他初始化任务并行发生。
- 为网路请求保存一个优先级队列，不要因为后台网络请求阻塞前台的网络请求，或者因为用户看不到的数据而影响用户当前感兴趣的数据。
- 监视过度获取以及设备资源的过度消耗。过度获取可能耗尽磁盘空间，或者耗费大量的用户流量。
前台参数
- 客户端上传到服务器。这里的思想是尽量上传更少的数据到服务器，这就意味着在发送到服务器之前调整图片的大小。如果上传重试失败的很快，通常是因为网络问题。
- 非死book App 大概有 20 个不同的 APK（Andriod 应用程序包），主要基于 API 等级、屏幕大小和处理器架构。