WakeLock：是什么、类型及睡眠锁管理

什么是WakeLock

WakeLock是一种系统锁，禁止Android将设备切换到低功耗模式。通常Android在用户几秒无操作后会关闭屏幕并将处理器进入深度睡眠（deep sleep）状态，此时后台线程被暂停。WakeLock通过保持CPU在活动模式来阻止这种转换。

WakeLock机制通过系统服务PowerManager进行管理，可通过getSystemService(Context.POWER_SERVICE)方法访问。开发人员创建WakeLock对象并指定锁类型，必须在任务完成后确保释放它，否则设备电池会快速耗尽。系统不会自动释放WakeLock——这是应用程序的责任。

随着Android每个主要版本发布，Google对WakeLock的控制越来越严格。从Android 9（API 28）开始，后台应用程序不能在没有正当理由的情况下获取WakeLock，系统会跟踪滥用锁的应用程序并可以强制释放它们。在Android 12+中，对后台应用程序访问PowerManager引入了更多限制。

何时需要WakeLock

WakeLock在任务无法因设备进入睡眠而中断的场景下是必需的：通过不稳定连接下载大文件、录制视频、在无用户参与的情况下执行长时间计算。没有睡眠锁，处理器会进入深度睡眠，所有线程（threads）被冻结，任务将无法完成。

然而，Google强烈建议尽量减少WakeLock的使用。在大多数情况下，相同的任务可以通过Foreground Service（带通知）、WorkManager或JobScheduler来解决。这些机制会考虑电池和网络状态，从而延长设备的电池续航时间。

WakeLock的工作原理

WakeLock通过管理设备电源状态的系统服务PowerManager工作。当应用程序通过powerManager.newWakeLock()请求锁时，系统会提高CPU的活动级别，防止进入深度睡眠。调用wakeLock.release()后，系统返回正常的省电模式。

重要的是要理解WakeLock并不能阻止所有省电模式。 Doze模式（Android 6+的睡眠模式）在特定阶段可能会忽略WakeLock——持有WakeLock的应用程序在Doze维护窗口中将无法访问网络。这意味着即使WakeLock处于活动状态，也不能保证在Doze第二阶段执行网络操作。

每个WakeLock都与框架端的PowerManager.WakeLock相关联。系统维护进程级别的活动锁计数：如果一个进程持有多个WakeLock，它们会累加，只有为每个锁调用release()后才会释放。Android还支持唤醒锁超时（wake lock timeouts）——在指定间隔后自动释放。但是，不建议依赖超时：任务可能更早完成，额外的持有时间会缩短电池寿命。

WakeLock与系统事件

当设备进入睡眠模式（电源按钮）时，Android会强制释放所有SCREEN_DIM_WAKE_LOCK和SCREEN_BRIGHT_WAKE_LOCK，但保留PARTIAL_WAKE_LOCK。这意味着屏幕锁无法阻止设备关闭显示屏——只有PARTIAL_WAKE_LOCK能够在按下电源按钮后继续工作。

Android中的WakeLock类型

Android中有几种WakeLock类型，每种类型管理设备的特定组件。类型选择决定了锁定后哪些硬件组件保持活动状态。错误的类型选择会因启用不必要的模块而导致过度功耗。

PARTIAL_WAKE_LOCK —— 主要类型

PARTIAL_WAKE_LOCK是最常用且推荐的类型。它保持CPU处于活动模式，但允许屏幕和键盘背光关闭。这是后台任务的最佳选择：数据下载、图像处理、同步。屏幕会在系统超时后熄灭，这可以在执行用户不可见的工作时节省电池。

已弃用的类型（deprecated）

SCREEN_DIM_WAKE_LOCK、SCREEN_BRIGHT_WAKE_LOCK和FULL_WAKE_LOCK从Android 7（API 24）开始被标记为已弃用。它们保持屏幕开启，导致显著的电池消耗。Google建议改用FLAG_KEEP_SCREEN_ON（通过Activity.getWindow().addFlags()）——此标志仅在Activity活动时有效，不需要WAKE_LOCK权限，系统会自动管理屏幕持有时间。

WakeLock与功耗

WakeLock是Android上电池的主要消耗者之一。睡眠锁每持有一秒都会消耗额外能量，因为处理器无法进入能效更高的C-state状态。Google Power Dashboard研究表明，具有不正确释放WakeLock的应用程序在待机模式下可以将设备功耗提高30–50%。

系统通过Battery Historian组件跟踪滥用WakeLock的应用程序。开发人员可以分析功耗配置文件并检测锁泄漏——即WakeLock被创建但未释放的情况。Google Play Console会显示已发布应用程序的WakeLock统计信息，持有时间过长可能导致差评。

Doze模式和App Standby进一步限制了WakeLock的工作。在Doze的第一阶段（Light Doze），系统允许在短维护窗口中使用WakeLock。在第二阶段（Deep Doze），WakeLock与其他锁合并并在共同窗口中执行。如果应用程序在没有用户交互的情况下持有WakeLock超过10分钟，系统可以强制释放它并将应用程序列入电池优化的黑名单。

• Battery Historian —— 用于分析功耗和WakeLock泄漏的工具
• Doze模式 —— 在维护窗口中限制WakeLock，合并锁
• Google Play Console —— 显示已发布应用程序的WakeLock统计信息
• 黑名单 —— 应用程序可能被系统标记为高耗能

最佳使用实践

正确使用WakeLock是在执行任务的必要性和对设备电池的关心之间取得平衡。Google建议遵循几个原则：始终在finally中或通过acquire(timeout)释放WakeLock，使用最小必要的锁类型，避免在非必要情况下长时间持有。

释放规则

WakeLock应在创建它的同一代码块中释放。为了保证在异常情况下的释放，使用try-finally结构或Kotlin的use块。在Android 10+上，如果WakeLock被持有超过60秒，系统会在logcat中显示警告："WakeLock held for more than 60 seconds" —— 这是可能泄漏的信号。

获取时的超时

acquire(long timeout)方法会在指定的毫秒时间后自动释放WakeLock。这是在释放代码由于异常或错误而未能执行时的保障。建议始终设置超时时间，等于任务的最大预期执行时间加上10–20%的余量。

检查锁的存在

在调用release()之前，应检查WakeLock当前是否被持有。在没有先调用acquire()的情况下重复调用release()会导致RuntimeException: WakeLock under-locked。建议存储状态标志（isHeld），并在释放前检查wakeLock.isHeld()。

在Kotlin中使用WakeLock

让我们看看在Kotlin中正确创建和释放WakeLock的方法。示例演示了持有PARTIAL_WAKE_LOCK进行异步数据下载，在try-finally块中保证释放，并设置超时以防止泄漏。该服务使用带有IO调度器的CoroutineScope来执行后台任务。

class DownloadService : Service() {

    private lateinit var wakeLock: PowerManager.WakeLock
    private val scope = CoroutineScope(Dispatchers.IO + SupervisorJob())

    override fun onCreate() {
        super.onCreate()
        val powerManager = getSystemService(Context.POWER_SERVICE) as PowerManager
        wakeLock = powerManager.newWakeLock(
            PowerManager.PARTIAL_WAKE_LOCK,
            "download:wakelock"
        )
    }

    override fun onStartCommand(intent: Intent?, flags: Int, startId: Int): Int {
        wakeLock.acquire(60000)
        scope.launch {
            try {
                downloadFile()
            } finally {
                if (wakeLock.isHeld()) {
                    wakeLock.release()
                }
            }
        }
        return START_NOT_STICKY
    }

    private suspend fun downloadFile() {
        // 模拟文件下载
        delay(30000)
    }

    override fun onDestroy() {
        super.onDestroy()
        scope.cancel()
        if (wakeLock.isHeld()) {
            wakeLock.release()
        }
    }

    override fun onBind(intent: Intent): IBinder? = null
}

在清单中声明权限

要使用WakeLock，需要在AndroidManifest.xml中添加权限。WAKE_LOCK权限是普通权限（normal），不需要在运行时向用户请求，在安装应用程序时自动授予。但是，如果应用程序没有明确的WakeLock使用场景，Google Play可能会拒绝发布。

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

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

WakeLock的替代方案

WakeLock是一种低级别机制，Google建议尽可能用更现代的API替代它。主要的替代方案是带有通知的Foreground Service，它会在服务运行期间自动保持CPU锁定。系统本身管理Foreground Service的WakeLock，使开发人员无需显式获取和释放。

WorkManager是后台任务的第二重要工具。它保证即使在设备进入Doze模式或重启后也能执行工作。WorkManager内部支持持有锁（hold lock）——开发人员不需要显式使用PowerManager。任务在Doze维护窗口中执行，并自动管理睡眠锁。

对于需要精确时间的定期任务，使用带有setAndAllowWhileIdle()的AlarmManager，它可以将设备从Doze中唤醒。但AlarmManager仅适用于短操作——它不适用于长时间持有WakeLock。如果任务持续时间超过10秒，应将AlarmManager与启动Foreground Service的BroadcastReceiver结合使用。

• Foreground Service —— 带通知的自动WakeLock管理
• WorkManager —— 考虑Doze和重启的保证执行
• JobScheduler —— 考虑网络、充电和空闲状态的调度
• AlarmManager —— 按计划唤醒设备执行短任务