前言：為什么網絡優化比別人慢？優化那些還不夠？應該加強哪里？
1.Android應用為什么需要考慮網絡優化，主要基于以下幾個原因：
- 流量：App的移動網絡流量消耗對用戶來說是比較敏感的；
- 電量：網絡請求對電量的消耗是比較大的，影響手機的待機時間；
- 用戶體驗：網絡請求是耗時操作，如果App請求等待時間長，會給用戶網絡卡, 應用反應慢的感覺。
網絡請求優化的目的是盡可能地減少用戶等待的時間、減少用戶的流量使用、減少對手機電量的消耗，最終達到提升用戶體驗。
2.網絡性能優化主要從如下幾個方面著手：
- 流量消耗
- 網絡速度
- 獲取數據優化
- 接口設計
- 弱網優化
一丶流量消耗優化
所謂流量優化，就是在保證數據正確的前提下，如何保證盡可能地少消耗用戶流量。雖然現在的流量費用越來越便宜，但是減少流量本身并不是最重要的目的，而是提升用戶體驗帶來的結果。
1.使用本地緩存，減少網絡請求
分為幾種情況：
- 基本數據：可以使用持久化技術，比如本地數據庫，sharedPreference，本地文件，來記錄之前請求下來的數據。而且具有一定的過期時效來保證數據的可用性。
- 圖片：同樣的，在本地緩存和此圖片url映射的圖片，可以避免圖片的網絡請求。目前很多優秀的圖片加載框架，如Glide，Picasso，Fresco都具備這種能力。
- 文件：如一般的文件，webview里的js，css，html等，當然也要注意過期時效。
2.合理合并api接口，減少網絡請求
這種方案可以使得多次網絡請求合并為一次，減少網絡連接來回往返的等待時長。
比如有一種場景：App 本地數據庫緩存有N個表，當老用戶卸載重裝時，首次檢查需要把遠端的數據一次性download到本地來，保證兩端的一致性。
由于之前必然為每個表設計了一個api，但是在這種場景下，如果還是繼續使用這些api的話，就需要N次網絡請求，結果不僅會造成N次網絡I/O和磁盤寫入I/O，還會使得服務端查找性能降低，用戶等待時間較長，本地磁盤寫入性能降低。
針對這種場景，完全可以設計一個bulk sync api把這些api整合為一個，這樣一來客戶端只需一次網絡I/O即可獲取所有數據，服務端查找性能也提升了一個數量級，本地磁盤I/O也可以把此次返回的數據當成一次事務一次性插入數據庫中，大大減少了用戶等待時間，同時也提升了網絡和本地磁盤寫入性能。
3.減少網絡請求的數據量
當網絡請求不可避免的情況下，此時就要考慮如何減少網絡請求攜帶的數據量。
同樣也分幾種情況：
- 基本數據：使用數據壓縮方式，比如protoBuff格式，okhttp開啟gzip壓縮，支持Http 2.0，使用其頭部壓縮，二進制格式替代Http 1.1 文本格式的特性。
- 圖片：當不得不獲取一張本地緩存沒有的圖片時，就不得不請求服務端獲取。此時沒有必要使用最高清的大尺寸的原始圖片，完全可以針對客戶端顯示的圖片尺寸和屏幕密度，向服務器請求較小的尺寸，和較低質量的圖片，服務器通過圖片處理，返回符合此參數的圖片給客戶端進行顯示。
- 文件：普通文件可以進行zip打包下發，而如webview需要加載的css，js，html還可以事先使用webpack壓縮，然后再zip打包下發。
二.丶速度優化
在進行網絡流量優化的同時；由于網絡請求次數；請求攜帶的數據量變少了；這其實也是在變相地提高網絡速度。
另外，還有其他一些方式：
- 如okhttp中復用網絡連接的方法，當網絡請求等待隊列中的host和之前的某個結束的請求連接host一致，此時可以直接讓此請求復用此網絡連接。
- 使用http 2.0的多路復用特性，我們都知道在http 2.0中，使用了stream的概念，使得多個網絡請求可以并行發送，不再需要等待上一次請求響應回來再發送下一個請求，從而有效避免了網絡請求的排隊，提升了整體網絡請求速度。
- 當有網絡數據需要具備一定的實時性，可以使用長連接方式，比如websocket，http 2.0的方式進行推送，避免通過網絡輪詢的方式來達到，這樣不僅實時性高，而且減少了網絡請求次數，提升了用戶體驗。
三丶獲取數據優化
- 連接復用：節省連接時間，如開啟keep-alive。Android中HttpUrlConnection默認是開啟的。
- 請求合并：可以將多個請求合并為一個進行請求。
- 減小請求數據，并壓縮：對于post請求，Body可以做Gzip壓縮，如日志。
- 精簡數據格式：對于后臺返回的數據，盡量使用Json來代替XML。
- 數據的增量更新
四丶接口設計
1.API設計
App與Server之間的API設計要考慮網絡請求的頻次, 資源的狀態等. 以便App可以以較少的請求來完成業務需求和界面的展示。
- 例如, 注冊登錄. 正常會有兩個API, 注冊和登錄, 但是設計API時我們應該給注冊接口包含一個隱式的登錄. 來避免App在注冊后還得請求一次登錄接口(有可能失敗, 從而導致業務流程失敗)
- 再例如, 上文提到的獲取repo詳情, 實際上請求了4個接口, 請求了repo的信息, forks列表, contributors列表, readme, 這是因為github提供的接口是盡量單一職責的. 然而在我們的實際開發中, 我們的Server除了提供這些單一職責的小接口外, 最好還能組合一個滿足客戶端業務需求的repo詳情接口出來。
2.Gzip壓縮
使用Gzip來壓縮request和response, 減少傳輸數據量, 從而減少流量消耗。
考慮使用Protocol Buffer代替JSON
從前我們傳輸數據使用XML, 后來使用JSON代替了XML, 很大程度上也是為了可讀性和減少數據量(當然還有映射成POJO的方便程度)。
Protocol Buffer是google推出的一種數據交換格式。
如果我們的接口每次傳輸的數據量很大的話, 可以考慮下protobuf, 會比JSON數據量小很多。當然相比來說, JSON也有其優勢, 可讀性更高。
3.圖片的Size
上面Network Monitor中看到的22s到27s之間的有多次請求, 且數據量還很大. 就是在獲取圖片資源。圖片相對于接口請求來說, 數據量要大得多. 故而也是我們需要優化的一個點。
我們可以在獲取圖片時告知服務器需要的圖片的寬高, 以便服務器給出合適的圖片, 避免浪費。現在很多公司的圖片資源都是使用第三方的云存儲服務的(七牛, 阿里云存儲之類的)
以七牛為例, 可以在請求圖片的url中添加諸如質量, 格式, width, height等path來獲取合適的圖片資源:
五丶弱網優化
1.弱網標準
百度其中就有使用的是一個循序漸進的過程，通過三個階段來建立一個弱網標準。
- 第一階段，線下測試：
- 獲取預期的閾值，在測試App網絡切換、DNS故障時，抓取這些數據
- 第二階段，線上進行驗證：
- 通過線下獲取到的閾值，在線上可以獲取到弱網的比例，找到會出現弱網的場景，進行診斷優化。（比如網絡體驗最好的微信，也只是在信令的傳輸上優化到極致）
- 第三階段，線上反復試驗：
- 通過反復試驗來調整閾值，使得優化更接近業務層。
- 騰訊的做法也大同小異，都是根據2.2的指標進行數據收集，整理一套達到弱網時的數據標準。但是我們該如何去探測這些數據呢？這需要我們實現一套完整的網絡探測架構。
2.弱網檢測
網絡探測是弱網檢測的基礎，目標是能夠即時、正確的檢測出網絡質量，我們把網絡探測分成兩個部分，主動網絡探測和被動網絡采集。
3.主動網絡探測
主動檢測，就是在觸發了某些特定條件后，主動的進行網絡檢測，并按照一定的條件檢查出是否為弱網狀態。架構圖如下所示：
4.弱網優化
利用工具模擬弱網, 在弱網情況下體驗我們的App. 一般來說, 網絡延遲在60ms內, 是OK的, 超過200ms就比較糟糕了. 我們需要做的是在比較糟糕的網絡環境下還能給用戶較好的體驗。
弱網優化, 本質上是在弱網的情況下能讓用戶流暢的使用我們的App. 我們要做的就是結合上述的優化項:
- 壓縮/減少數據傳輸量
- 利用緩存減少網絡傳輸
- 針對弱網(移動網絡), 不自動加載圖片
- 界面先反饋, 請求延遲提交 例如, 用戶點贊操作, 可以直接給出界面的點贊成功的反饋, 使用JobScheduler在網絡情況較好的時候打包請求
五丶結尾
網絡優化，是App優化中相當重要的一項優化. 除了客戶端, 接口的優化外, 很多一部分優化還依賴于服務器端, 包括服務器端的代碼開發, 部署方式等。看到這里想必大家心里應該都知道，應該學習哪塊；哪里學習不夠；和別人的區別在哪吧。
自己也是從事Android開發5年有余了；整理了一些Android開發技術核心筆記和面經題綱，如有需要的同學請私信我回復“核心筆記”或“面試”領取！
