电池续航时间是用户体验的一个关键方面，而唤醒锁定在其中发挥着重要作用。您是否过度使用这些功能？在这篇博文中，我们将探讨什么是唤醒锁、使用唤醒锁的一些最佳实践，以及如何通过 Play 管理中心指标更好地了解您自己应用的行为。

Android Vitals 中的过度局部唤醒锁定使用情况

Play 管理中心现在会监控耗电情况，重点关注过度使用部分唤醒锁定这一关键性能指标。

此功能在现有核心指标（即用户感知到的过度崩溃和 ANR）的基础上，进一步提升了电池效率的重要性。我们已针对过度唤醒锁定定义了不良行为阈值。自 2026 年 3 月 1 日起，如果您的影视内容未达到此质量阈值，我们可能会将其从醒目的曝光途径（例如推荐）中排除。在某些情况下，我们可能会在您的商品详情中显示警告，告知用户您的应用可能会导致电池电量消耗过快。

Android Vitals 概览中的“唤醒锁定操作过多”警告。

对于移动设备，Android Vitals 指标适用于在屏幕关闭且应用在后台运行或运行前台服务时获取的非豁免唤醒锁定。如果出现以下情况，Android Vitals 会认为部分唤醒锁定使用量过高：

• 在 24 小时内，唤醒锁定至少保持 2 小时。
• 在 28 天内，平均有超过 5% 的应用会话受到影响。

由 audio、location 和 JobScheduler 用户启动的 API 创建的唤醒锁定不纳入唤醒锁定计算范围。

了解唤醒锁定

唤醒锁定是一种机制，可让应用即使在用户未主动与设备互动时也能保持设备 CPU 运行。

即使屏幕处于关闭状态，部分唤醒锁定也会使 CPU 保持运行，从而防止 CPU 进入低功耗“挂起”状态。完全唤醒锁定可让屏幕和 CPU 保持运行。

部分唤醒锁的获取方式有 2 种：

• 应用会针对特定使用情形，使用 PowerManager API 手动获取和释放唤醒锁定，通常会与 Foreground Service（一种旨在实现用户可感知操作的平台生命周期 API）结合使用。
• 或者，唤醒锁定由另一个 API 获取，并因使用该 API 而归因于应用，有关这方面的更多信息，请参阅最佳实践部分。

虽然唤醒锁定对于完成用户发起的大型文件下载等任务是必需的，但过度或不当使用会导致电池电量严重消耗。我们发现，有些应用会持有唤醒锁数小时，或者未能正确释放唤醒锁，导致用户即使未与应用互动，也会因电池耗电过快而投诉。

使用唤醒锁的最佳实践

在介绍如何调试过多的唤醒锁定使用情况之前，请确保您遵循了唤醒锁定最佳实践。

请考虑以下四个关键问题。

1. 您是否考虑过其他唤醒锁定选项？

在考虑获取手动部分唤醒锁定之前，请按照以下决策流程图操作：

用于确定何时手动获取唤醒锁的流程图

1. 屏幕需要保持开启状态吗？
   • 是：请改用保持屏幕开启文档
2. 应用是否正在运行前台服务？
   • 否：您无需手动获取唤醒锁定。
3. 设备暂停是否会损害用户体验？
   • 否：例如，在设备唤醒后更新通知不需要唤醒锁定。
   • 是：如果必须防止设备进入暂停状态（例如，正在与外部设备进行通信），请继续。
4. 是否有 API 代表您使设备保持唤醒状态？
   • 您可以利用文档识别由其他 API 创建的唤醒锁来识别由其他 API（例如 LocationManager）创建唤醒锁的场景。
   • 如果不存在任何 API，请继续回答最后一个问题。
5. 如果您已回答上述所有问题，并确定不存在替代方案，则应继续手动获取唤醒锁定。

2. 您是否正确命名了唤醒锁定？

手动获取唤醒锁时，正确的命名对于调试至关重要：

• 在名称中省去任何个人身份信息 (PII)，例如电子邮件地址。如果检测到 PII，唤醒锁定会被记录为 _UNKNOWN，从而妨碍调试。
• 请勿以编程方式使用类或方法名称来命名唤醒锁定，因为这些名称可能会被 Proguard 等工具混淆。您可以改用硬编码字符串。
• 请勿向唤醒锁定标签添加计数器或唯一标识符。每次运行唤醒锁定都应使用相同的标记，以便系统按名称汇总使用情况，从而更轻松地检测到异常行为。

3. 获取的唤醒锁定是否始终会释放？

如果您手动获取唤醒锁定，请确保始终执行唤醒锁定释放。未能释放唤醒锁定可能会导致严重耗电。

例如，如果在 processingWork() 期间抛出未捕获的异常，则可能永远不会发生 release() 调用。您可以改为使用 try-finally 代码块来确保即使发生异常，唤醒锁定也会被释放。

此外，您还可以为唤醒锁定添加超时时间，以确保它在特定时间段后释放，防止它被无限期持有。

  fun processingWork() {
    wakeLock.apply {
        try {
            acquire(60 * 10 * 1000) // timeout after 10 minutes
            doTheWork()
        } finally {
            release()
        }
    }
}

4. 能否降低唤醒频率？

对于周期性数据请求，减少应用唤醒设备的频率是电池优化的关键。以下是降低唤醒频率的一些示例：

• WorkManager：增加了 PeriodicWorkRequest 中的周期性间隔。
• SensorManager：通过在注册监听器时指定 maxReportLatencyMs 来利用批处理。
• 一体化位置信息提供程序：
  • 使用 getLastLocation 获取最近一次的缓存位置，从而降低位置信息检索频率。
  • 使用 setPriority(PRIORITY_PASSIVE) 可采用电池消耗量更低的更新方法。
  • 此外，您还可以通过使用 setMinUpdateIntervalMillis 设置最小更新间隔，来利用位置信息批处理机制。

如需查看更多详情，请参阅唤醒锁定最佳实践文档。

调试过度使用唤醒锁定的问题

即使是出于好意，也可能会过度使用唤醒锁定。如果您的应用在 Play 管理中心内被标记，请按以下步骤进行调试：

通过 Play 管理中心进行初始身份验证

Android Vitals“过多的部分唤醒锁定”信息中心会提供与您的应用相关联的非豁免唤醒锁定名称的细分数据，显示受影响的会话和持续时间。提醒您使用文档来帮助您确定唤醒锁定名称是由应用持有还是由其他 API 持有。

Android Vitals“过度使用部分唤醒锁定”信息中心向下滚动到细分部分，以查看过度唤醒锁定标记。

调试工作线程/作业持有的过多的唤醒锁定

您可以通过以下唤醒锁定名称来识别工作线程持有的唤醒锁定：

*job*/<package_name>/androidx.work.impl.background.systemjob.SystemJobService

如需查看工作线程持有的唤醒锁定名称的完整列表，请参阅文档。如需调试这些唤醒锁定，您可以使用后台任务检查器在本地进行调试，也可以利用 getStopReason 在现场调试问题。

Android Studio 后台任务检查器

后台任务检查器的屏幕截图，其中显示了它能够识别出经常重试并失败的工作器“WeatherSyncWorker”。

如需对 WorkManager 问题进行本地调试，请在模拟器或已连接的设备（API 级别 26 及更高版本）上使用此工具。该工具会显示工作器的列表及其状态（已完成、正在执行、已入队），让您可以检查详细信息并了解工作器链。

例如，它可以显示工作器是否因达到系统限制而频繁失败或重试。

如需了解详情，请参阅后台任务检查器文档。

WorkManager getStopReason

如需对具有过多唤醒锁的工作器进行实地调试，请在 WorkManager 2.9.0 及更高版本中使用 WorkInfo.getStopReason()，或在 SDK 31 及更高版本中使用 JobParameters.getStopReason()（适用于 JobScheduler）。

此 API 可帮助记录工作器停止的原因（例如，STOP_REASON_TIMEOUT、STOP_REASON_QUOTA），从而找出因运行时时长耗尽而导致频繁超时等问题。

  backgroundScope.launch {
    WorkManager.getInstance(context)
        .getWorkInfoByIdFlow(workRequest.id)
        .collect { workInfo ->
            logStopReason(workRequest.id, workInfo?.stopReason)
        }
}

如需了解详情，请参阅针对任务调度 API 优化电池用量。

调试其他类型的过度唤醒锁定

对于涉及手动持有唤醒锁定或 API 持有唤醒锁的更复杂场景，我们建议您使用系统跟踪收集进行调试。

系统轨迹收集

系统轨迹 是一种强大的调试工具，可捕获一段时间内的详细系统活动记录，从而深入了解 CPU 状态、线程活动、网络活动以及与电池相关的指标（例如作业时长和唤醒锁定使用情况）。

您可以使用多种方法捕获系统轨迹：

• 利用系统轨迹命令行工具
• 使用 Android Studio CPU 性能分析器
• 使用 Perfetto 界面
• 直接从开发者选项在设备上手动记录轨迹。

在 Perfetto 界面中的“Android apps & svcs”（Android 应用和服务）标签页下，启用“power:PowerManagement”Atrace 类别。 

无论选择哪种方法，都必须确保收集 “power:PowerManagement”Atrace 类别，以便查看设备状态轨迹。

Perfetto 界面检查和 SQL 分析

您可以在 Perfetto 界面中打开并检查系统轨迹。打开轨迹后，您会看到时间轴上各种进程的可视化效果。本指南将重点介绍“设备状态”下的轨道。

固定“设备状态”下的轨道，例如“热门应用”“屏幕状态”“长时间唤醒锁定”和“作业”轨道，以便直观地识别长时间运行的唤醒锁定切片。

每个块都会列出活动的名称、开始时间和结束时间。在 Perfetto 中，这称为切片。

如需对多个轨迹进行可扩缩的分析，您可以使用 Perfetto 的 SQL 分析。SQL 查询可以按时长找到所有唤醒锁定，从而帮助确定过度使用的主要原因。

以下是一个示例查询，用于对系统轨迹中出现的所有唤醒锁定标记求和，并按总时长排序：

  SELECT slice.name as name, track.name as track_name,SUM(dur / 100000) as total_dur_ms
FROM slice
JOIN track ON slice.track_id = track.id
WHERE track.name = 'WakeLocks'GROUP BY slice.name, track.name
ORDER BY total_dur_ms DESC

使用 ProfilingManager 进行现场跟踪记录收集

对于难以重现的问题，ProfilingManager（在 SDK 35 中添加）是一个程序化 API，可让开发者在现场通过开始和结束触发器收集系统轨迹。它可让您更好地控制配置文件收集的开始和结束触发点，并强制执行系统级速率限制，以防止影响设备性能。

如需进一步了解如何实现现场系统轨迹收集，请参阅 ProfilingManager 文档，其中包含如何以编程方式捕获轨迹、分析性能分析数据以及使用本地调试命令。

使用 ProfilingManager 收集的系统轨迹与手动收集的轨迹类似，但系统进程和其他应用进程会从轨迹中隐去。

总结

Android Vitals 中的“过度局部唤醒锁定”指标只是我们持续致力于支持开发者减少耗电和提高应用质量的一小部分。

通过了解并正确实现唤醒锁定，您可以显著优化应用的电池性能。利用替代 API、遵循唤醒锁定最佳实践，以及使用强大的调试工具（例如后台任务检查器、系统轨迹和 ProfilingManager）是确保应用在 Google Play 上取得成功的关键。