注：本文翻譯自Google官方的Android Developers Training文檔，譯者技術(shù)一般，由于喜愛安卓而產(chǎn)生了翻譯的念頭，純屬個人興趣愛好。

原文鏈接： http://developer.android.com/training/efficient-downloads/efficient-network-access.html

在你的應(yīng)用中，可能最消耗電力的就是用無線網(wǎng)絡(luò)對資源進(jìn)行下載了。?為了最小化網(wǎng)絡(luò)連接對電池?fù)p耗的影響，你一定要理解你的連接模型是如何影響底層的的無線硬件的。這節(jié)課將介紹“無線網(wǎng)絡(luò)狀態(tài)機(jī)”并解釋你的應(yīng)用連接模型如何與這個狀態(tài)機(jī)聯(lián)系起來。緊接著我們會介紹如何減少你的數(shù)據(jù)連接，使用預(yù)取（ use prefetching ）和捆綁傳輸（ bundle ）讓數(shù)據(jù)傳輸對電池壽命的影響降低到最低。

一）. 無線狀態(tài)機(jī)

一個完全活躍的無線連接會顯著地消耗電量，所以它會在不同的能耗狀態(tài)間切換，這樣做的目的是在它沒有被使用時可以節(jié)省電量，同時又能保證可以在盡量短的時間內(nèi)重新啟動無線電。

對于一個標(biāo)準(zhǔn)的3G無線網(wǎng)絡(luò)來說，它的狀態(tài)機(jī)由三個能耗狀態(tài)組成：

1. 高能耗 ：當(dāng)一個連接處于活躍狀態(tài)時使用，允許設(shè)備在其最高的傳輸速率下傳輸數(shù)據(jù)。
2. 低能耗 ：一個中間的狀態(tài)，其功率損耗大致為高能耗狀態(tài)的50%。
3. 待機(jī) ：最低的能耗狀態(tài)，這種情況下沒有活躍的或者需要的網(wǎng)絡(luò)連接。

雖然低能耗及待機(jī)狀態(tài)會顯著減少電量的消耗，但他們也會在網(wǎng)絡(luò)連接請求發(fā)起時導(dǎo)致巨大的延遲。從低能耗狀態(tài)回到高能耗狀態(tài)需要大約1.5秒，而從待機(jī)狀態(tài)回到高能耗狀態(tài)則需要大約2秒甚至更多的時間。

為了將延遲最小化，狀態(tài)機(jī)使用了一個延遲機(jī)制，來推遲由高能耗到低能耗這一狀態(tài)切換。圖1所示的是 AT&T對于標(biāo)準(zhǔn)3G網(wǎng)絡(luò)的狀態(tài)機(jī)時間參數(shù)：

圖1. 標(biāo)準(zhǔn)的3G無線網(wǎng)絡(luò)狀態(tài)機(jī)

每個設(shè)備上的無線狀態(tài)機(jī)，尤其是狀態(tài)切換的延遲時間（尾時間“ tail time” ）以及啟動時間會隨著所采用的無線技術(shù)的不同而變化（2G，3G，LTE等），這些參數(shù)都由設(shè)備所支持的網(wǎng)絡(luò)運營商所定義和配置。

這節(jié)課將會講解一個具有代表性的標(biāo)準(zhǔn)3G網(wǎng)絡(luò)無線狀態(tài)機(jī)，它基于AT&T所提供的 數(shù)據(jù) 。然而，這一思想及實踐方法對于所有的無線網(wǎng)絡(luò)的實現(xiàn)來說也是可以應(yīng)用的。

這里所使用的這一狀態(tài)機(jī)對于網(wǎng)頁瀏覽來說是非常有效的，因為它不會在瀏覽網(wǎng)頁時引入用戶無法接受的長延遲。較短的狀態(tài)切換時間也可以是的一旦一個瀏覽網(wǎng)頁的會話完畢了，無線網(wǎng)絡(luò)會轉(zhuǎn)換到低能耗狀態(tài)。

不幸的是，這種方法會導(dǎo)致一個現(xiàn)代智能手機(jī)操作系統(tǒng)上（如Android）的低效應(yīng)用，因為應(yīng)用即在前臺運行（控制延遲異常重要），也在后臺運行（對電池壽命的影響）。

二）. 應(yīng)用如何影響無線狀態(tài)機(jī)

每次你創(chuàng)建一個新的網(wǎng)絡(luò)連接，都會切換到高能耗狀態(tài)。在上面所說的標(biāo)準(zhǔn)3G的無線狀態(tài)機(jī)而言，它在高能耗狀態(tài)所維持的時間為：數(shù)據(jù)傳輸時間+額外的5秒切換延遲，緊接著是低能耗狀態(tài)下的12秒切換延遲。也就是說，對于一個典型的3G設(shè)備，每次數(shù)據(jù)傳輸會話將會導(dǎo)致無線電消耗電量的時間長達(dá)20秒左右。

在實際情況下，這意味著一個應(yīng)用如果不把要傳輸?shù)臄?shù)據(jù)打包，并每隔18秒傳輸1秒的數(shù)據(jù)，那么就會然無線電一直處于活躍狀態(tài)，在它即將回到待機(jī)狀態(tài)時，又回到了高能耗狀態(tài)。它導(dǎo)致的結(jié)果就是：每分鐘內(nèi)，會以高能耗狀態(tài)消耗電量18秒，剩下的42秒為低能耗狀態(tài)消耗電量的時間。

作為對比，同樣一個應(yīng)用如果將要傳輸?shù)臄?shù)據(jù)打包，每分鐘傳輸3秒的數(shù)據(jù)，那么高能耗狀態(tài)只保持8秒，低能耗狀態(tài)只保持12秒。

上述第二個例子允許無線電在每分鐘內(nèi)有40秒處于待機(jī)狀態(tài)，這回顯著減少電量的消耗。

圖2. 打包傳輸數(shù)據(jù)和不打包傳輸數(shù)據(jù)時，無線電的電量使用對比

三）. 預(yù)取數(shù)據(jù)

預(yù)取數(shù)據(jù)是一種非常有效的減少獨立數(shù)據(jù)傳輸?shù)臅挃?shù)目的方法。預(yù)取允許你一次性下載在給定時間內(nèi)你可能會使用的所有數(shù)據(jù)。

通過提前加載你的數(shù)據(jù)，可以減少下載數(shù)據(jù)所需要的無線連接數(shù)。與此同時，你不但節(jié)省了電量，也優(yōu)化了延遲，減少了帶寬的占用并減少了下載時間。

預(yù)取也可以減少由在顯示數(shù)據(jù)時等待下載完成所造成的延遲。這可以有效提升用戶體驗。

然而，如果使用的太過度，預(yù)取也會引入過量消耗電池和帶寬使用的風(fēng)險，這是因為過度預(yù)取可能會取回來一些根本不需要的數(shù)據(jù)。另外還要確保預(yù)取不會造成應(yīng)用的啟動延遲，因為應(yīng)用可能會等待預(yù)取結(jié)束。就實際應(yīng)用而言，這意味著應(yīng)該要逐步地處理數(shù)據(jù)，或者說初始化傳輸?shù)膬?yōu)先級，如應(yīng)用啟動時需要的數(shù)據(jù)應(yīng)該優(yōu)先被下載。

執(zhí)行預(yù)取的程度取決于要被下載的數(shù)據(jù)規(guī)模以及數(shù)據(jù)被使用的可能性。粗略地來說，基于上述狀態(tài)機(jī)所描述的，對于當(dāng)前會話中有大約50%幾率使用的數(shù)據(jù)，你可以先預(yù)取6秒鐘左右（大約1-2Mb），6秒時間的確定指的是在下載無用數(shù)據(jù)所消耗的時間和不下載這些數(shù)據(jù)所節(jié)省的時間相等時（此時預(yù)取已經(jīng)無法節(jié)約時間了）。

通常來說，預(yù)取數(shù)據(jù)時，可以每2-5分鐘初始化另一個下載，來下載大約1-5Mb的數(shù)據(jù)。

遵循上述宗旨，大規(guī)模的下載——如視頻文件，應(yīng)該分塊以固定時間間隔分別下載（比如每2-5分鐘下載一塊數(shù)據(jù)），僅下載極有可能在后幾分鐘會觀看的視頻數(shù)據(jù)。

注意更多下載需要打包下載，這會在下一節(jié)詳細(xì)展開，具體的實現(xiàn)會根據(jù)連接的類型和速度而變化，這也會在后續(xù)課程中講到。

下面看一些實際例子：

音樂播放器：

你當(dāng)然可以一下子把整個專輯預(yù)取下來，然而如果用戶聽完第一首歌后就停止不聽了，那么你就消耗了大量的貸款和電池壽命。

一個更好的措施是在當(dāng)前正在播放的歌曲之外，維持一個裝有凌一首歌曲的緩存。對于流媒體音樂，可以使用HTTP流來傳輸音頻，預(yù)取操作可以用上述所說的。

新聞閱讀器：

許多新聞應(yīng)用會嘗試通過再一種類型的新聞被選中后，僅下載標(biāo)題的方法來減少帶寬，只有在用戶選擇相應(yīng)的新聞后再下載文章，只有在用戶滑動到顯示圖片的位置時再加載圖片。

通過這種方法，無線連接會一直保持活躍狀態(tài)，因為用戶會不停地在標(biāo)題間切換，改變新聞類別，并且閱讀文章。不僅如此，在能耗狀態(tài)發(fā)生切換時，用于如果切換類別或閱讀文章會導(dǎo)致顯著的延遲。

一個更好的方法是在啟動時先預(yù)取合理數(shù)量的數(shù)據(jù)。比如開始可以先取最先的一批新聞標(biāo)題和縮略圖——保證啟動的延遲時間較短——之后再陸續(xù)獲取標(biāo)題和縮略圖，以及相關(guān)的正文。

還有一種做法是預(yù)取每一個標(biāo)題，縮略圖，正文，甚至新聞完整的圖片——可以在后臺參照一個預(yù)定的時間表執(zhí)行。但是這個方法會消耗掉大量的帶寬和電量去下載那些從來不被使用的內(nèi)容，所以以這種方式實現(xiàn)的時候一定要格外的注意。

實現(xiàn)時，一種方法是僅在有Wi-Fi連接的時候，還可能是僅在設(shè)備在充電的時候執(zhí)行。具體的細(xì)節(jié)在這篇文章中有闡述： Modify your Download Patterns Based on the Connectivity Type 。

四）. 批量傳輸和連接

每一次你初始化一個連接——不論傳輸?shù)臄?shù)據(jù)量有多大——你都會導(dǎo)致無線電消耗大約20秒左右的電量（在使用一個標(biāo)準(zhǔn)3G無線網(wǎng)時）。

如果一個應(yīng)用每20秒ping一次服務(wù)器，確認(rèn)應(yīng)用處于正在運行并對用戶可見的狀態(tài)，會導(dǎo)致無線電一直消耗電量，即使沒有實際的數(shù)據(jù)傳輸，也會消耗掉大量的電量。

綜上所述，打包你的數(shù)據(jù)傳輸是很重要的并創(chuàng)建一個帶傳輸?shù)年犃小Ｈ绻麑崿F(xiàn)正確，你可以有效地在一時間窗口內(nèi)進(jìn)行數(shù)據(jù)傳輸，讓他們同時發(fā)生，以盡量保證數(shù)據(jù)傳輸在短時間內(nèi)做完。

這背后的哲學(xué)意義便是在傳輸數(shù)據(jù)量相同的情況下，要盡量使用最少的會話數(shù)目來完成所有數(shù)據(jù)的傳輸。

所以說，你應(yīng)該對于那些可以容忍有一定延遲的數(shù)據(jù)傳輸任務(wù)執(zhí)行批量傳輸，同時要記得當(dāng)對于時間敏感的傳輸任務(wù)需要做時，它可以具有更高的優(yōu)先級去做更新或者預(yù)取等操作。計劃的更新和預(yù)取任務(wù)應(yīng)該開始于你的延遲傳輸隊列。

對于一個實際的例子，讓我們回到之前預(yù)取數(shù)據(jù)中的例子。

對于一個采用了上述預(yù)取策略的新聞應(yīng)用。新聞閱讀器收集并分析信息來理解其用戶的閱讀模式，并標(biāo)記出用戶最喜歡的文章類型。為了保證該部分文章一直是最新的，它每隔一個小時就刷新一次。為了保留帶寬，它并不是下載每篇文章的所有圖片，而是僅下載縮略圖，并在用戶選擇了以后再下載完整的圖片。

在這個例子中，所有應(yīng)用收集的分析信息被捆綁在一起，并排成隊列等待傳輸，而不是一收集到就傳輸。捆綁好的數(shù)據(jù)的傳輸時機(jī)，可以是當(dāng)一副完整的圖片下載好了，或者每隔一小時的更新發(fā)生時（將數(shù)據(jù)傳輸?shù)娜蝿?wù)合并在一起）。

所有對時間敏感的或者點播類型的數(shù)據(jù)傳輸——比如下載一幅完整的圖片，需要優(yōu)先于常規(guī)的計劃任務(wù)。計劃更新的執(zhí)行時機(jī)應(yīng)該是在設(shè)置好的計劃間隔時間過了之后隨著緊急的數(shù)據(jù)傳輸一起發(fā)生。這種方法通過將計劃更新和對時間敏感的下載圖片等任務(wù)捆綁在一起，來減輕執(zhí)行計劃更新的代價。

五）. 減少連接數(shù)

通常來說，使用已經(jīng)存在的網(wǎng)絡(luò)連接會比重新初始化一個新的網(wǎng)絡(luò)連接來說更有效率。重復(fù)使用連接還能是的網(wǎng)絡(luò)對于擁塞和相關(guān)的網(wǎng)絡(luò)數(shù)據(jù)問題的響應(yīng)可以更加智能。

你應(yīng)該將請求捆綁到一個GET當(dāng)中，而不是創(chuàng)建多個連接同時下載數(shù)據(jù)，或多個連接連續(xù)的發(fā)送GET請求。

例如，為每一個新聞標(biāo)題生成單一的請求，并返回單一的請求或響應(yīng)會比生成多個請求要好。無線需要保持活躍來傳輸端到端之間的確認(rèn)接受包，所以在不用網(wǎng)絡(luò)連接的時候應(yīng)該將其關(guān)閉，而不是讓它一直開啟并等待超時信息。

也就是說，如果過早地關(guān)閉一個連接會阻止它被重用，這就需要額外的消耗來建立新的連接。一個折中的方案是不要立即關(guān)閉這些連接，不過還是要在超時時間到之前將其關(guān)閉。

六）. 使用DDMS的網(wǎng)絡(luò)流量工具來確定哪里可以改進(jìn)

Android? DDMS (Dalvik Debug Monitor Server) 包含有一個詳細(xì)的網(wǎng)絡(luò)使用工具，使得其能夠在你的應(yīng)用發(fā)出網(wǎng)絡(luò)連接請求時跟蹤網(wǎng)絡(luò)情況。使用這個工具，你可以監(jiān)測你的應(yīng)用是在何時以什么方式傳輸數(shù)據(jù)的，并可以根據(jù)監(jiān)測的結(jié)果優(yōu)化你的代碼實現(xiàn)。

圖3展示了一個每隔15秒鐘傳輸一次少量數(shù)據(jù)的場景，從中可以發(fā)現(xiàn)通過預(yù)取或者批量傳輸?shù)姆椒梢燥@著提高應(yīng)用的傳輸效率：

圖3. 使用DDMS跟蹤網(wǎng)絡(luò)使用情況

通過監(jiān)聽你的數(shù)據(jù)傳輸?shù)念l率，以及每次傳輸數(shù)據(jù)時的數(shù)據(jù)量，之后你就能找到你的應(yīng)用可以在什么地方加以改進(jìn)來提高電池的使用效率。通常而言，你可以找一些可以延遲的波峰，對其進(jìn)行延遲。或者將一些傳輸任務(wù)提前。

為了更好的表現(xiàn)出傳輸導(dǎo)致波峰的原因，可以使用 Traffic Stats API在一個線程內(nèi)使用 TrafficStats.setThreadStatsTag() 方法，人工地標(biāo)記或者取消標(biāo)記某一個套接字（使用 tagSocket() 方法和 untagSocket() 方法 ），來標(biāo)記數(shù)據(jù)傳輸?shù)陌l(fā)生。例如：

      TrafficStats.setThreadStatsTag(0xF00D
      
        );

TrafficStats.tagSocket(outputSocket);


      
      
        //
      
      
         Transfer data using socket
      
      

TrafficStats.untagSocket(outputSocket);
    

Apache的 HttpClient 和 URLConnection 庫可以基于當(dāng)前的 getThreadStatsTag() 的值自動地為套接字做標(biāo)記。這些庫還能在套接字在活動池中循環(huán)后自動地進(jìn)行標(biāo)記或取消標(biāo)記。

      TrafficStats.setThreadStatsTag(0xF00D
      
        );


      
      
        try
      
      
         {

  
      
      
        //
      
      
         Make network request using HttpClient.execute()
      
      

} 
      
        finally
      
      
         {

  TrafficStats.clearThreadStatsTag();

}
      
    

套接字標(biāo)記在Android 4.0中開始被支持，但是實時的數(shù)據(jù)顯示僅能在運行Android 4.0.3或更高版本系統(tǒng)的設(shè)備上被顯示。

【Android Developers Training】 83. 實現(xiàn)高效網(wǎng)絡(luò)訪問來優(yōu)化下載