2015年6月，我們?yōu)榘沧康男屡d市場推出了Facebook Lite。很高興如今這款應(yīng)用已經(jīng)攬收1億的月活躍用戶了。在不到9個月的時間里就發(fā)展出了1億用戶量，F(xiàn)acebook Lite當屬發(fā)展速度最快的Facebook版本。它的APK包僅有不到1MB，也就是說即便在慢速連接下，也只需數(shù)秒就能完成下載。這款應(yīng)用現(xiàn)在支持56種語言，在巴西、印度、印尼、墨西哥和菲律賓的使用率特別高。
　　為什么要做Facebook Lite
　　我們希望每個人在使用Facebook時都能獲得完美的體驗，無論是用的什么手機或是什么網(wǎng)絡(luò)，這一點非常重要。由于網(wǎng)絡(luò)狀況繁雜，手機硬件類型多樣，各人的體驗都會有所不同。盡管在全球范圍內(nèi)2G移動網(wǎng)絡(luò)的覆蓋率高達96%，全世界有一半人口都在使用2G網(wǎng)進行基本的數(shù)據(jù)連接，不過至少仍有16億人口所處的地方無法訪問高速移動網(wǎng)絡(luò)（3G和4G），導(dǎo)致數(shù)據(jù)連接非常困難。即便3G網(wǎng)也經(jīng)常由于連接的間斷性和不穩(wěn)定性這個最大的障礙，而無法提供優(yōu)秀的用戶體驗。
　　在針對新興市場和用戶使用Facebook的方式進行過研究之后，我們發(fā)現(xiàn)：用戶對于數(shù)據(jù)成本及流量使用量非常關(guān)心。因此，我們致力于減少流量消耗，為新興市場的用戶訪問Facebook提供便利。一方面繼續(xù)提高安卓Facebook在2G網(wǎng)絡(luò)下的體驗，一方面在2015年推出了Facebook Lite來解決這些限制。我們的目標是為新興市場的典型安卓手機及網(wǎng)絡(luò)的用戶發(fā)布一款輕量級、快速的原生Facebook應(yīng)用。
　　我們的目標
　　我們的任務(wù)歸結(jié)為如下目標：
　　保持APK包小于1MB。設(shè)計時將客戶端與服務(wù)器之間的數(shù)據(jù)交互減到最小，以便適應(yīng)2G環(huán)境。創(chuàng)建的應(yīng)用能在Gingerbread版本以及2009年的設(shè)備上運行。
　　架構(gòu)一覽
　　有了這些約束，我們選擇了客戶端層面很單薄的代理服務(wù)器架構(gòu)。我們使用了之前非常成功的Facebook For Every Phone架構(gòu)作為初始起點，并將其移植到Android手機上。
　　
　　為了達到想要的APK大小，Lite APK并未包含常見安卓應(yīng)用所包含的產(chǎn)品代碼與資源，Lite的客戶端使用了簡單的虛擬機來提供與OS的各種交互能力，比如讀取文件、打開攝像頭、創(chuàng)建SQLite數(shù)據(jù)庫等等；并通過渲染引擎來驅(qū)動安卓UI界面。產(chǎn)品代碼寫在服務(wù)器端，根據(jù)客戶端的性能來調(diào)整展現(xiàn)方式。按照不同的需求，將資源從服務(wù)器端發(fā)送到手機端，并緩存在手機客戶端中。因此，在不增加APK包內(nèi)容的情況下，就能構(gòu)建出可無限擴展的不同應(yīng)用了。
　　Lite的架構(gòu)在設(shè)計之初就讓服務(wù)器端承擔了大量的工作，使得這款應(yīng)用在低功率的設(shè)備上也能良好地運作（比如LG Optimus ME）。服務(wù)器端從Facebook的后臺服務(wù)器拿取數(shù)據(jù)資源，并按照類似DOM的壓縮UI樹形式，將屏幕顯示內(nèi)容發(fā)送給客戶端，再由客戶端進行渲染。在會話中，客戶端只和一個單獨的服務(wù)器通訊，并在請求數(shù)據(jù)時由這個服務(wù)器推送數(shù)據(jù)到客戶端。
　　Lite沒有使用HTTPS，而是采用了通過TLS發(fā)送的定制消息協(xié)議（直接通過TCP發(fā)送）。在會話期間，客戶端與服務(wù)器端通過持續(xù)的TLS連接來交換壓縮后的信息。這一設(shè)計為減少數(shù)據(jù)使用以及在2G網(wǎng)絡(luò)下運行的優(yōu)化留下了通道。
　　Lite有一組與CDN通訊同時存儲其他圖片的圖片服務(wù)器，通過它們按照具體尺寸為客戶端提供圖片。
　　達成目標
　　小型APK包
　　在2G網(wǎng)絡(luò)下，下載常見的20MB APK包需要30多分鐘，而且由于網(wǎng)絡(luò)本身的問題，很有可能在完成前就出現(xiàn)下載中斷的情況。限制APK包的大小會讓人們下載起來更容易，而且升級時所下載的數(shù)據(jù)量也更少。因此，我們特別關(guān)注了縮小應(yīng)用APK包大小的問題。前面提到過，這款應(yīng)用在設(shè)計時是將客戶端當作普通的虛擬機，將產(chǎn)品代碼放在服務(wù)器端。會填塞APK包大小的元素，比如字符串編譯及PNG資源等都是按照需求通過服務(wù)器端發(fā)送并緩存在客戶端中的，而不是內(nèi)置在APK包中。在不同地方展示圖標時，我們使用了Unicode符號而不是圖片資源，以便節(jié)省數(shù)據(jù)及縮減應(yīng)用的大小。
　　針對慢速連接和數(shù)據(jù)利用率進行優(yōu)化
　　對Lite的網(wǎng)絡(luò)協(xié)議棧優(yōu)化，目標是為了在2G下運行，并降低數(shù)據(jù)使用量。為了達到非常高效的數(shù)據(jù)利用率，我們沒有使用HTTPS，而是使用了通過TLS發(fā)送的定制消息協(xié)議（直接通過TCP發(fā)送）。在2G網(wǎng)絡(luò)下，最大的痛點之一就是連接建立非常慢，可能會需要好幾秒。而在Lite中，由于大多流量都是通過后端的單個連接傳輸?shù)模@種問題就能相對緩解。
　　而且由于客戶端是與同一臺服務(wù)器反復(fù)通訊的，在整個會話中，可以通過動態(tài)共享字典壓縮的形式來降低消息發(fā)送所消耗的數(shù)據(jù)量。我們使用了LZMA2來壓縮服務(wù)器與客戶端之間的消息，這種算法的壓縮率很高，解壓時需要的資源很少。在客戶端與服務(wù)器消息中我們還使用到了DEFLATE。
　　我們的工程師通過類似Augmented Traffic Control和Internet.org Innovation Lab之類的工具來模擬2G網(wǎng)絡(luò)信號進行測試。
　　應(yīng)用的大部分數(shù)據(jù)損耗來自圖片，因此這也是我們想要減少數(shù)據(jù)使用量的地方，控制圖片大小就能控制損耗的數(shù)據(jù)量。Lite服務(wù)器知道確切的屏幕尺寸以及分辨率，它不會直接與CDN通訊，而是通過同樣的TCP連接來獲取確切的圖片尺寸；服務(wù)器可以調(diào)整圖片質(zhì)量，將圖片修剪為所需大小，而不是采用CDN僅支持的幾種尺寸。對圖片尺寸及質(zhì)量的優(yōu)化使得很多圖片都很小，而對于較大的圖片，我們執(zhí)行了分塊傳說的形式。Lite的圖片服務(wù)器還為圖片提供緩存和轉(zhuǎn)碼機制。
　　由于客戶端只與一臺服務(wù)器通訊，服務(wù)器會在特定情況下預(yù)期并推送數(shù)據(jù)。Lite還包含diff機制，因此可以針對客戶端已經(jīng)接收到的屏幕進行比較，有輕微差別的圖片可以只發(fā)送diff內(nèi)容，而無需發(fā)送全屏內(nèi)容，這樣就能節(jié)省數(shù)據(jù)損耗。例如，如果執(zhí)行下拉刷新獲取新數(shù)據(jù)，在只有幾條消息變化的時候，服務(wù)器端就會只將不同的地方下發(fā)到客戶端。另外，如果某條內(nèi)容有新增評論，服務(wù)器可以通過diff機制只發(fā)送新增的評論（即便客戶端并未請求數(shù)據(jù)）。
　　在所有新興市場安卓設(shè)備上的表現(xiàn)情況
　　我們設(shè)立的目標就是讓Lite能在新興市場的設(shè)備上運作良好，即便是非常低功率的設(shè)備。像Samsung Galaxy Y這樣2009年的設(shè)備，只有290MB RAM，600MHz處理器和180MB的內(nèi)部存儲。根據(jù)數(shù)據(jù)顯示，對Gingerbread版本也是大頭?？蛻舳说募軜?gòu)已經(jīng)確保了將客戶端的CPU、存儲與RAM使用最小化，像屏幕布局之類的資源密集型任務(wù)都由Lite服務(wù)器端完成；并且避免動畫及其他重型UI交互。需要緩存的圖片和資源有數(shù)萬MB?？蛻舳思軜?gòu)采用措施，保證內(nèi)存使用量較低，并在后臺運行時釋放內(nèi)存。
　　這些設(shè)計讓Facebook Lite在低帶寬網(wǎng)絡(luò)中執(zhí)行登錄、啟動、下拉刷新、圖片載入等操作時都達到了一流的性能表現(xiàn)。
　　通過Facebook Lite，我們達成了盡可能為所有人提供最佳Facebook體驗的目標，無論他們使用的是什么設(shè)備，什么網(wǎng)絡(luò)連接。并且我們希望，通過分享構(gòu)建應(yīng)用的方式，能夠鼓勵更多人為下一批聯(lián)網(wǎng)的10億人做些應(yīng)用。
?