使用無線電傳輸資料，可能是應用程式最耗電的來源之一。如要盡可能減少與網路活動相關的電池耗電量，請務必瞭解連線模型對基礎無線電硬體的影響。
本節將介紹無線電狀態機，並說明應用程式的連線能力模型如何與其互動。接著，本課程會提供幾項技巧，只要遵循這些技巧，就能盡量減少應用程式資料消耗對電池的影響。
無線電狀態機器
使用者裝置上的無線電內建省電功能，可盡量減少耗電量。無線電在完全啟用時會消耗大量電力，但在閒置或待機時，無線電消耗的電力非常少。
請注意，無線電無法立即從待機狀態切換至完全啟用狀態。「啟動」無線電會有一段延遲時間。因此，電池會緩慢地從高能量狀態轉換為低能量狀態，以便在不使用時節省電力，同時盡可能縮短與「啟動」無線電相關的延遲時間。
一般 3G 網路無線電的狀態機器包含三種能量狀態：
- 全功率：在連線啟用時使用，讓裝置以最高速率傳輸資料。
- 低耗電：中等狀態，可減少約 50% 的電池耗電量。
- 待機：耗電量最低的狀態，此時沒有任何網路連線。
雖然低電量和待機狀態會大幅降低電池耗電量，但也會大幅增加網路要求的延遲時間。從低功率狀態恢復到全功率狀態約需 1.5 秒，從待機狀態恢復到全功率狀態則可能需要超過 2 秒。
為了盡可能縮短延遲時間，狀態機器會使用延遲機制，延後轉換至低耗能狀態。圖 1 採用 AT&T 的一般 3G 無線電時序。
圖1. 一般 3G 無線電狀態機器。
每部裝置上的無線電狀態機器，尤其是相關的轉換延遲 (「尾端時間」) 和啟動延遲，會因採用的無線電技術 (3G、LTE、5G 等) 而異，並由裝置運作的電信業者網路定義和設定。
本頁面根據 AT&T 提供的資料，說明一般 3G 無線電的代表性狀態機器。不過，一般原則和最佳做法適用於所有無線電實作。
這種做法特別適合一般的行動版網站瀏覽，因為可以避免使用者瀏覽網頁時發生不必要的延遲。相對較低的尾端時間也確保瀏覽工作階段結束後，無線電可以進入低耗能狀態。
不過，在 Android 等現代智慧型手機作業系統上，應用程式會在前景 (延遲時間很重要) 和背景 (應優先考量電池續航力) 執行，因此這種做法可能會導致應用程式效率不彰。
應用程式對無線電狀態機的影響
每次建立新的網路連線時，無線電都會轉換為全功率狀態。以上述典型的 3G 無線電狀態機為例，無線電會在傳輸期間保持全功率運作，並在傳輸結束後維持 5 秒的尾端時間，然後進入低耗能狀態 12 秒。因此，對於一般的 3G 裝置，每次資料移轉工作階段都會導致無線電消耗至少 18 秒的能量。
在實際操作中，這表示如果應用程式每分鐘進行三次一秒的資料移轉，無線電就會永久保持啟用狀態，並在進入待機模式時返回高功率模式。
圖2. 每分鐘執行三次一秒傳輸作業的相對無線電功率用量。圖表不含執行作業之間的「啟動」延遲時間。
相較之下，如果同一個應用程式將資料移轉作業綁定，每分鐘執行一次三秒的移轉作業，則無線電每分鐘只會維持在高功率狀態 20 秒。這樣一來，無線電每分鐘有 40 秒處於待機狀態，可大幅降低電池消耗量。
圖3.每分鐘執行一次三秒傳輸作業的相對無線電功率用量。
最佳化技術
現在您已瞭解網路存取對電池續航力的影響，接下來我們將說明幾種有助於降低耗電量的方法，同時提供快速流暢的使用者體驗。
套裝組合資料移轉
如上一節所述，將資料移轉作業分批處理，以較低的頻率移轉較多資料，是提高電池效率的最佳方法之一。
當然，如果應用程式需要立即接收或傳送資料，以回應使用者動作，則不一定能這麼做。您可以預測並預先擷取資料，藉此緩解這個問題。其他情境 (例如將記錄或數據分析傳送至伺服器，以及其他非緊急、由應用程式啟動的資料移轉) 非常適合批次處理和整合。如需排定背景網路傳輸作業的提示，請參閱「最佳化應用程式啟動的工作」。
預先擷取資料
預先擷取資料是另一種有效方法，可減少應用程式執行的獨立資料移轉工作階段數量。預先擷取功能會在使用者於應用程式中執行某個動作時，預測使用者接下來的一系列動作最可能需要哪些資料，然後透過單一連線，以最大容量一次擷取該資料。
預先載入傳輸作業可減少下載資料所需的無線電啟動次數。這樣一來，您不僅能節省電池電力，還能縮短延遲時間、降低所需頻寬，以及減少下載時間。
預先擷取功能也可盡量減少應用程式內延遲時間，進而改善使用者體驗。延遲時間是指使用者在執行動作或查看資料前，等待下載完成的時間。
以下是實際範例。
新聞閱讀器
許多新聞應用程式會嘗試減少頻寬，方法是在選取類別後才下載標題、在使用者想閱讀時才下載完整文章，以及在捲動至檢視畫面時才下載縮圖。
如果採用這種做法，當使用者捲動瀏覽頭條新聞、變更類別和閱讀文章時，無線電在大部分的新聞閱讀工作階段中都必須保持啟用狀態。不僅如此，在能源狀態之間不斷切換，會導致切換類別或閱讀文章時出現明顯延遲。
較好的做法是在啟動時預先擷取合理數量的資料，從第一組新聞標題和縮圖開始，確保啟動時間延遲時間短，並繼續處理其餘標題和縮圖，以及至少從主要標題清單中取得每篇文章的文章文字。
另一個替代方案是預先擷取每個標題、縮圖、文章文字，甚至可能是整篇文章的圖片，通常是在背景中按照預定時間表進行。這種做法可能會耗費大量頻寬和電池續航力，下載從未使用過的內容，因此應謹慎實施。
其他注意事項
雖然預先擷取資料有許多好處，但如果過度使用，也可能導致電池耗電量和頻寬用量增加，以及下載未使用的資料而耗用下載配額。此外，也請務必確保預先擷取不會延遲應用程式啟動，因為應用程式會等待預先擷取完成。實際做法可能是逐步處理資料，或依優先順序啟動連續傳輸，優先下載及處理應用程式啟動所需的資料。
預先擷取資料的積極程度取決於下載的資料大小，以及資料的使用可能性。根據上述狀態機，如果資料在目前使用者工作階段中有 50% 的機率會被使用，通常可以預先擷取約 6 秒 (約 1 至 2 MB)，然後下載未使用資料的潛在成本，就會與不下載該資料的潛在節省費用相符。
一般來說，建議您預先擷取資料，這樣每隔 2 到 5 分鐘才需要啟動另一次下載，且下載量約為 1 到 5 MB。
根據這項原則，大型下載項目 (例如影片檔案) 應定期 (每 2 到 5 分鐘) 分段下載，只預先擷取可能在接下來幾分鐘內觀看的影片資料。
其中一個解決方案是，排定只有在連上 Wi-Fi 時才進行完整下載，而且可能只有在裝置充電時才進行。WorkManager API 支援這個用途，可讓您限制背景工作，直到裝置符合開發人員指定的條件 (例如充電和連上 Wi-Fi) 為止。
提出要求前先檢查連線
搜尋行動網路訊號是行動裝置上最耗電的操作之一。針對使用者發出的要求，最佳做法是先使用 ConnectivityManager 檢查連線，如「監控連線能力狀態和連線計量功能」一文所示。如果沒有網路，應用程式可以不強制行動無線電搜尋，藉此節省電池電力。接著，系統會排定要求，並在建立連線時與其他要求一起批次執行。
集區連線
除了批次處理和預先擷取之外，另一項有助於提升效能的策略是集結應用程式的網路連線。
一般來說，重複使用現有網路連線比啟動新連線更有效率。重複使用連線也能讓網路更聰明地因應壅塞和相關網路資料問題。
HttpURLConnection 和大多數 HTTP 用戶端 (例如 OkHttp) 預設會啟用連線集區，並針對多個要求重複使用相同的連線。
回顧與展望
在本節中，您已瞭解許多關於無線電的知識，以及一些可廣泛應用的策略，能提供快速、回應迅速的使用者體驗，同時減少電池耗電量。
下一節將詳細介紹大多數應用程式常見的三種不同網路互動類型。您將瞭解每種類型的驅動因素，以及有效管理這些互動的現代技術和 API。