如何防止你的安卓应用程序因“唤醒锁定”功能而过度消耗电池电量

“唤醒锁”是Android系统中最简单的API之一，同时也是最容易被误用的功能之一。获取一个唤醒锁只需要一行代码；但如果忘记释放它，手机的CPU可能会持续工作数小时，从而导致电池在夜间被耗尽，同时你的应用程序也可能会在Google Play上收到警告标签。

大多数与唤醒锁相关的错误并不是由于对API本身的误解造成的，而是源于一些常见的控制流程问题：比如在调用acquire()和release()方法之间抛出了异常、程序过早退出、回调函数从未被执行，或者引用计数出现了失衡。

这些错误在代码审查过程中很难被发现，在常规测试中也无法显现出来，因为通常情况下设备都是处于连接电源且处于唤醒状态的状态。

本文将解释唤醒锁在系统层面上究竟起到了什么作用，分析应用程序最常见的导致唤醒锁泄漏的原因，并提供具体的预防和检测方法。同时，本文还会介绍一些现代API，这些API在大多数情况下已经消除了手动使用唤醒锁的必要性。

目录

• 先决条件

• Android设备进入睡眠状态时会发生什么

• 唤醒锁的作用是什么

• 唤醒锁的类型

• 如何获取和释放唤醒锁

• 引用计数机制的工作原理

• 应用程序导致唤醒锁泄漏的常见原因

• 防止泄漏的方法和模式

• 在什么情况下完全不需要使用唤醒锁

• 如何检测唤醒锁泄漏现象

• 如何测试唤醒锁的行为

• 框架之外的唤醒锁机制

• 总结

先决条件

你应该能够熟练使用Kotlin编写Android应用程序，并且需要了解服务、广播接收器以及协程的基本概念。

此外，你还需要安装adb工具，并准备一台真实的设备用于调试。模拟器无法真实地模拟设备的电源状态，因此本文后面提到的一些命令在模拟器上运行时可能会产生错误的结果。

Android设备进入睡眠状态时会发生什么

当屏幕熄灭且没有其他程序需要使用CPU时，Android会将应用程序处理器置于低功耗待机状态。在这种状态下，CPU会停止执行指令，大部分RAM会保持自刷新状态，只有少数硬件模块（如调制解调器、实时时钟、传感器接口以及一些中断控制器）会继续运行。虽然设备看起来处于空闲状态，但一旦有中断信号到来，它就能立即恢复唤醒状态并开始工作。

Android采用了一种名为“自动睡眠”的机制。当系统没有继续运行的必要时，内核会尝试让系统进入休眠状态。任何需要CPU持续运行的进程，都必须通过某种方式明确告诉内核这一需求，这种方式就是持有“唤醒源”（在Android中，这种机制被称为“唤醒锁”）。只要至少有一个唤醒源处于激活状态，内核就不会让系统进入休眠模式。

 屏幕关闭
     |
     v
 有任何激活的唤醒源吗？ == 是 ==> CPU保持运行状态
     |
     否
     |
     v
 内核使CPU进入休眠状态
     |
     v
 中断事件发生（闹钟、网络数据包、按钮被按下）
     |
     v
 CPU恢复运行，相应的驱动程序或框架会获取唤醒锁来处理该事件

上图展示了在屏幕关闭状态下，内核会反复做出的这些决策。如果存在任何激活的唤醒源，CPU就会继续运行；如果没有这样的唤醒源，系统就会进入休眠状态，直到有硬件中断发生。当设备恢复运行时，处理该中断事件的代码通常会获取短暂的唤醒锁，以便能够在内核再次尝试让系统进入休眠模式之前完成自己的工作。

需要重点注意的是，让CPU保持运行状态是需要应用程序主动选择的。除非有某种机制在为应用程序持有唤醒锁，否则在屏幕关闭状态下，应用程序是无法获得CPU资源的。

唤醒锁的作用

应用层级的唤醒锁实际上是向PowerManagerService发出的请求，而这个系统服务是运行在system_server进程中的。当你的应用程序调用acquire()方法时，这个请求会通过Binder传递给该服务，服务会记录下这个请求，同时还会记录下你的UID、一个标识字符串以及唤醒锁的类型。PowerManagerService会将所有应用程序的这些请求汇总起来，然后代表所有这些应用程序持有一个内核级别的唤醒源。当最后一个应用层级的唤醒锁被释放时，该内核唤醒源也会被取消，此时设备就可以进入休眠状态了。

这种设计有两个值得注意的地方。首先，系统能够清楚地知道是哪个应用程序持有了哪个唤醒锁，以及持有的时间长度；因此，电池使用统计数据和Play Console的监控数据才能将特定的问题归咎于某个具体的应用程序。

其次，PowerManagerService会通过Binder的通知机制，将每个唤醒锁与对应的应用程序进程关联起来。如果某个应用程序进程终止了，系统会自动释放它所持有的所有唤醒锁。因此，这些唤醒锁的存在时间是受限于相应应用程序进程的生命周期的；不过，那些正在运行前台服务或者被系统强制保持活跃状态的进程，其进程本身可能会持续运行数小时之久。

唤醒锁的类型

PowerManager类定义了几种不同的唤醒锁级别。其中大多数已经被弃用，在实际开发中，对于应用程序开发者来说，只有其中一种类型是真正需要关注的。

第一列是您传递给`newWakeLock()`的参数，接下来的两列则说明了这种锁会保持哪些设备处于工作状态。与屏幕相关的设置已经被弃用，因为用户在离开设备后，这些设置仍会使屏幕保持开启状态，从而导致电池电量被浪费。

用来保持屏幕开启状态的替代方法是使用`FLAG_KEEP_SCREEN_ON`窗口标志（或者在布局文件中设置`android:keepScreenOn`），窗口管理器会将这个标志与窗口的可见性关联起来，这样就可以防止屏幕在用户离开后仍然处于开启状态从而继续消耗电池电量。而在接听电话时，接近传感器锁会自动发挥作用。对于其他情况来说，在现代Android系统中，“唤醒锁”实际上指的是`PARTIAL_WAKE_LOCK`，本文接下来的内容也将主要围绕这一类型锁定机制进行讲解。

如何获取和释放唤醒锁

要使用唤醒锁，您的应用在清单文件中必须声明拥有`WAKE_LOCK`权限。这是一种常见的权限，因此在安装应用时系统会自动授予这一权限，而不会向用户发出任何提示。

<uses-permission android:name="android.permission.WAKE_LOCK" />

这条声明表明该应用可以使用唤醒锁。如果没有这个权限，调用`acquire()`方法时会抛出`SecurityException`异常。由于这一权限是自动授予的，因此用户在查看电池使用情况之前，并不会知道自己的应用正在使用唤醒锁，这也进一步说明了谨慎使用这种功能的重要性。

以下是使用唤醒锁的最基本示例代码：

val powerManager = context.getSystemService(PowerManager::class.java)
val wakeLock = powerManager.newWakeLock(
    PowerManager.PARTIAL_WAKE_LOCK,
    "myapp:upload"
)

wakeLock.acquire(10 * 60 * 1000L) // 10分钟
uploadPendingFiles()
wakeLock.release()

这段代码首先获取了`PowerManager`系统服务，然后创建了一个`WakeLock`对象，指定了部分唤醒模式，并设置了一个标识标签。“myapp:upload”这个标签会在`dumpsys`工具、电池使用记录以及Play Console中显示出来，因此它能够准确识别出是您的应用以及具体正在执行的操作。

Google推荐使用“app:component”这种格式作为标签，因为在调试过程中使用这种格式可以更方便地获取实时信息。传递给`acquire()`方法的参数是一个以毫秒为单位的超时时间值。如果10分钟后锁仍然没有被释放，系统会自动将其解除。

虽然上面的代码看起来没有问题，但实际上存在一个漏洞：如果`uploadPendingFiles()`方法抛出异常，那么`release()`方法就永远不会被执行。尽管这个超时设置可以将造成的损害限制在10分钟内，但每次出现异常，仍然会有10分钟的电池电量被浪费掉。接下来的章节会解释如何解决这个问题，以及还有哪些其他需要注意的地方。

引用计数机制的工作原理

默认情况下，唤醒锁是使用引用计数机制来管理的。每次调用`acquire()`方法时，系统内部的计数器值会增加；而每次调用`release()`方法时，计数器值会减少。只有当计数器的值为0时，锁定状态才会被真正解除。

wakeLock.acquire(60_000L)  // 计数变为2，锁被持有
wakeLock.acquire(60_000L)  // 计数仍为2
wakeLock.release()         // 计数变为1，锁仍然被持有
wakeLock.release()         // 计数为0，锁被释放
wakeLock.release()         // 抛出RuntimeException：WakeLock未完全释放

前两次调用会使计数变为2。第一次释放后计数会变回1，因此即使代码执行了“释放”操作，锁仍然会被持有。

直到第二次释放时，锁才会真正被释放。如果第三次尝试释放时已经没有锁可释放了，就会抛出RuntimeException，错误信息为“WakeLock未完全释放”。在生产环境中，这种情况会导致程序崩溃，因此有些开发者会将release()方法放在try块中执行，或者先检查isHeld属性。

当多段独立的代码共享同一个WakeLock对象时，引用计数机制非常有用。然而，如果获取锁和释放锁的操作次数不一致，就会出现问题。例如，某个函数被调用了两次，但其完成回调只执行了一次，就会导致锁泄漏。

fun syncContacts() { wakeLock.acquire(5 * 60 * 1000L) val account = accountStore.current() ?: return api.pushContacts(account) wakeLock.release() }

当当前没有可使用的账户时，这个函数就会导致锁泄漏，因为return语句会直接跳过释放锁的操作。另外，如果pushContacts()方法抛出网络异常，也会导致锁泄漏。这两种情况单独来看似乎都不会造成严重问题，但每次同步操作失败都会浪费5分钟的时间。

fun startDownload(url: String) { wakeLock.acquire() downloader.enqueue(url, object : Callback { override fun onComplete() { wakeLock.release() } override fun onError(e: Throwable) { log("download failed", e) } }) }

这里存在两个错误。错误处理回调函数忘记了释放锁，因此每次下载失败都会导致锁被持续占用。而且，获取锁时根本没有设置超时时间，所以这种锁的占用状态会一直持续到进程终止为止。

还有第三个不太明显的风险：如果downloader被取消或者在没有调用任何回调函数的情况下就中断了请求，那么锁也会被遗留下来。任何那种需要依赖第三方来释放锁的设计，都应当设置超时机制作为安全保障。

引用计数不平衡

当一个共享的、基于引用计数的锁被获取的次数超过了被释放的次数时，即使所有代码路径看起来都在尝试释放这个锁，它仍然会保持被占用的状态。

class LocationTracker(private val wakeLock: PowerManager.WakeLock) {
    fun onStart() {
        wakeLock.acquire(30 * 60 * 1000L)
        startUpdates()
    }

    fun onStop() {
        stopUpdates()
        wakeLock.release()
    }
}

这个类看起来设计得很平衡。但问题会出现在onStart()被调用两次（例如在配置发生变化或者收到重复的意图信号时），而onStop()只被调用一次的情况下。此时引用计数会变为1，锁就会一直保持被占用的状态，直到超时时间结束。关闭引用计数机制，或者在获取锁之前添加if (!wakeLock.isHeld)这样的判断语句，就可以解决这个bug。

会启动后台任务的广播接收器

在onReceive()方法执行期间，系统会为你保持这个唤醒锁。一旦onReceive()方法执行完毕，这个锁就会被释放，进程也会被视为处于空闲状态。

inline fun  PowerManager.WakeLock.withLock(
    timeoutMs: Long,
    block: () -> T
): T {
    acquire(timeoutMs)
    try {
        return block()
    } finally {
        if (isHeld) release()
    }
}

fun syncContacts() = wakeLock.withLock(timeoutMs = 5 * 60 * 1000L) {
    val account = accountStore.current() ?: return
    api.pushContacts(account)
}

suspend fun uploadAll(files: List) {
    wakeLock.acquire(10 * 60 * 1000L)
    try {
        withTimeout(9 * 60 * 1000L) {
            files.forEach { api.upload(it) }
        }
    } finally {
        if (wakeLock.isHeld) wakeLock.release()
    }
}