節省電力和電池

在 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 上的健康照護服務。
透過藍牙存取其他裝置 媒介 保持工作階段簡短。
保持 Wake Lock 媒介 減少手動建立 Wake Lock，並使用 WorkManager。

縮短螢幕開啟時間

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

  • 螢幕鎖定：請盡量避免。如要進行測試，請在系統設定中關閉「螢幕長亮模式」，並觀察螢幕是否在逾時期限內關閉。
  • 動畫：盡量減少動畫效果較詳細的動畫，而應專注於短暫轉場，打造專業質感。尤其應避免長時間執行的動畫和迴圈。如果需要迴圈，請在迴圈之間加入至少與動畫本身相同的停頓。

  • 「在微光模式下喚醒的時間」：在必要時支援一律開啟，例如健身用途。如果應用程式需要一律開啟功能，請確認應用程式在裝置處於微光模式時執行以下操作：

    • 降低裝置螢幕亮起的百分比。
    • 不會顯示動畫。
    • 除非發生 onAmbientUpdate() 回呼，否則不會更新畫面內容。

盡可能減少 CPU 使用率

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

  • 盡量減少使用時間。
  • 批次處理任何相關作業，以盡可能縮短應用程式程序處於閒置狀態的時間。

盡可能減少 Wake Lock

在大多數情況下，請避免使用任何會妨礙應用程式休眠的作業，例如喚醒鎖定。舉例來說，在健康與健身應用程式中，長時間執行的健身不需要使用 Wake Lock。收到來自感應器 API 的回呼時，請使用處理器的喚醒時間，例如使用 Wear OS 上的健康照護服務時。

在某些情況下，可使用 Wake Lock，例如應用程式執行下列其中一項操作：

  • 在背景播放媒體。
  • 使用 WorkManager 或 JobScheduler。(在背景執行工作時，系統會為您保留 Wake Lock。)

Battery Historian 可讓您查看個別長時間醒來的情況，以及保留的 Wake Lock 總數和持續時間的摘要。檢查應用程式保留的 Wake Lock 次數和持續時間，並將這項資訊與應用程式的互動式使用模式進行比較：

  • 檢查是否有非預期的 Wake Lock。
  • 如果持續時間超過預期，請考慮特定依附元件 (例如網路可用性) 是否會封鎖工作。

檢查應用程式的閒置狀態

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

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

  • 應用程式遭到抹除。

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

能源分析器

依序選取「View」>「Tool Windows」>「Profiler」，即可在 Android Studio 選單中存取能源分析器：

  1. 在螢幕關閉且裝置進入微光模式時檢查系統追蹤記錄。
  2. 找出所有持續進行的工作，以及裝置的 CPU 使用率等級。

Perfetto

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

定義自訂事件來標示應用程式的重要事件，包括網域專屬的事件。以媒體應用程式來說，這包括擷取播放清單、下載特定媒體項目、開始播放及停止播放等工作。定義這些事件後，您就可以在 Perfetto 中查看這些事件，並與應用程式的 CPU 和電池用量進行比較。

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

透過 WorkManager 排定工作可讓您在應用程式中執行背景工作。雖然某些背景工作必須定期執行，但不要頻繁或長時間執行工作，以免消耗裝置的電池電量。

使用 Battery Historian 檢查整體工作的執行狀態，包括整體資料 (「System stats」>「Jobscheduler 統計資料」) 和「App」(應用程式統計資料) >「已排定工作」。檢查總數和總時長：

  • 如果工作執行頻率非常高，請考慮降低這個頻率。
  • 檢查總執行時間是否與預期相符，而且不會大幅縮短。

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

  • 對您的應用程式而言，執行時間應該合理。
  • 請考量工作是否在應用程式執行期間發生，或者工作是否代表定期背景工作。

感應器

Wear OS 裝置配備許多不同的感應器，例如 GPS。在大多數情況下，請使用 Wear OS 上的健康照護服務，不要直接與 SensorManager 互動。在許多情況下，健康照護服務會聰明地批次處理資料，藉此提高電池效能。

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

adb shell dumpsys sensorservice

這個指令的結果會顯示以下內容：

  • 目前及先前的感應器註冊資料。
  • 感應器設定，包含已設定的批次處理功能。
  • 最近取樣的資料。

測試從感應器取消註冊

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

  1. 滑動關閉應用程式。
  2. 用手掌輕觸螢幕。這麼做可以關閉螢幕，或將螢幕切換為微光模式。

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

資料層

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

使用 Data Layer 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 介面中保持一致。