非死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 等級、屏幕大小和處理器架構。