Facebook Lite是怎樣打造出來的

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億人做些應用。
?