節省電力和電池

在 Wear OS 上，電力效率特別重要。Wear OS 設計 原則，因為手錶是一種 小型板型規格，適用於簡短互動。

與大型行動裝置相比，Wear OS 裝置電池容量較小， 都比較明顯耗盡電力此外，使用者必須投入更多心力 為 Wear OS 裝置充電雖然使用者可以 他們的行動裝置在一天當中不時分時，必須 在為 Wear OS 裝置充電前，先從身體上卸下 Wear OS 裝置。

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

  • 應用程式的設計應善用 Wear OS 板型規格。這項服務 不得直接複製您的行動應用程式
  • 將現有的行動應用程式用於某些用途。例如： 手錶網路和同步是高昂的費用；思考 這項繁雜工作或許是由行動裝置 而 Wear OS 裝置 資料變化
  • 因此，設計時應考量較短的互動。
  • 請思考您會使用哪些 Wear OS 事件，以及這些事件的頻率 。

  • 請盡可能延後應用程式的運作，直到手錶充電為止。 這尤其適用於需要大量資料的工作，例如同步處理資料 整理資料庫

    如果裝置正在充電且具有 Wi-Fi 連線，請將工作排定在 預先擷取使用者可能想在 應用程式。

本電源指南會協助您瞭解系統執行應用程式的時機和方式，以及 如何限制應用程式的執行階段和電池耗電如要進一步瞭解如何 例如載入應用程式或捲動瀏覽 清單—查看效能相關指南，例如 Compose on Wear OS 上的 Compose 效能指南。

持續監控電池用量變化

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

adb shell dumpsys batterystats

GitHub 上的程式庫提供電池統計資料剖析器， 與這個指令搭配使用時也很實用

影響電池續航力的事件

在認真考量應用程式前，請更廣泛地思考 針對 Wear OS 裝置消耗電源的事件。

下表顯示了數個對電池壽命的相對影響 Wear OS 應用程式中的常見事件確切的耗電量會因裝置而異。

活動 對電池續航力的影響 如何緩解
存取網路，包括 LTE 和 Wi-Fi 非常高 延後到不必要的網路存取時間，直到裝置充電為止。
開啟螢幕並啟動互動模式 高 不得鼓勵使用者在螢幕上停留超過 無從得知提供使用 持續待機 模式，也稱為微光模式。
存取 GPS 感應器 高 盡可能等待使用者要求 GPS 存取。
保持高 CPU 使用率 高 共享 資料流
存取心率感應器 中 使用處理器的清醒時間的時機 接收來自感應器 API 的回呼，例如使用 啟用健康照護服務 Wear OS：
透過藍牙存取其他裝置 中 課程應力求簡短。
保持喚醒鎖定 中 減少手動建立 Wake Lock 和使用次數 WorkManager。

盡可能減少螢幕開啟時間

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

  • 螢幕鎖定：請盡量避免使用。如要測試，請關閉「一律開啟」 顯示畫面，並觀察螢幕是否在 逾時期限。
  • 動畫：將精美的動畫減少到摘要上 加上轉場效果，打造更專業的外觀尤其是避免長時間執行 像是動畫和迴圈如果需要迴圈，請在迴圈之間加入暫停 至少跟動畫本身一樣

  • 在微光模式下醒來的時間：可視需要一律開啟，例如 或是健身用途如果您的應用程式需要一律啟用，請檢查應用程式是否 裝置處於微光模式時：

    • 降低裝置螢幕亮起的機率。
    • 不會顯示動畫。
    • 不會更新畫面內容 (只有在 onAmbientUpdate() 回呼。

盡可能減少 CPU 使用率

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

  • 使用時間應力求精簡。
  • 批次處理任何相關作業，盡可能延長應用程式處理程序的時間 閒置中。

盡量減少喚醒鎖定

在大多數情況下，請避免執行任何妨礙應用程式休眠的作業，例如： 例如 Wakelocks。以健康和健身應用程式, 長時間跑步訓練 而不必設定喚醒鎖定使用處理器的清醒時間來接收回呼 ，例如 Wear OS 上的健康照護服務。

在某些情況下可以取得喚醒鎖定，例如 應用程式會執行下列其中一項作業：

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

Battery Historian 可讓您查看個別長時間的發生事件 以及喚醒鎖定總數和持續時間的摘要 來回應檢查應用程式的喚醒鎖定次數和持續時間 保存、將此資訊與 應用程式：

  • 檢查是否有非預期的 Wake Lock。
  • 如果持續時間比預期長，請思考工作是否 部分依附元件 (例如網路的可用性) 遭到封鎖。

檢查應用程式的閒置狀態

思考發生重要事件時，運作中的應用程式正在執行的動作，例如 包括：

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

  • 應用程式以滑動方式關閉。

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

能源分析器

如要在 Android Studio 選單中存取能源分析器，請選取 檢視 >工具視窗 >Profiler：

  1. 在螢幕關閉且裝置進入時檢查系統追蹤記錄 微光效果
  2. 請檢查是否有任何持續執行的作業，以及裝置的 CPU 使用率。

Perfetto

Perfetto 可讓您錄製追蹤記錄並檢查應用程式，確認是否出現 無論在螢幕或裝置、 進入微光模式，或使用者關閉應用程式活動。

定義自訂事件來標記應用程式的重大事件，包括 特定網域專屬的事件如果是媒體應用程式，則包括擷取 播放清單、下載特定媒體項目、開始播放並停止 播放。定義這些事件後，您就可以在 Perfetto 中查看這些事件 例如應用程式的 CPU 和耗電量

分析應用程式的排程工作

透過 WorkManager 的排定工作，您可以在以下容器中執行背景工作： 應用程式。雖然部分背景工作必須定期執行，但請避免同時執行工作 ，因為這種連線方式會消耗裝置的電力。

使用 Battery Historian 檢查排定的工作執行情況 (兩者皆可) 整體 (系統統計資料 > Jobscheduler 統計資料) 和依據應用程式 (應用程式統計資料 > 已加入排程的工作)。查看總數和總時長：

  • 如果工作執行頻率很高，請考慮降低這個執行頻率。
  • 檢查總執行時間是否與預期相符，且不會 遠遠更久。

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

  • 對你的應用程式而言，執行時間長度應該合理。
  • 請思考這些工作是在應用程式執行期間進行，還是 工作代表週期性背景工作。

感應器

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

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

adb shell dumpsys sensorservice

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

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

測試從感應器取消註冊

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

  1. 滑動關閉應用程式。
  2. 用手掌輕觸螢幕。這會關閉螢幕 會讓螢幕進入微光模式。

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

資料層

使用 Data Layer API 時，每項傳輸作業都會耗用一定電力。於 請特別注意，如果您使用這個 API 傳送資料，則必須喚醒應用程式才能收到 實體媒介包括儲存空間陣列 傳統硬碟、磁帶和 USB 隨身碟等因此，使用 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 介面上的資料一致。