利用 Network Profiler 檢查網(wǎng)絡(luò)流量
-
接口設(shè)計
-
API設(shè)計
App 與 Server 之間的 API 設(shè)計要考慮網(wǎng)絡(luò)請求的頻次，資源的狀態(tài)等。以便 App 可以以較少的請求來完成業(yè)務(wù)需求和界面的展示。
比如注冊登錄一般會有兩個 API，但是設(shè)計 API 時應(yīng)該給注冊接口包含一個隱式的登錄。來避免 App 在注冊后還得請求一次登錄接口(有可能失敗，從而導(dǎo)致業(yè)務(wù)流程失敗)。
比如有些請求可能包含了幾種小請求，可以單獨設(shè)計個接口，減少請求次數(shù)。
-
Gzip 壓縮
使用 Gzip 來壓縮 request 和 response，減少傳輸數(shù)據(jù)量，從而減少流量消耗。
考慮使用 Protocol Buffer/flatBuffer 代替 JSON
-
圖片的 Size
圖片相對于接口請求來說，數(shù)據(jù)量要大得多。故而也是需要優(yōu)化的一個點?？梢栽讷@取圖片時告知服務(wù)器需要的圖片的寬高，以便服務(wù)器給出合適的圖片，避免浪費。以七牛為例，可以在請求圖片的 url 中添加諸如質(zhì)量，格式，width，height 等 path 來獲取合適的圖片資源。對于不同的設(shè)備不同網(wǎng)絡(luò)返回不同的內(nèi)容不同分辨率圖片。
-
增量更新
需要數(shù)據(jù)更新時，可考慮增量更新。如常見的服務(wù)端進行 bsdiff，客戶端進行 bspatch。
-
大文件下載
支持斷點續(xù)傳，并緩存 Http Resonse 的 ETag 標識，下次請求時帶上，從而確定是否數(shù)據(jù)改變過，未改變則直接返回 304。
-
網(wǎng)絡(luò)緩存，減少延遲節(jié)省流量。
-
打包網(wǎng)絡(luò)請求
當接口設(shè)計不能滿足業(yè)務(wù)需求時。例如可能一個界面需要請求多個接口，或是網(wǎng)絡(luò)良好，處于 Wifi 狀態(tài)下時我們想獲取更多的數(shù)據(jù)等。這時就可以打包一些網(wǎng)絡(luò)請求，例如請求列表的同時，獲取 Header 點擊率較高的的 item 項的詳情數(shù)據(jù)，響應(yīng)體里包含更多的內(nèi)容。
-
監(jiān)聽相關(guān)狀態(tài)
監(jiān)聽設(shè)備的狀態(tài)：休眠狀態(tài)、充電狀態(tài)、網(wǎng)絡(luò)狀態(tài)，結(jié)合 JobScheduler 來根據(jù)實際情況做網(wǎng)絡(luò)請求。比方說 Splash 閃屏廣告圖片，可以在連接到 Wifi 時下載緩存到本地; 新聞類的 App 可以在充電，Wifi 狀態(tài)下做離線緩存。
-
弱網(wǎng)優(yōu)化
除了正常的網(wǎng)絡(luò)優(yōu)化，還需考慮到弱網(wǎng)情況下 App 的表現(xiàn)。
一般來說，網(wǎng)絡(luò)延遲在 60ms 內(nèi)是 OK 的，超過 200ms 就比較糟糕了。弱網(wǎng)優(yōu)化，本質(zhì)上是在弱網(wǎng)的情況下能讓用戶流暢的使用。
- 壓縮/減少數(shù)據(jù)傳輸量
- 利用緩存減少網(wǎng)絡(luò)傳輸
- 針對弱網(wǎng)(移動網(wǎng)絡(luò))，不自動加載圖片
- 界面先反饋，請求延遲提交。例如，用戶點贊操作，可以直接給出界面的點贊成功的反饋，使用 JobScheduler 在網(wǎng)絡(luò)情況較好的時候打包請求。
建立取消機制，頁面跳走了要取消請求，且不再接收數(shù)據(jù)。
GET 請求失敗增加重試機制，POST 請求可能因為延時，不要有重試機制，要防止頻繁請求相同的接口。重試機制必須要有明顯的結(jié)束條件。
避免重復(fù)上傳與下載。避免輪詢。
IP 直連，避免 DNS 解析，即耗時又有被劫持風(fēng)險。
