节省电量和电量

节能在 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 和 WLAN 非常高 推迟非必需的网络访问，直到设备充电。
开启屏幕并启动交互模式 高 请勿鼓励用户让屏幕保持开启状态的时间超出必要。提供使用始终开启模式（也称为氛围模式）的体验。
访问 GPS 传感器 高 如果可能，请等到用户请求 GPS 访问权限。
使 CPU 使用率保持较高水平 高 使用 Jetpack Compose 使用数据流。
访问心率传感器 中 从传感器 API 接收回调时（如使用 Wear OS 上的健康服务时），请使用处理器的唤醒时间。
通过蓝牙访问其他设备 中 让会话保持简短。
保持唤醒锁定 中 减少手动创建唤醒锁的次数，并使用 WorkManager。

尽量缩短屏幕开启时间

在 Wear OS 应用中，请遵循以下屏幕使用原则：

  • 屏幕开启锁定：请尽可能避免。如需进行测试，请在系统设置中关闭屏幕常亮，然后观察屏幕是否会在超时期限内关闭。
  • 动画：尽量减少使用复杂的动画，而应着重于使用简短的转场效果，以打造更专业的外观。特别是要避免长时间运行的动画和循环。如果需要循环播放，请在循环之间添加至少与动画本身一样长的时间的暂停。

  • 氛围模式下的唤醒时间：根据需要支持始终开启，例如在健身用例中。如果您的应用要求始终开启，请在设备处于氛围模式时检查应用是否会执行以下操作：

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

最大限度地降低 CPU 使用量

在 Wear OS 应用中，请遵循以下 CPU 使用率原则：

  • 使用情况信息应尽量简短。
  • 批处理所有相关操作，以最大限度地延长应用进程的空闲时间。

尽量减少唤醒锁

在大多数情况下，请避免任何阻止应用进入休眠的操作，如唤醒锁定。例如，在健康和健身应用中，长时间运行的锻炼不需要唤醒锁。在从传感器 API 收到回调时使用处理器的唤醒时间，例如在使用 Wear OS 上的健康服务时。

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

  • 在后台播放媒体内容。
  • 使用 WorkManager 或 JobScheduler。（在后台运行作业时，系统会代表您保持唤醒锁。）

借助 Battery Historian，您可以查看长时间唤醒锁的具体出现情况，以及唤醒锁的总数和时长的摘要。检查应用保持的唤醒锁定的次数和持续时间，并将此信息与应用的交互式使用模式进行比较：

  • 检查是否存在意外的唤醒锁。
  • 如果时长比预期长，请考虑工作是否因某些依赖项（例如网络可用性）而被阻塞。

检查应用变为非活动状态的方式

考虑在发生关键设备事件（例如以下事件）时，处于活动状态的应用正在执行的操作：

  • 屏幕关闭，设备进入氛围模式。

  • 应用会被滑动关闭。

如需分析应用活动，请使用以下部分中所述的工具。

功耗性能分析器

如需在 Android Studio 菜单中访问能耗性能分析器，请依次选择 View > Tool Windows > Profiler：

  1. 在屏幕关闭且设备进入氛围模式时检查系统轨迹。
  2. 查找是否有任何工作仍在继续，以及设备的 CPU 使用率。

Perfetto

借助 Perfetto，您可以录制轨迹，然后检查应用，看看当屏幕关闭、设备进入氛围模式或用户关闭应用的 activity 时，是否有任何线程正在执行任何工作。

定义自定义事件以标记应用的重要事件，包括特定于网域的事件。对于媒体应用，这包括提取播放列表、下载特定媒体内容、开始播放和停止播放等任务。通过定义这些事件，您可以在 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 发送数据，则应用必须唤醒才能接收数据。因此，请谨慎使用此 API。

有关使用数据层 API 的其他一些最佳实践包括：

  • 请等到应用处于活动状态，然后再使用 WearableListenerService 设置监听器。

  • 传输状态变化，而不是配置快速更新。通过这些状态更改，Wear OS 设备可以执行本地数据计算，例如在锻炼时段开始时。

    仅传输用于更新界面的状态变化。例如，如果您的活动屏幕仅显示小数一位数的“跑步公里数”，请勿在用户每次向前移动一米时都向 Wear OS 发送状态更改。

如需分析应用中的 Data Layer API 使用情况，请在开发机器上的终端窗口中运行以下命令：

adb shell dumpsys activity service WearableService

此命令的结果包括：

  • RpcService：可让您查看使用 MessageClient 调用的频率和调用的路径。
  • DataService：可让您查看使用 DataClient 设置数据项的频率。

健康与健身应用

如果您负责维护健康与健身应用，请使用健康服务优化应用对传感器的使用。

  • 对于 ExerciseClient，请使用 Battery Historian 验证氛围模式下的行为是否正确。检查您的应用唤醒的频率是否不高于每两三分钟一次，以接收 ExerciseUpdate 数据。
  • 对于全天的一般健康监控，请按照有关如何在后台监控健康与健身数据的指南中所述使用 PassiveMonitoringClient。

功能块和复杂功能

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

  • 停用自动刷新功能，或将刷新率提高到 2 小时或更长时间。
  • 使用 Firebase 云消息传递 (FCM) 或适当安排的作业发送数据更新。请务必防止更新速率过快，否则可能会导致系统安排重复工作的速度超过用户或平台访问执行该工作的所需数据的速度。
  • 请勿在用户未与功能块或复杂功能互动时为其安排工作。
  • 使用离线优先方法。
  • 在主应用、功能块和复杂功能之间共享单个数据库。这也有助于在各种界面中保持数据一致性。