Android開發如何進行網路優化？

01-03

volley，Android-Universal-Image-Loader，等網路框架，網路請求部分都是封裝的httpurlconnection，那麼問題來了，不從封裝的角度，如何優化android網路？

謝邀，很早前就想把零碎的思緒整理下，一直比較忙就拖到了這個問題的邀請，然後拖到了今天。

這篇文章首發在微信公眾號 codeKK 移動端網路優化

一個網路請求可以簡單分為連接伺服器 -&> 獲取數據兩個部分。

其中連接伺服器前還包括 DNS 解析的過程；獲取數據後可能會對數據進行緩存。

一、連接伺服器優化策略

1. 不用域名，用 IP 直連

省去 DNS 解析過程，DNS 全名 Domain Name System，解析意指根據域名得到其對應的 IP 地址。如 codeKK 開源項目源碼分析的域名解析結果就是 104.236.147.76。

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

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

2. 伺服器合理部署

伺服器多運營商多地部署，一般至少含三大運營商、南中北三地部署。

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

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

二、獲取數據優化策略

1. 連接復用

節省連接建立時間，如開啟 keep-alive。

Http 1.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 代替其他圖片格式。關注公眾號 codekk，回復 20 查看關於 WebP 的介紹。

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

(4) 增量更新

需要數據更新時，可考慮增量更新。如常見的服務端進行 bsdiff，客戶端進行 bspatch。

(5) 大文件下載

支持斷點續傳，並緩存 Http Resonse 的 ETag 標識，下次請求時帶上，從而確定是否數據改變過，未改變則直接返回 304。

6. 數據緩存

緩存獲取到的數據，在一定的有效時間內再次請求可以直接從緩存讀取數據。

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

三、其他優化手段

這類優化方式在性能優化系列總篇中已經有過完整介紹

1. 預取

包括預連接、預取數據。

2. 分優先順序、延遲部分請求

將不重要的請求延遲，這樣既可以削峰減少並發、又可以和後面類似的請求做合併。

3. 多連接

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

四、監控

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

註：伺服器部署方面的優化有參考手 Q 和 QZone 去年的技術分享。

本文為性能優化系列第四篇，目前性能調優專題已完成以下部分：

性能優化總綱——性能問題及性能調優方式

性能優化第四篇——移動網路優化

性能優化第三篇——代碼優化

性能優化第二篇——布局優化

性能優化第一篇——資料庫性能優化

Android 性能調優工具 TraceView

性能優化實例

我來說點高大上的：用機器學習來做Android/iOS應用的網路優化，也就是TwinPrime。

TwimPrime是一家美國創業公司，國內媒體唯一一次關注它也就是它融資950萬刀的故事，我給大家講講它究竟為啥能拿到這筆錢，以及它背後的故事。

電梯演講時間

TwimPrime解決了移動網路「最後一英里」的交付問題。下面我大概解釋下。

當前移動設備使用率超過PC已成共識，但移動設備的網路性能比之PC糟糕許多。對移動網路進行優化已是必然趨勢。傳統的網路優化手段之一就是CDN, 依靠部署在各地的邊緣伺服器，通過中心平台的分發調度，使用戶就近獲取所需內容，降低網路擁塞，提高用戶訪問速度。然而這一切在無線時代卻存在硬傷，移動網路之所以這麼慢，其實是移動運營商到移動設備之間的網路性能瓶頸導致的。根據統計70%的延遲都發生在這所謂的最後一英里，目前的CDN方案解決不了這個問題。

為什麼不是CDN?

CDN其實是PC時代的產物，PC相較移動設備的特徵之一就是穩定，你家的電腦不會跟著你到處走，它的網路也因此相對穩定，電腦的性能也比手機強，也不像手機種類那麼分化，而手機則不一樣，它有WIFI及各種運營商的場景，它的位置在不斷變化，設備與操作系統也種類繁多。

TwinPrime怎麼work?

集成TwinPrime SDK到你的App，它通過修改底層網路通訊基礎庫，定期上傳最新的設備信息給TwinPrime伺服器，TwimPrime根據你的設備，操作系統，位置，運營商的信息，不斷優化推薦當前它認為最佳的內容轉發通道給App, 使得後續App的訪問速度都通過TwimPrime的轉發得以優化，從而大幅度優化最終訪問速度。

看兩張圖來直觀理解下。這是移動互聯網時代面臨的挑戰：

TwimPrime的解決方案：

與CDN的關係

技術接入

具體到Android SDK的集成，其實有兩種選擇，一種是android自帶的HttpUrlConnection, 一種是OkHttp, 是的，你沒有猜錯，它需要我們用TwinPrime包裝過的的 HttpUrlConnection, OKHttp替換原生的，從而修改通信部分，同時也支持Picasso，支持圖片訪問的性能優化，視頻也有對應的支持方案。

要錢不？

你又猜對了，他是要收費的，目前有一個月的免費試用，試用期後要收費。那你肯定會嘀咕，他怎麼證明真的對我們的網路優化有幫助？有多大幫助？我已經就這個問題與TwinPrime的CTO互相交換了意見: ) 他表示收費前會幫我們調優網路，並做足夠的A/B測試，提供測試數據以打消我們的疑慮。在最近一次的試用中發現它們有少量Crash, 他們已經快速修復並且提供了最新版的SDK, 目前我們打算繼續嘗試中。。。

最後我們的應用雖然主要在海外，但他號稱是支持全球的，所以理論上中國也是地球不可分割的一部分是吧？

最近在運營一個Android開發的公眾號，也開始在知乎答題，話說這個問題發布好久了，我現在是不是在挖墳啊，估計沒什麼人關注了，要是大家感興趣的話，就幫忙點贊喲，我可以多聊一些相關話題，也歡迎大家去關注我的微信公眾號AndroidTrending，主要關注Android最佳實踐，做技術有捷徑，少走彎路即是。

可以參考Google Android開發指導

http://hukai.me/android-training-course-in-chinese/connectivity/efficient-downloads/index.html

代碼上也就那樣了，重要是整體的邏輯規劃，什麼時候請求網路，返回怎樣的數據，後續怎麼操作對於Trinea說的也就兩點可用：規劃邏輯在合理的時候請求合理的數據做合理的操作和緩存，其他基本沒啥實質性可用的。只有一點：不用域名，用 IP 直連強烈不推薦。

就android這天天發新版，只能說，優化的越多，悲劇來的越快