节省电量和电量

节能在 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 使用数据流。
访问心率传感器 Medium 从传感器 API 接收回调时（如使用 Wear OS 上的健康服务时），请使用处理器的唤醒时间。
通过蓝牙访问其他设备 Medium 保持会话简短。
保持唤醒锁定 Medium 减少手动创建唤醒锁定的情况并使用 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。

使用 Data Layer API 的一些其他最佳实践包括：

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

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

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

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

adb shell dumpsys activity service WearableService

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

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

健康与健身应用

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

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

功能块和复杂功能

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

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