節省電力和電池

在 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 上的健康照護服務

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

  • 在背景播放媒體。
  • 使用 WorkManagerJobScheduler。(系統會保留 在背景執行工作時為您代您 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 介面上的資料一致。