Tasker 屏幕关闭监控详解 让自动化在 Doze 期间继续正常触发
屏幕关闭后发生了什么
当你按下电源键让屏幕关闭后，Android 系统会逐步降低后台活跃度以省电：
即时：屏幕变灭、屏幕上的 App 进入后台状态1-2 分钟：系统评估"这个 App 近期是否被使用过" 30 分钟：进入深度 Doze——大幅限制后台唤醒、延迟闹钟、限制网络数小时后：进入 App Standby——如果 Tasker 不常被打开，可能被进一步限制
屏幕关闭监控（Display Off Monitoring）就是 Tasker 在这个系统级限制下的生存策略。
Tasker 的屏幕关闭监控设置
Tasker 菜单 → 首选项 → 监控（Monitor）在这里可以分别控制每种 Context 在屏幕关闭时的监控行为：
每种 Context 的监控策略
| Context 类型 | 屏幕关闭监控选项 | 说明 |
|---|---|---|
| 时间 / 日期 | 通常始终开启 | 底层用 AlarmManager，Doze 期间也能精准触发 |
| 状态（State） | 建议开启 | 系统广播方式，耗电很低 |
| 事件（Event） | 建议开启 | 系统广播 |
| 应用（App） | 可选 | 屏幕关闭时其实 App 不会切换，这个监控在屏幕关闭期间几乎不触发 |
| 位置（Location） | 建议关闭 | GPS 持续追踪在屏幕关闭时耗电非常高 |
| 手势 | 可选 | 屏幕关闭时也能检测（用加速度传感器），但耗电略高 |
推荐配置
屏幕关闭监控（推荐）：
时间 / 日期 → 开启
状态 → 开启
事件 → 开启
应用 → 关闭（屏幕关闭时 App 不变，这个监控没意义）
位置 → 关闭（太耗电，除非场景必须）
手势 → 按需求开为什么 Location 监控应该关
Location Context 最耗电的原因：
- Tasker 需要主动请求 GPS 或网络定位
- 屏幕关闭时这个请求可能被 Android Doze 拦截（结果更不准）
- 持续 GPS 追踪每小时消耗约 10-20% 电量
如果"屏幕关闭时的位置变化"是必须的（比如"手机离开家后自动启动车载模式"）：
- 用 AutoLocation 的被动监听模式（被动 GPS）
- 或只用 Wi-Fi SSID 变化检测（不精确但省电）
屏幕关闭期间的自动化设计
夜间模式（屏幕关闭时仍需精确）
夜间模式 Profile 用 Time Context（23:00-07:00），依赖 AlarmManager：
- Doze 期间可以精准触发（AlarmManager 不受深度 Doze 影响）
- 即使 Tasker 没被电池优化白名单，也能准时在 23:00 激活
事件驱动（屏幕关闭时触发）
Profile：充电时锁屏界面显示密码本
Event → Charging Connected
AND
State → Display Off
Enter Task：
Show Scene → 密码本（显示锁屏界面上的 Scene）这个场景屏幕必须是关的！Event Context 用系统广播，屏幕关闭监控开启后可以正常触发。
屏幕关闭时的定时心跳
Profile：屏幕关闭心跳
Time → 每 5 分钟（但只在屏幕关闭 + 深度 Doze 前有效）
AND
State → Display Off
Task：
1. 执行一个轻量级的状态检查（如 Wi-Fi 是否还连着）
2. 如有异常 → 执行修复动作注意：深度 Doze 期间这个 5 分钟定时可能被延迟到 15-30 分钟。如果心跳必须严格准时（比如安全场景），考虑用 AlarmManager 的 setAlarmClock 类型（可以穿透 Doze）。
屏幕关闭 + 深度 Doze 的测试方法
要验证你的 Profile 在 Doze 期间是否正常工作：
步骤一：设置测试 Profile
Profile：Doze 测试
Time → 每 5 分钟
Enter Task：
Write File → 追加 "时间 %TIME Tasker 还活着" 到日志步骤二：让手机进入 Doze
- 关掉所有后台 App
- 屏幕关闭
- 放着不动 30 分钟以上
- 期间不要碰手机（一碰就会退出 Doze）
步骤三：查看日志
adb shell cat /sdcard/tasker-test.log正常情况应该每 5 分钟一行：
时间 21:30 Tasker 还活着
时间 21:35 Tasker 还活着
时间 21:40 Tasker 还活着
...如果发现延迟（比如中间跳了 20 分钟），说明 Doze 在限制 AlarmManager。这时需要检查：
- Tasker 是否在电池优化白名单
- 是否开启了省电模式
- 是否有其他 App 在频繁唤醒设备
Tasker 的唤醒锁（Wake Lock）
Tasker 内部会在执行 Task 时请求 Partial Wake Lock——这会在执行期间保持 CPU 活跃（但屏幕仍然关闭），确保 Task 能完整执行完毕。
通常 Tasker 自己管理 Wake Lock，但你可以在首选项里调整：
- 首选项 → 监控 → 使用唤醒锁：默认开启，让 Task 完整执行
- 如果你觉得耗电太高，可以关掉，但风险是 Task 可能在执行中途被系统挂起
Wake Lock 的正确用法
Tasker 会在以下情况自动请求 Wake Lock：
- Profile 激活/退出时执行 Enter/Exit Task
- 手动执行 Task 时
- 定时检查 Context 时
Task 执行时间长（>10 秒）时：
- 默认 Wake Lock 会保持到 Task 结束
- 如果 Task 里有大量 Wait 动作，Wake Lock 会一直占着 CPU（耗电）
- 建议：Wait 超过 30 秒的 Task 尽量拆分成多个小 Task，中间让 Wake Lock 释放
屏幕关闭 + 多个 Profile 同时触发
在夜间或手机闲置时，可能有多个 Profile 在同一时间点触发：
- 23:00 → 夜间模式 Profile 激活
- 23:00 → 低电量检查 Profile 也可能同时激活
- 23:01 → 定时备份 Profile 触发
Tasker 的处理：
- Profile 级别的 Context 检测：在后台监听，系统广播到达时立即评估
- Task 执行是单线程的：多个 Profile 的 Enter Task 会串行执行，不会并行
- 如果某个 Task 执行时间太长（比如复杂的 HTTP Request），会阻塞后续 Profile 的 Task
建议：把执行长的 Task（如备份、下载）安排在不太可能有其他 Profile 触发的时段（凌晨 3-5 点）。