在 Wear OS 上,電力效率特別重要。Wear OS 設計原則著重於裝置耗電量,因為手錶是適用於短時間內互動的小型板型規格。
與大型行動裝置相比,Wear OS 裝置的電池容量較小,因此電池耗電量都較為明顯。此外,與行動裝置相比,使用者需要花更多心力為 Wear OS 裝置充電。雖然使用者一天中可以以不同間隔為行動裝置充電,但必須先從身體卸離 Wear OS 裝置,才能為裝置充電。
如要提升應用程式的電池效能,請遵循下列設計最佳做法:
- 應用程式的設計應善用 Wear OS 板型規格。不應直接複製您的行動應用程式。
- 將現有的行動應用程式用於某些用途。舉例來說,手錶上的網際網路和同步處理作業相當昂貴;請考量行動裝置是否能夠進行這類繁重工作,以及 Wear OS 裝置接收資料變更。
- 因此,設計時應考量較短的互動。
- 請決定您正在使用哪些 Wear OS 事件,以及這些事件的發生頻率。
請盡可能延後應用程式的運作,直到手錶充電為止。這特別適用於需要處理大量資料的工作,例如同步處理資料及整理資料庫。
如果裝置正在充電且具有 Wi-Fi 連線,請為工作排定工作時間,預先擷取使用者可能想在應用程式中查看的資料、映像檔和更新項目。
本電源指南可協助您瞭解系統執行應用程式的時間和方式,以及如何限制應用程式的執行階段和電池耗電。如要進一步瞭解如何執行特定動作 (例如載入應用程式或捲動清單),請參閱效能相關指南,例如 Compose on Wear OS 效能指南。
持續監控電池用量變化
如要分析執行應用程式的 Wear OS 裝置電池統計資料,請在開發機器的終端機視窗中輸入下列指令:
adb shell dumpsys batterystats
GitHub 上的程式庫提供電池統計資料剖析器,可搭配這個指令使用。
影響電池續航力的事件
在具體考慮應用程式之前,建議您更廣泛地思考在 Wear OS 裝置上消耗電源的事件。
下表列出 Wear OS 應用程式多個常見事件對電池續航力的相對影響。確切的耗電量會因裝置而異。
活動 | 對電池續航力的影響 | 如何緩解 |
---|---|---|
存取網路,包括 LTE 和 Wi-Fi | 非常高 | 延後到不必要的網路存取時間,直到裝置充電為止。 |
開啟螢幕並啟動互動模式 | 高 | 請勿鼓勵使用者長時間停留在螢幕上。提供使用螢幕長亮模式 (又稱為微光模式) 的內容。 |
存取 GPS 感應器 | 高 | 盡可能等待使用者要求 GPS 存取。 |
保持高 CPU 使用率 | 高 | 使用 Jetpack Compose 執行資料流。 |
存取心率感應器 | 媒介 | 從感應器 API 接收回呼時,使用處理器的清醒時間,例如 Wear OS 上的健康照護服務時。 |
透過藍牙存取其他裝置 | 媒介 | 課程應力求簡短。 |
保持喚醒鎖定 | 媒介 | 減少手動建立 Wake Lock,並使用
WorkManager 。 |
盡可能減少螢幕開啟時間
在 Wear OS 應用程式中,請遵守下列螢幕使用原則:
- 螢幕鎖定:請盡量避免使用。如要進行測試,請在系統設定關閉「螢幕長亮模式」,並觀察螢幕是否在逾時期限內關閉。
- 動畫:盡量減少複雜的動畫,改為將焦點放在簡短的轉場效果,打造更專業的外觀。尤其請避免使用長時間執行的動畫和迴圈。如果需要迴圈,請在循環之間加入暫停,至少與動畫本身一樣。
微光模式的時間喚醒:如有必要,例如一律開啟,例如健身用途。如果應用程式需要一律開啟,請檢查應用程式是否在裝置處於微光模式時執行以下操作:
- 降低裝置螢幕亮起的機率。
- 不會顯示動畫。
- 除非發生
onAmbientUpdate()
回呼,否則不會更新畫面內容。
盡可能減少 CPU 使用率
請在 Wear OS 應用程式中遵守以下 CPU 使用原則:
- 使用時間應力求精簡。
- 批次處理任何相關作業,盡可能延長應用程式程序處於閒置狀態的時間。
盡量減少喚醒鎖定
在大多數情況下,請避免執行任何導致應用程式無法休眠的作業,例如 Wakelock。舉例來說,在健康與健身應用程式中,長時間執行的健身不需要使用喚醒鎖定。接收來自感應器 API 的回呼時,請使用處理器的清醒時間,例如 Wear OS 上的健康照護服務時。
在某些情況下,可以取得喚醒鎖定,例如應用程式執行下列其中一項作業:
- 在背景播放媒體。
- 使用
WorkManager
或JobScheduler
。(系統會在背景執行工作時,代表您持有 Wake Lock)。
Battery Historian 可讓您查看個別長時間的喚醒鎖定,以及保持喚醒鎖定總數和持續時間的摘要。檢查應用程式保留的 Wake Lock 次數和持續時間,並將這項資訊與應用程式的互動式使用模式進行比較:
- 檢查是否有非預期的 Wake Lock。
- 如果持續時間比預期長,請考量工作是否因某些依附元件 (例如網路可用性) 而遭到封鎖。
檢查應用程式的閒置狀態
請思考發生按鍵裝置事件時,運作中的應用程式會執行什麼動作,例如:
- 螢幕關閉時,裝置會進入微光模式。
應用程式以滑動方式關閉。
如要分析應用程式活動,請使用以下各節所示的工具。
能源分析器
依序選取「View」>「Tool Windows」>「Profiler」,即可在 Android Studio 選單中存取能源分析器:
- 在螢幕關閉且裝置進入微光模式時,檢查系統追蹤記錄。
- 請檢查是否有任何持續執行的作業,以及裝置的 CPU 使用率。
Perfetto
Perfetto 可讓您記錄追蹤記錄並檢查應用程式,瞭解在螢幕關閉、裝置進入微光模式,或使用者關閉應用程式活動時,是否有任何執行緒正在執行任何工作。
定義自訂事件來標記應用程式的重大事件,包括網域專屬事件。若是媒體應用程式,則包括擷取播放清單、下載特定媒體項目、開始播放及停止播放等工作。定義這些事件後,您就可以在 Perfetto 中查看這些事件,並與應用程式的 CPU 和耗電量進行比較。
分析應用程式的排程工作
您可以利用 WorkManager 排定的工作,在應用程式中執行背景工作。雖然部分背景工作必須定期執行,但請避免頻繁或長時間執行工作,以免消耗裝置的電池電量。
使用 Battery Historian 檢查整體排定的工作執行情況 (系統統計資料 > 工作排程器統計資料),以及依應用程式 (應用程式統計資料 > 已排定的工作) 檢查。查看總數和總時長:
- 如果工作執行頻率很高,請考慮降低這個執行頻率。
- 檢查總執行時間是否符合您的預期,不會大幅超出預期。
此外,檢查 Battery Historian 圖表,查看每個 JobScheduler 項目。將滑鼠指標懸停在特定項目上時,Battery Historian 會顯示執行工作的擁有者。請考量下列幾項重點:
- 對你的應用程式而言,執行時間長度應該合理。
- 請思考這些工作是在應用程式執行期間進行,還是這些工作代表週期性背景工作。
感應器
Wear OS 裝置搭載許多不同的感應器,例如 GPS。在大多數情況下,請使用 Wear OS 上的健康照護服務,而非直接與 SensorManager
互動。在許多情況下,健康照護服務會透過智慧方式批次處理資料,以改善電池效能。
如要分析應用程式的感應器使用情形,請在開發機器的終端機視窗中執行下列指令:
adb shell dumpsys sensorservice
這項指令的結果會顯示以下內容:
- 目前和先前的感應器註冊資料。
- 感應器設定,包括批次設定 (如有)。
- 最近取樣的資料。
測試從感應器取消註冊
如要檢查應用程式是否正常停止擷取感應器資料,請測試下列情境:
- 滑動關閉應用程式。
- 用手掌輕觸螢幕。藉此關閉螢幕或將螢幕置於微光模式。
使用上一節的 ADB 指令,檢查感應器是否正確顯示為未註冊。
資料層
使用 Data Layer API 時,每項傳輸作業都會耗用一定電力。請特別注意,如果您使用這個 API 傳送資料,則應用程式必須喚醒應用程式才能接收資料。因此,使用 API 時請務必謹慎。
使用 Data Layer API 的其他最佳做法包括:
- 請等到應用程式處於啟用狀態後,再使用
WearableListenerService
設定事件監聽器。 傳送狀態變更,而非設定快速更新。這些狀態變更可讓 Wear OS 裝置執行本機資料計算,例如健身工作階段開始時。
僅傳輸更新 UI 的狀態變更。舉例來說,如果您的活動畫面只顯示「跑公里數」到小數點後 1 位,請不要在每次使用者移動另一個計量器時,將狀態變更傳送至 Wear OS。
如要分析應用程式的 Data Layer API 用量,請在開發機器的終端機視窗中執行下列指令:
adb shell dumpsys activity service WearableService
這個指令執行的結果如下:
- RpcService:可讓您查看使用
MessageClient
呼叫的頻率和路徑。 - DataService:可讓您瞭解使用
DataClient
設定資料項目的頻率。
健康與健身應用程式
如果您維護的是健康與健身應用程式,請使用健康照護服務,最佳化應用程式的感應器使用方式。
- 如果是
ExerciseClient
,請使用 Battery Historian 驗證微光模式中的正確行為。檢查應用程式的喚醒頻率通常不超過每分鐘一兩分鐘,以接收ExerciseUpdate
資料。 - 如要全天進行一般健康監控,請使用
PassiveMonitoringClient
,詳情請參閱在背景監控健康與健身資料的相關指南。
資訊方塊和小工具
如果您的應用程式支援資訊方塊或小工具,請按照下列最佳做法操作:
- 停用自動重新整理功能,或將重新整理頻率提高至 2 小時以上。
- 請使用 Firebase 雲端通訊 (FCM) 或適當的排程工作傳送資料更新。請務必小心,以免更新速度過快,導致系統以比使用者或平台存取執行工作所需的資料更快的速度排定重複工作的執行頻率。
- 請勿在使用者未與資訊方塊或小工具互動時,為資訊方塊或小工具安排工作時程。
- 採用離線優先的方法。
- 跨主要應用程式、資訊方塊和小工具共用單一資料庫。這也有助於各 UI 介面的資料保持一致。
為您推薦
- 注意:系統會在 JavaScript 關閉時顯示連結文字
- 在背景存取位置資訊
- 設定鬧鐘
- 建立進階小工具 {:#advanced-widget}