服务于所有手机、所有网络的安卓Facebook Lite是怎样打造出来的

原文： How we built Facebook Lite for every Android phone and network
作者： Gautam Roy
翻译： 孙薇

2015年6月，我们为安卓的新兴市场推出了Facebook Lite。很高兴如今这款应用已经揽收1亿的月活跃用户了。在不到9个月的时间里就发展出了1亿用户量，Facebook Lite当属发展速度最快的Facebook版本。它的APK包仅有不到1MB，也就是说即便在慢速连接下，也只需数秒就能完成下载。这款应用现在支持56种语言，在巴西、印度、印尼、墨西哥和菲律宾的使用率特别高。

为什么要做Facebook Lite

我们希望每个人在使用Facebook时都能获得完美的体验，无论是用的什么手机或是什么网络，这一点非常重要。由于网络状况繁杂，手机硬件类型多样，各人的体验都会有所不同。尽管在全球范围内2G移动网络的覆盖率高达96%，全世界有一半人口都在使用2G网进行基本的数据连接，不过至少仍有16亿人口所处的地方无法访问高速移动网络（3G和4G），导致数据连接非常困难。即便3G网也经常由于连接的间断性和不稳定性这个最大的障碍，而无法提供优秀的用户体验。

在针对新兴市场和用户使用Facebook的方式进行过研究之后，我们发现：用户对于数据成本及流量使用量非常关心。因此，我们致力于减少流量消耗，为新兴市场的用户访问Facebook提供便利。一方面继续提高安卓Facebook在2G网络下的体验，一方面在2015年推出了Facebook Lite来解决这些限制。我们的目标是为新兴市场的典型安卓手机及网络的用户发布一款轻量级、快速的原生Facebook应用。

我们的目标

我们的任务归结为如下目标：

保持APK包小于1MB。
设计时将客户端与服务器之间的数据交互减到最小，以便适应2G环境。
创建的应用能在Gingerbread版本以及2009年的设备上运行。

架构一览

有了这些约束，我们选择了客户端层面很单薄的代理服务器架构。我们使用了之前非常成功的Facebook For Every Phone架构作为初始起点，并将其移植到Android手机上。

为了达到想要的APK大小，Lite APK并未包含常见安卓应用所包含的产品代码与资源，Lite的客户端使用了简单的虚拟机来提供与OS的各种交互能力，比如读取文件、打开摄像头、创建SQLite数据库等等；并通过渲染引擎来驱动安卓UI界面。产品代码写在服务器端，根据客户端的性能来调整展现方式。按照不同的需求，将资源从服务器端发送到手机端，并缓存在手机客户端中。因此，在不增加APK包内容的情况下，就能构建出可无限扩展的不同应用了。

Lite的架构在设计之初就让服务器端承担了大量的工作，使得这款应用在低功率的设备上也能良好地运作（比如LG Optimus ME）。服务器端从Facebook的后台服务器拿取数据资源，并按照类似DOM的压缩UI树形式，将屏幕显示内容发送给客户端，再由客户端进行渲染。在会话中，客户端只和一个单独的服务器通讯，并在请求数据时由这个服务器推送数据到客户端。

Lite没有使用HTTPS，而是采用了通过TLS发送的定制消息协议（直接通过TCP发送）。在会话期间，客户端与服务器端通过持续的TLS连接来交换压缩后的信息。这一设计为减少数据使用以及在2G网络下运行的优化留下了通道。

Lite有一组与CDN通讯同时存储其他图片的图片服务器，通过它们按照具体尺寸为客户端提供图片。

达成目标

小型APK包

在2G网络下，下载常见的20MB APK包需要30多分钟，而且由于网络本身的问题，很有可能在完成前就出现下载中断的情况。限制APK包的大小会让人们下载起来更容易，而且升级时所下载的数据量也更少。因此，我们特别关注了缩小应用APK包大小的问题。前面提到过，这款应用在设计时是将客户端当作普通的虚拟机，将产品代码放在服务器端。会填塞APK包大小的元素，比如字符串编译及PNG资源等都是按照需求通过服务器端发送并缓存在客户端中的，而不是内置在APK包中。在不同地方展示图标时，我们使用了Unicode符号而不是图片资源，以便节省数据及缩减应用的大小。

针对慢速连接和数据利用率进行优化

对Lite的网络协议栈优化，目标是为了在2G下运行，并降低数据使用量。为了达到非常高效的数据利用率，我们没有使用HTTPS，而是使用了通过TLS发送的定制消息协议（直接通过TCP发送）。在2G网络下，最大的痛点之一就是连接建立非常慢，可能会需要好几秒。而在Lite中，由于大多流量都是通过后端的单个连接传输的，这种问题就能相对缓解。

而且由于客户端是与同一台服务器反复通讯的，在整个会话中，可以通过动态共享字典压缩的形式来降低消息发送所消耗的数据量。我们使用了LZMA2来压缩服务器与客户端之间的消息，这种算法的压缩率很高，解压时需要的资源很少。在客户端与服务器消息中我们还使用到了DEFLATE。

我们的工程师通过类似Augmented Traffic Control和Internet.org Innovation Lab之类的工具来模拟2G网络信号进行测试。

应用的大部分数据损耗来自图片，因此这也是我们想要减少数据使用量的地方，控制图片大小就能控制损耗的数据量。Lite服务器知道确切的屏幕尺寸以及分辨率，它不会直接与CDN通讯，而是通过同样的TCP连接来获取确切的图片尺寸；服务器可以调整图片质量，将图片修剪为所需大小，而不是采用CDN仅支持的几种尺寸。对图片尺寸及质量的优化使得很多图片都很小，而对于较大的图片，我们执行了分块传说的形式。Lite的图片服务器还为图片提供缓存和转码机制。

由于客户端只与一台服务器通讯，服务器会在特定情况下预期并推送数据。Lite还包含diff机制，因此可以针对客户端已经接收到的屏幕进行比较，有轻微差别的图片可以只发送diff内容，而无需发送全屏内容，这样就能节省数据损耗。例如，如果执行下拉刷新获取新数据，在只有几条消息变化的时候，服务器端就会只将不同的地方下发到客户端。另外，如果某条内容有新增评论，服务器可以通过diff机制只发送新增的评论（即便客户端并未请求数据）。

在所有新兴市场安卓设备上的表现情况

我们设立的目标就是让Lite能在新兴市场的设备上运作良好，即便是非常低功率的设备。像Samsung Galaxy Y这样2009年的设备，只有290MB RAM，600MHz处理器和180MB的内部存储。根据数据显示，对Gingerbread版本也是大头。客户端的架构已经确保了将客户端的CPU、存储与RAM使用最小化，像屏幕布局之类的资源密集型任务都由Lite服务器端完成；并且避免动画及其他重型UI交互。需要缓存的图片和资源有数万MB。客户端架构采用措施，保证内存使用量较低，并在后台运行时释放内存。

这些设计让Facebook Lite在低带宽网络中执行登录、启动、下拉刷新、图片载入等操作时都达到了一流的性能表现。

通过Facebook Lite，我们达成了尽可能为所有人提供最佳Facebook体验的目标，无论他们使用的是什么设备，什么网络连接。并且我们希望，通过分享构建应用的方式，能够鼓励更多人为下一批联网的10亿人做些应用。

（责编/钱曙光，关注架构和算法领域，寻求报道或者投稿请发邮件qianshg@csdn.net，交流探讨可加微信qshuguang2008，备注姓名+公司+职位）

「CSDN 高级架构师群」，内有诸多知名互联网公司的大牛架构师，欢迎架构师加微信qshuguang2008入群，备注姓名+公司+职位。