节省电量和电池

电源效率在 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 时),请利用处理器的唤醒时间。
通过蓝牙访问其他设备 中等 保持会话简短。
持有唤醒锁 中等 减少手动创建唤醒锁,并使用 WorkManager

缩短亮屏时间

在您的 Wear OS 应用中,请遵循以下屏幕使用原则

  • 亮屏锁定:尽可能避免。要测试,请在系统设置中关闭常亮显示,并观察屏幕是否在超时期限内熄灭。
  • 动画:尽量减少复杂的动画,转而专注于简短的过渡,以获得更专业的观感。特别是,避免长时间运行的动画和循环。如果需要循环,请在循环之间添加至少与动画本身一样长的暂停时间。
  • 微光模式下的唤醒时间:如有必要(例如健身用例),支持始终开启。如果您的应用需要始终开启,请在设备处于微光模式时检查您的应用是否执行以下操作

    • 降低设备屏幕的亮起百分比。
    • 不显示动画。
    • 不更新屏幕内容,除非在 onAmbientUpdate() 回调期间。

最小化 CPU 使用率

在您的 Wear OS 应用中,请遵循以下 CPU 使用原则

  • 保持使用时间简短。
  • 批量处理任何相关操作,以最大化应用进程的空闲时间。

最小化唤醒锁

在大多数情况下,避免任何阻止应用休眠的操作,例如唤醒锁。例如,在健康和健身应用中,长时间运行的锻炼不需要唤醒锁。在接收来自传感器 API 的回调时(例如使用 Wear OS 上的 Health Services 时),请利用处理器的唤醒时间。

在某些情况下,可以获取唤醒锁,例如当您的应用执行以下操作之一时

  • 在后台播放媒体。
  • 使用 WorkManagerJobScheduler。(系统在后台运行作业时会为您持有唤醒锁。)

Battery Historian 允许您查看长时间唤醒锁的单个出现情况,以及唤醒锁的总数和持续时间的摘要。检查您的应用持有的唤醒锁的数量和持续时间,并将此信息与您应用的交互式使用模式进行比较

  • 检查是否存在意外的唤醒锁。
  • 如果持续时间超出预期,请考虑工作是否被某些依赖项(例如网络可用性)阻塞。

检查您的应用如何变为非活动状态

考虑当关键设备事件发生时,活动应用正在做什么,例如以下情况

  • 屏幕熄灭,设备进入微光模式。
  • 应用被滑动关闭

要分析应用活动,请使用以下部分中显示的工具。

电源分析器

可通过在 Android Studio 菜单中选择 View > Tool Windows > Profiler 来访问电源分析器

  1. 检查屏幕熄灭和设备进入微光模式时的系统跟踪。
  2. 查找任何仍在进行的工作,以及设备的 CPU 使用率水平。

Perfetto

Perfetto 允许您记录跟踪,然后检查您的应用,查看当屏幕关闭、设备进入微光模式或用户关闭您应用的 activity 时,是否有任何线程正在执行任何工作。

定义自定义事件来标记您应用的重要事件,包括特定于领域的事件。对于媒体应用,这可能包括获取播放列表、下载特定媒体项、开始播放和停止播放等任务。通过定义这些事件,您可以在 Perfetto 中看到它们,并将它们的时间与您应用的 CPU 和功耗使用情况进行比较。

分析您应用的计划作业

使用 WorkManager 的计划作业允许您在应用中执行后台工作。虽然有些后台工作必须是周期性的,但不要过于频繁或长时间运行作业,因为这会耗尽设备的电池。

使用 Battery Historian 检查计划作业的执行情况,包括总体(System stats > Jobscheduler stats)和按应用(App stats > Scheduled job)。检查总计数和总持续时间

  • 如果作业运行非常频繁,请考虑降低此频率。
  • 检查总执行时间是否符合您的预期,并且没有明显更长。

此外,检查 Battery Historian 图表,查看每个 JobScheduler 条目。当您将指针悬停在特定条目上时,Battery Historian 会显示正在执行的作业的所有者。请考虑以下几点

  • 对于您的应用,执行持续时间应该合理。
  • 考虑作业是否在您的应用运行时发生,或者作业是否代表周期性后台工作。

传感器

Wear OS 设备有许多不同的传感器,例如 GPS。在大多数情况下,使用 Wear OS 上的 Health Services 而不是直接与 SensorManager 交互。在许多情况下,Health Services 会智能地批量处理数据以提高电池性能。

要分析您应用中的传感器使用情况,请在开发机器的终端窗口中运行以下命令

adb shell dumpsys sensorservice

此命令的结果显示以下内容

  • 当前和以前的传感器注册。
  • 传感器配置,包括是否设置了批处理。
  • 最近采样的数据。

测试传感器注销

要检查您的应用是否按预期停止获取传感器数据,请测试以下场景

  1. 滑动关闭您的应用。
  2. 用手掌轻触屏幕。这会关闭屏幕或将屏幕置于微光模式。

使用上一节中的 ADB 命令检查传感器是否正确显示为未注册。

数据层

使用数据层 API 时,每次传输都会消耗一些电量。特别是,如果您使用此 API 发送数据,您的应用必须唤醒才能接收数据。出于这些原因,请谨慎使用此 API。

使用数据层 API 的其他一些最佳实践包括以下几点

  • 在使用 WearableListenerService 设置监听器之前,请等待您的应用处于活动状态。
  • 传输状态更改而不是配置快速更新。这些状态更改允许 Wear OS 设备执行本地数据计算,例如锻炼会话何时开始。

    仅传输更新您界面的状态更改。例如,如果您的活动屏幕仅显示“已跑公里数”到一位小数,则不要在用户每前进一米时就向 Wear OS 发送状态更改。

要分析您应用中的数据层 API 使用情况,请在开发机器的终端窗口中运行以下命令

adb shell dumpsys activity service WearableService

此命令的结果包括以下内容

  • RpcService: 允许您查看使用 MessageClient 调用路径的频率和具体路径。
  • DataService: 允许您查看使用 DataClient 设置数据项的频率。

健康和健身应用

如果您维护健康和健身应用,请使用 Health Services 来优化您的应用对传感器的使用。

  • 对于 ExerciseClient,请使用 Battery Historian 来验证微光模式下的正确行为。检查您的应用是否不会每隔一两分钟就唤醒一次以接收 ExerciseUpdate 数据。
  • 对于全天候一般健康监测,请使用 PassiveMonitoringClient,如关于如何在后台监测健康和健身数据的指南中所述。

瓷块和复杂功能

如果您的应用支持瓷块复杂功能,请遵循以下最佳实践

  • 禁用自动刷新,或将刷新频率增加到 2 小时或更长。
  • 使用 Firebase Cloud Messaging (FCM)适当计划的作业来发送数据更新。请注意防止过快的更新速率,这可能导致系统以比用户或平台访问执行该工作所需数据更快的速率安排重复工作。
  • 当用户不与您的瓷块或复杂功能互动时,不要为其安排工作。
  • 使用离线优先方法
  • 在您的主应用、瓷块和复杂功能之间共享一个数据库。这也有助于数据在不同界面上保持一致。