移動端開發網路最佳化建議

標籤：部分   system   伺服器   body   開發   增量   優先   頁面   列表   

一個網路請求可以簡單分為串連伺服器 -> 擷取資料兩個部分。
其中串連伺服器前還包括 DNS 解析的過程；擷取資料後可能會對資料進行緩衝。

一、串連伺服器最佳化策略

1. 不用網域名稱，用 IP 直連
省去 DNS 解析過程，DNS 全名 Domain Name System，解析意指根據網域名稱得到其對應的 IP 位址。
如 www.codekk.com 的網域名稱解析結果就是 104.236.147.76。

首次網域名稱解析一般需要幾百毫秒，可通過直接向 IP 而非網域名稱請求，節省掉這部分時間，同時可以預防網域名稱劫持等帶來的風險。

當然為了安全和擴充考慮，這個 IP 可能是一個動態更新的 IP 列表，並在 IP 不可用情況下通過網域名稱訪問。

2. 伺服器合理部署
伺服器多電訊廠商多地部署，一般至少含三大電訊廠商、南中北三地部署。

配合上面說到的動態 IP 列表，支援優先順序，每次根據地區、網路類型等選擇最優的伺服器 IP 進行串連。

對於伺服器端還可以調優伺服器的 TCP 擁塞視窗大小、重傳逾時時間(RTO)、傳輸單元最大值(MTU)等。

二、擷取資料最佳化策略

1. 串連複用
節省串連建立時間，如開啟 keep-alive。

對於 Android 來說預設情況下 HttpURLConnection 和 HttpClient 都開啟了 keep-alive。只是 2.2 之前 HttpURLConnection 存在影響串連池的 Bug，具體可見：Android HttpURLConnection 及 HttpClient 選擇

2. 請求合并
即將多個請求合并為一個進行請求，比較常見的就是網頁中的 CSS Image Sprites。
如果某個頁面內請求過多，也可以考慮做一定的請求合并。

3. 減小請求資料大小
(1) 對於 POST 請求，Body 可以做 Gzip 壓縮，如日誌。

(2) 對要求標頭進行壓縮
這個 Http 1.1 不支援，SPDY 及 Http 2.0 支援。
Http 1.1 可以通過服務端對前一個請求的要求標頭進行緩衝，後面相同要求標頭用 md5 之類的 id 來表示即可。

4. CDN 緩衝靜態資源
緩衝常見的圖片、JS、CSS 等靜態資源。

5. 減小返回資料大小
(1) 壓縮
一般 API 資料使用 Gzip 壓縮，是之前測試的 Gzip 壓縮前後對比圖。

(2) 精簡資料格式
如 JSON 代替 XML，WebP 代替其他圖片格式，回複 20 查看關於 WebP 的介紹。

(3) 對於不同的裝置不同網路返回不同的內容
如不同解析度圖片大小。

(4) 累加式更新
需要資料更新時，可考慮累加式更新。如常見的服務端進行 bsdiff，用戶端進行 bspatch。

(5) 大檔案下載
支援斷點續傳，並緩衝 Http Resonse 的 ETag 標識，下次請求時帶上，從而確定是否資料改變過，未改變則直接返回 304。

6. 資料緩衝
緩衝擷取到的資料，在一定的有效時間內再次請求可以直接從緩衝讀取資料。

關於 Http 緩衝規則 Grumoon 在 Volley 源碼解析最後雜談中有詳細介紹。

三、其他最佳化手段

這類最佳化方式在效能最佳化系列總篇中已經有過完整介紹
1. 預取
包括預串連、預取資料。

2. 分優先順序、延遲部分請求
將不重要的請求延遲，這樣既可以削峰減少並發、又可以和後面類似的請求做合并。

3. 多串連
對於較大檔案，如大圖片、檔案下載可考慮多串連。
需要控制請求的最大並發量，畢竟移動端網路受限。

四、監控

最佳化需要通過資料對比才能看出效果，所以監控系統必不可少，通過前後端的資料監控確定調優效果。  

移動端開發網路最佳化建議