針對網路存取權進行最佳化

使用無線電傳輸資料可能是應用程式最主要的耗電來源之一。如要盡量減少網路活動造成的電池耗電量,請務必瞭解連線模型對基礎無線電硬體的影響。

本節將介紹無線電狀態機,並說明應用程式的連線模型如何與其互動。然後提供幾種方法,只要照著做,就能盡量減少應用程式資料用量對電池的影響。

無線電狀態機

使用者裝置上的無線電內建省電功能,可盡量減少耗電量。無線電完全啟動時會消耗大量電力,但處於閒置或待機狀態時,耗電量極低。

請務必記得,無線電無法立即從待機狀態完全啟動。「啟動」無線電時會有延遲期。因此,電池會緩慢從高耗電狀態轉換為低耗電狀態,以便在未使用時節省電力,同時盡量減少與「啟動」無線電相關的延遲。

一般 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。