节省电量和电量

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

最大限度地缩短屏幕开启时间

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

  • 屏幕锁定：尽可能避免。如需测试，请在系统设置中关闭屏幕常亮，并观察屏幕是否在超时期限内关闭。
  • 动画：尽量减少复杂的动画，而着重使用简短的过渡，以获得更专业的外观。尤其要避免长时间运行动画和循环。如果需要循环，请在循环之间添加一个暂停，该暂停至少与动画本身一样长。

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

    • 减少设备的屏幕亮起百分比。
    • 不显示动画。
    • 不更新屏幕内容（onAmbientUpdate() 回调期间除外）。

最大限度地降低 CPU 使用率

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

  • 尽量缩短使用时间。
  • 批处理任何相关操作，以最大限度地延长应用的进程空闲时间。

最大限度地减少唤醒锁定

在大多数情况下，应避免执行任何会阻止应用休眠的操作，例如唤醒锁定。例如，在健康与健身应用中，长时间的锻炼不需要唤醒锁。从 Sensor API 接收回调时（例如，在 Wear OS 上使用健康服务时），使用处理器的唤醒时间。

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

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

借助 Battery Historian，您可以查看长时间唤醒锁定的各个发生次数，以及持有唤醒锁定的总次数和持续时间的摘要。检查应用持有的唤醒锁的次数和持续时间，并将此信息与应用的交互使用模式进行比较：

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

检查应用如何变为非活跃状态

考虑当发生关键设备事件时，活跃应用在执行哪些操作，例如：

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

  • 应用为滑动关闭状态。

如需分析应用活动，请使用下面几部分中介绍的工具。

能耗性能分析器

您可以在 Android Studio 菜单中访问 Energy Profiler，方法是依次选择 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 之间保持一致。