節省電力和電池

關鍵字：Wear OS、電源、電池、效能

在 Wear OS 上，電源效率尤其重要。由於手錶是小型板型規格，用於短暫互動，因此 Wear OS 設計原則特別著重於裝置電力使用情形。

與較大的行動裝置相比，Wear OS 裝置的電池較小，因此耗電量會更明顯。此外，與行動裝置相比，使用者需要花費更多心力才能為 Wear OS 裝置充電。雖然使用者可以在一天中不同時段為行動裝置充電，但他們必須先將 Wear OS 裝置從身上取下，才能為裝置充電。

如要提升應用程式的電力效率，請遵循下列設計最佳做法：

  • 應用程式的設計應充分運用 Wear OS 板型規格。不應直接複製您的行動應用程式。
  • 使用現有的行動應用程式，協助處理特定用途。舉例來說，手錶的網路和同步處理功能耗用大量資源；請考慮行動裝置是否可負擔繁重的工作，而 Wear OS 裝置則接收資料變更。
  • 設計用途時，請考量到較短的互動時間。
  • 請考量您使用哪些 Wear OS 事件，以及這些事件發生的頻率。

  • 盡可能將應用程式的工作延後至手錶充電時執行。這項做法特別適用於資料密集型工作，例如同步處理資料和整理資料庫。

    如果裝置正在充電且已連上 Wi-Fi，請排定工作，預先擷取使用者可能想在應用程式中看到的資料、圖片和更新。

這份電源指南可協助您瞭解系統執行應用程式的時間和方式，以及如何限制應用程式的執行時間和耗電量。如要進一步瞭解如何執行特定動作 (例如載入應用程式或捲動清單)，請參閱效能相關指南，例如 Wear OS 上的 Compose 效能指南。

監控電池用量變化

如要分析執行應用程式的 Wear OS 裝置電池狀態，請在開發機器的終端機視窗中輸入下列指令：

adb shell dumpsys batterystats

GitHub 上的程式庫提供電池統計資料剖析器，可與此指令一併執行。

影響電池續航力的事件

在思考應用程式時，建議您先以更廣泛的角度思考 Wear OS 裝置上耗電的事件。

下表列出 Wear OS 應用程式中幾個常見事件對電池續航力的相對影響。實際耗電量會因裝置而異。

活動 對電池續航力的影響 如何減輕影響
存取網路 (包括 LTE 和 Wi-Fi) 非常高 延後非必要的網路存取作業，直到裝置充電為止。
開啟螢幕並啟動互動模式 高 請勿鼓勵使用者將螢幕開啟的時間延長至必要的時間。提供使用一律啟用模式 (也稱為微光模式) 的體驗。
存取 GPS 感應器 高 盡可能等到使用者要求 GPS 存取權。
維持高 CPU 使用率 高 使用 Jetpack Compose 取用資料流。
存取心率感應器 中 接收感應器 API 回呼時，請使用處理器的喚醒時間，例如使用 Wear OS 上的 Health Services 時。
透過藍牙存取其他裝置 中 縮短會談時間。
保持 WakeLock 中 請減少手動建立的喚醒鎖，並使用 WorkManager。

盡量減少螢幕開啟時間

在 Wear OS 應用程式中，請遵循下列螢幕使用原則：

  • 螢幕開啟鎖定：盡可能避免使用。如要進行測試，請在系統設定中關閉「螢幕長亮模式」，並觀察螢幕是否會在逾時期間關閉。
  • 動畫：盡量減少複雜的動畫，改以簡短的轉場效果營造更專業的氛圍。特別要避免長時間執行的動畫和迴圈。如果需要循環播放，請在循環之間加入至少與動畫本身一樣長的暫停時間。

  • 在微光模式下喚醒的時間：如有需要 (例如健身用途)，請支援螢幕長亮功能。如果您的應用程式需要持續待機，請確認您的應用程式在裝置處於微光模式時執行下列操作：

    • 降低裝置螢幕的亮度百分比。
    • 不顯示動畫。
    • 除了在 onAmbientUpdate() 回呼期間，不會更新畫面內容。

盡可能減少 CPU 用量

在 Wear OS 應用程式中，請遵循下列 CPU 使用原則：

  • 使用時長應精簡。
  • 將所有相關作業分批處理，盡可能讓應用程式程序處於閒置狀態。

盡量減少喚醒鎖定

在大多數情況下，請避免執行任何會導致應用程式無法進入休眠狀態的作業，例如喚醒鎖。舉例來說，在健康與健身應用程式中，長時間執行的健身活動不需要喚醒鎖定。在接收感應器 API 回呼時使用處理器的喚醒時間，例如使用 Wear OS 上的 Health Services 時。

在某些情況下，取得喚醒鎖定是合理的，例如應用程式執行下列任一操作時：

  • 在背景播放媒體。
  • 使用 WorkManager 或 JobScheduler。(在背景執行工作時，系統會代您保持喚醒鎖定)。

Battery Historian 可讓您查看個別長時間喚醒鎖定事件，以及喚醒鎖定總數和持續時間的摘要。檢查應用程式持有的喚醒鎖數量和持續時間，並將這項資訊與應用程式的互動使用模式進行比較：

  • 檢查是否有非預期的喚醒鎖定。
  • 如果時間比預期長，請考慮工作是否因某些依附元件而受阻，例如網路可用性。

檢查應用程式如何變為非活動狀態

請考量在發生重要裝置事件時，目前執行中的應用程式正在執行的作業，例如：

  • 螢幕會關閉，裝置進入微光模式。

  • 應用程式會滑動關閉。

如要分析應用程式活動，請使用下列各節所述的工具。

電源分析器

如要使用 Power Profiler，請在 Android Studio 選單中依序選取「View」>「Tool Windows」>「Profiler」：

  1. 檢查螢幕關閉及裝置進入環境模式時的系統追蹤記錄。
  2. 請查看是否有任何工作仍在進行，以及裝置的 CPU 使用率。

Perfetto

Perfetto 可讓您記錄追蹤記錄，然後檢查應用程式，看看在螢幕關閉、裝置進入微光模式，或使用者關閉應用程式活動時，是否有任何執行緒在執行任何工作。

定義自訂事件，用於標示應用程式的重要事件，包括特定領域的事件。對於媒體應用程式，這包括擷取播放清單、下載特定媒體項目、開始播放和停止播放等工作。定義這些事件後，您就能在 Perfetto 中查看這些事件，並將事件時間與應用程式的 CPU 和電源使用情形進行比較。

分析應用程式的已排定工作

使用 WorkManager 排定的工作，可讓您在應用程式中執行背景工作。雖然某些背景工作必須定期執行，但請勿過於頻繁或長時間執行工作，因為這可能會耗盡裝置的電池電量。

使用 Battery Historian 檢查排程工作執行情形，包括整體 (系統統計資料 > 工作排程器統計資料) 和應用程式 (應用程式統計資料 > 排程工作)。查看總計數量和總時長：

  • 如果工作執行頻率過高，請考慮降低頻率。
  • 確認總執行時間是否符合預期，且不會大幅增加。

另外，請檢查 Battery Historian 圖表，查看每個 JobScheduler 項目。當您將游標懸停在特定項目上時，Battery Historian 會顯示執行工作的擁有者。請把握以下幾項重點：

  • 對於應用程式而言，執行時間應有意義。
  • 請考量工作是否會在應用程式執行期間發生，或工作是否代表定期的背景工作。

感應器

Wear OS 裝置具有許多不同的感應器，例如 GPS。在大多數情況下，請使用 Wear OS 的健康照護服務，而非直接與 SensorManager 互動。在許多情況下，健康照護服務會以智慧方式將資料分批處理，以改善電池效能。

如要分析應用程式中的感應器用量，請在開發機器的終端機視窗中執行下列指令：

adb shell dumpsys sensorservice

這項指令的結果如下所示：

  • 目前和先前的感測器註冊。
  • 感應器設定，包括批次處理 (如有設定)。
  • 最近的取樣資料。

測試從感應器取消註冊

如要確認應用程式是否如預期停止擷取感應器資料，請測試下列情境：

  1. 滑動關閉應用程式。
  2. 用手掌輕觸螢幕。這會關閉螢幕或將螢幕置於微光模式。

使用上一節的 ADB 指令，確認感應器是否正確顯示為未註冊。

資料層

使用 Data Layer API 時，每次傳輸都會消耗一些電力。特別是，如果您使用這個 API 傳送資料，應用程式必須喚醒才能接收資料。基於這些原因，請謹慎使用這個 API。

使用資料層 API 的其他最佳做法包括：

  • 請等到應用程式啟用後，再使用 WearableListenerService 設定事件監聽器。

  • 傳送狀態變更，而非設定快速更新。這些狀態變更可讓 Wear OS 裝置執行本機資料計算作業，例如開始健身時。

    只傳送可更新 UI 的狀態變更。舉例來說，如果活動畫面只會顯示小數點後一位的「跑步公里數」，請勿在使用者每次移動一公尺時，向 Wear OS 傳送狀態變更。

如要分析應用程式中的 Data Layer API 用量，請在開發機器的終端機視窗中執行下列指令：

adb shell dumpsys activity service WearableService

這個指令的結果包括：

  • RpcService：讓您查看使用 MessageClient 時的呼叫頻率和路徑。
  • DataService：讓您查看使用 DataClient 設定資料項目的頻率。

健康與健身應用程式

如果您維護健康與健身應用程式，請使用健康照護服務，改善應用程式對感應器的使用方式。

  • 針對 ExerciseClient，請使用 Battery Historian 驗證背景模式中的正確行為。確認應用程式不會每隔一兩分鐘就喚醒，以便接收 ExerciseUpdate 資料。
  • 如要全天監控一般健康資料，請使用 PassiveMonitoringClient，如在背景監控健康與健身資料指南所述。

資訊方塊和小工具

如果您的應用程式支援資訊方塊或小工具，請遵循下列最佳做法：

  • 停用自動重新整理功能，或將重新整理頻率提高至 2 小時以上。
  • 請使用 Firebase 雲端通訊 (FCM) 或適當排程的工作傳送資料更新。請注意，如果更新速度過快，系統安排重複工作時，使用者或平台可能無法存取執行該項工作的必要資料。
  • 在使用者未與資訊方塊或小工具互動時，請勿為其排程工作。
  • 使用離線優先方法。
  • 在主要應用程式、資訊方塊和小工具之間共用單一資料庫。這也有助於在 UI 途徑中保持資料一致性。