對于手機(jī)程序，網(wǎng)絡(luò)操作相對來說是比較耗電的行為。優(yōu)化網(wǎng)絡(luò)操作能夠顯著節(jié)約電量的消耗。在性能優(yōu)化第1季里面有提到過，手機(jī)硬件的各個模塊的耗電量是不一樣的，其中移動蜂窩模塊對電量消耗是比較大的，另外蜂窩模塊在不同工作強(qiáng)度下，對電量的消耗也是有差異的。當(dāng)程序想要執(zhí)行某個網(wǎng)絡(luò)請求之前，需要先喚醒設(shè)備，然后發(fā)送數(shù)據(jù)請求，之后等待返回數(shù)據(jù)，最后才慢慢進(jìn)入休眠狀態(tài)。這個流程如下圖所示：

在上面那個流程中，蜂窩模塊的電量消耗差異如下圖所示：

從圖示中可以看到，激活瞬間，發(fā)送數(shù)據(jù)的瞬間，接收數(shù)據(jù)的瞬間都有很大的電量消耗，所以，我們應(yīng)該從如何傳遞網(wǎng)絡(luò)數(shù)據(jù)以及何時發(fā)起網(wǎng)絡(luò)請求這兩個方面來著手優(yōu)化。

1.1)何時發(fā)起網(wǎng)絡(luò)請求

首先我們需要區(qū)分哪些網(wǎng)絡(luò)請求是需要及時返回結(jié)果的，哪些是可以延遲執(zhí)行的。例如，用戶主動下拉刷新列表，這種行為需要立即觸發(fā)網(wǎng)絡(luò)請求，并等待數(shù)據(jù)返回。但是對于上傳用戶操作的數(shù)據(jù)，同步程序設(shè)置等等行為則屬于可以延遲的行為。我們可以通過Battery Historian這個工具來查看關(guān)于移動蜂窩模塊的電量消耗（關(guān)于這部分的細(xì)節(jié)，請點擊Android性能優(yōu)化之電量篇）。在Mobile Radio那一行會顯示蜂窩模塊的電量消耗情況，紅色的部分代表模塊正在工作，中間的間隔部分代表模塊正在休眠狀態(tài)，如果看到有一段區(qū)間，紅色與間隔頻繁的出現(xiàn)，那就說明這里有可以優(yōu)化的行為。如下圖所示：

對于上面可以優(yōu)化的部分，我們可以有針對性的把請求行為捆綁起來，延遲到某個時刻統(tǒng)一發(fā)起請求。如下圖所示：

經(jīng)過上面的優(yōu)化之后，我們再回頭使用Battery Historian導(dǎo)出電量消耗圖，可以看到喚醒狀態(tài)與休眠狀態(tài)是連續(xù)大塊間隔的，這樣的話，總體電量的消耗就會變得更少。

當(dāng)然，我們甚至可以把請求的任務(wù)延遲到手機(jī)網(wǎng)絡(luò)切換到WiFi，手機(jī)處于充電狀態(tài)下再執(zhí)行。在前面的描述過程中，我們會遇到的一個難題是如何把網(wǎng)絡(luò)請求延遲，并批量進(jìn)行執(zhí)行。還好，Android提供了JobScheduler來幫助我們達(dá)成這個目標(biāo)。

1.2)如何傳遞網(wǎng)絡(luò)數(shù)據(jù)

關(guān)于這部分主要會涉及到Prefetch(預(yù)取)與Compressed(壓縮)這兩個技術(shù)。對于Prefetch的使用，我們需要預(yù)先判斷用戶在此次操作之后，后續(xù)零散的請求是否很有可能會馬上被觸發(fā)，可以把后面5分鐘有可能會使用到的零散請求都一次集中執(zhí)行完畢。對于Compressed的使用，在上傳與下載數(shù)據(jù)之前，使用CPU對數(shù)據(jù)進(jìn)行壓縮與解壓，可以很大程度上減少網(wǎng)絡(luò)傳輸?shù)臅r間。

想要知道我們的應(yīng)用程序中網(wǎng)絡(luò)請求發(fā)生的時間，每次請求的數(shù)據(jù)量等等信息，可以通過Android Studio中的Networking Traffic Tool來查看詳細(xì)的數(shù)據(jù)，如下圖所示：