Facebook和Instagram的经验：面向新兴市场改进Android开发_最新动态_新闻资讯_程序员俱乐部

　　英文原文：Facebook & Instagram Lessons on Android Development for Emerging Markets

　　在@Scale 2014大会上，来自 Facebook 和 Instagram 的工程师做了题为《Scaling Android Apps for Emerging Markets》的演讲，就如何面对不同的 Android 设备和不同的网络连接速度改进其应用的表现分享了相关经验。

　　Facebook

　　Facebook 将团队送到了亚洲、非洲、中美洲和南美洲的一些国家，去评估当地的手机市场。他们购买和使用了当地流行的设备，以了解在这些设备上访问 Facebook 的应用时的用户体验。Chris Marra 是 Facebook 的 Android 开发产品经理，他就这些新兴市场中 Android 设备和网络连接情况分享了一些发现：

• 通常访问 Facebook 的设备模型有 10 000 种左右
• 在发展中国家，有两种占据统治地位的移动设备：功能机和低端入门级 Android 手机
• 这些设备通常是使用上一代硬件制作的
• 互联网连接还属于高级服务，存在网络堵塞
• 手机较慢，屏幕较小，网络连接状况往往比较差
• 美国的 3G 网络覆盖率达 70%，而像巴西和印度，覆盖率分别是 38% 和7% 

　　在给这些市场把过脉之后，Facebook 就开始改进其应用了。他们发现，因为内存有限，经常会导致 OutOfMemory 错误，使用较老手机的用户碰到应用崩溃的情形明显要多得多，所以他们决定提供一个不同的版本，以确保应用在这类设备上运行更平滑。因为用户在较老的手机上体验不好，Facebook 不得不砍掉了动画和其他很耗 CPU 的界面操作。

　　在看到了应用在某些低端手机上的表现情况之后，Facebook 创建了一些工具，帮助团队了解存在的问题，同时开始改进在这类设备上的用户体验。屏幕大小是必须考虑的一个因素，10% 的 Facebook 用户使用的是分辨率较低（120 DPI）的手机。开发团队决定裁剪用户界面，去掉或者简化窗口小部件（widget）和图标。

　　Facebook 的工程经理 Andrew Rogers，详细介绍了他们为改进用户体验所做的一些步骤。

　　图片大小。在 Facebook 的 Android 应用上，图片数据占到了 85%。在 Facebook Messenger 应用中，图片数据占到了网络传输数据量的 65%。应该尽可能减小图片大小。这是通过如下手段实现的：

• 在服务器上调整图片大小
• 提供分辨率不同的多份图片：用于新闻摘要（feed）的预览图、用于个人信息显示的缩略图和用于照片存储的较大的图
• 根据屏幕大小下载小型图片
• 只有用户放大的时候才使用全尺寸图片；大部分时间，用户只需要较小的缩略图或预览图
• 在 Android 上，90% 的图片使用 WebP 格式，与 JPEG 格式相比，质量相同的图片大小要小 30%。存在的问题是，Android 4.2+ 才提供了对 WebP 的原生支持，所以之前的 Android 版本上，还需要在设备上将图片转码成 PNG 或 JPEG

　　网络质量。Facebook 意识到，根据网络类型来确定网络速度还不够。尽管使用的是同样的技术，如 Edge、HSPA 或 LTE 等，某些国家的网络速度可能会比其他国家慢 2 到 3 倍。像印度或巴西，WiFi 的速度要比 LTE 慢，所以最好动态确定真实的网络速度。

　　为减少下载时间，他们决定：

• 进一步压缩图片
• 发出更多并行的请求
• 关闭自动播放
• 预取更多内容 

　　为了能够在部署之前在不同的网络上测试其应用，Facebook 创建了 Air Traffic Control 这款工具来模拟 WiFi 上的不同网络连接类型，它能够配置最大带宽、丢包率、上行线路/下行线路的往返时延。

　　预取内容。Rogers 提到的另一个改进用户体验的方式是预取某些内容。对于延迟较高的网络，这特别有用。但是预取也不能过度使用，因为这会填充缓存，再就是预取的数据不能肯定会用到。

　　Instagram

　　Tyler Kieft 是 Instagram 的一位 Android 开发工程师，他介绍了他们团队为改进其 Android 应用的性能和用户体验所做的一些调整。其一是使用现代的扁平式设计重写了界面，去掉了渐变效果、抛光色彩和阴影等，这在各种 Android 设备上都带来了性能提升。

　　扁平化设计还带来了一个效果，实现了资源裁剪。应用不再需要各种颜色的资源，而是只有一种颜色即可。Instagram 将应用的一个视图所需要的资源从 29 个减少到了 8 个。其结果是，UI 显示提速，占用的内存空间减少，冷启动时间下降了 120 毫秒。此外，用户对于新的界面和性能改进反应非常积极。

　　据 Kieft 介绍，为确定哪里比较慢，他们使用 Android Traceview 和计时语句分析了应用的性能。 然后采用了下列措施：

• 从冷启动路径中去掉较慢的东西
• 重写了较慢的代码
• 将一些东西延迟到一个后台线程中
• 重复以上步骤（分析、重写）

　　他们还使用了两步的惰性加载：在 UI 线程上创建单件（singleton）对象，但是在这些对象上执行的动作，比如访问 cache 的磁盘存储信息、加载 HTTP 客户端的证书和反序列化 cookies 等，都放到了一个后台线程上。

　　另一个减少应用冷启动时间的手段是，使用原生代码代替 WebView，在不同版本的 Android 上，平均节省了 30% 的时间。