20.1 待机场景功耗优化待机场景，说白了就是手机“睡着了”的状态。但“睡着”不等于“死掉”，它还得能响应来电、消息、闹钟。所以优化的核心是：让系统尽可能深睡，同时精准控制唤醒源。20.1.1 待机功耗的三大杀手我总结了一下，待机功耗搞不定的原因，无非这三类：唤醒源过多：App 乱注册 Alarm、Sensor 不休眠、RTC 频繁中断。内核残留唤醒锁：某个驱动没释放 wakelock，系统无法进入深度睡眠。Modem 常驻连接：网络搜网、心跳包、VoLTE 注册等。怎么查？我习惯用这几招：抓取 /proc/wakelocks：看哪个进程占用了 wakelock 时间最长。查看 /sys/power/runtime_suspended_time：确认设备是否真的进入了 suspend。用 MTK 的 PowerMonitor 工具：直接看电流曲线，哪个时间段电流下不来，一目了然。核心原则：待机场景下，CPU 应该进入WFI（Wait For Interrupt）状态，DDR 进入自刷新，Modem 进入 DRX（不连续接收）模式。如果电流超过 5mA，基本就有问题。20.1.
20、MTK平台功耗：待机场景功耗优化、通话场景功耗优化、导航场景功耗优化
20.1 待机场景功耗优化待机场景，说白了就是手机“睡着了”的状态。但“睡着”不等于“死掉”，它还得能响应来电、消息、闹钟。所以优化的核心是：让系统尽可能深睡，同时精准控制唤醒源。20.1.1 待机功耗的三大杀手我总结了一下，待机功耗搞不定的原因，无非这三类：唤醒源过多：App 乱注册 Alarm、Sensor 不休眠、RTC 频繁中断。内核残留唤醒锁：某个驱动没释放 wakelock，系统无法进入深度睡眠。Modem 常驻连接：网络搜网、心跳包、VoLTE 注册等。怎么查？我习惯用这几招：抓取 /proc/wakelocks：看哪个进程占用了 wakelock 时间最长。查看 /sys/power/runtime_suspended_time：确认设备是否真的进入了 suspend。用 MTK 的 PowerMonitor 工具：直接看电流曲线，哪个时间段电流下不来，一目了然。核心原则：待机场景下，CPU 应该进入WFI（Wait For Interrupt）状态，DDR 进入自刷新，Modem 进入 DRX（不连续接收）模式。如果电流超过 5mA，基本就有问题。20.1.