AppLock三大锁定后端对比：无障碍服务、Shizuku与用量统计，怎么选才能稳锁不闪退？

AppLock 是一款开源的 Android 应用锁工具，通过"无障碍服务、Shizuku、用量统计"三大锁定后端监测前台应用切换，在目标 App 被打开时弹出密码/手势锁屏。新手最常踩的坑就是选错后端——要么锁不住，要么被系统杀进程后频繁闪退失效。这篇文章带你用 5 分钟读懂三个后端的工作原理、权限门槛和兜底机制，给出明确的选型建议。

🧭 一分钟看懂：三套后端各是怎么"看住"前台应用的？

AppLock 在 SettingsScreen.kt 中提供三个后端选项，对应源码里的BackendImplementation枚举（定义于 AppLockRepository.kt）：

💡 无论选哪个后端，同一时间只会有一个锁定服务真正工作，由 BackendServiceManager.kt 统一管理启动与切换，避免多服务冲突。

🦺 后端一：无障碍服务（Accessibility Service）——默认推荐

实现文件：AppLockAccessibilityService.kt

这是 AppLock 的"主力"后端。它注册为系统无障碍服务，监听TYPE_WINDOW_STATE_CHANGED窗口切换事件，前台 App 一变化就能立刻判断是否需要弹锁，是三种方案中响应最快、触发最准的。

它的额外职责还有两件：

• 防卸载保护：开启该功能后，有人试图在系统设置里关闭 AppLock 的无障碍服务或取消设备管理器授权时，AppLock 会拦截操作并把手机直接锁屏，防止"先关锁再删 App"的套路。
• 兜底监听：即使你在设置里选了 Shizuku 或用量统计后端，只要 Shizuku/实验服务意外挂掉，无障碍服务会立刻接管锁屏（见下文shouldAccessibilityHandleLocking逻辑）。

注意：无障碍权限属于敏感权限，部分手机会提示"谨防诈骗"，属于正常现象；若系统把它静默杀掉，它不会自动降级到其他服务，需要系统重启或手动重新开启。

📊 后端二：用量统计（Usage Statistics）——实验性方案

实现文件：ExperimentalAppLockService.kt

这个后端不需要无障碍权限，只申请系统级的"使用情况访问"权限，适合不想开无障碍、又想要低打扰的用户。

它的工作方式是用UsageStatsManager每 250 毫秒查询最近约 100 秒内的事件流，从中找到最新的ACTIVITY_RESUMED（Activity 进入前台）记录，判断前台是否切到了被锁的 App。服务以通知栏常驻的前台服务形式运行，抗被杀能力较强。

权衡点：

• ✅ 权限敏感度低，不碰"无障碍"这个红线；
• ⚠️ 官方在设置页明确标注为"Experimental（实验性）"，且依赖用量统计数据的实时性，个别机型上数据更新会有延迟，锁定可能慢半拍。

🔮 后端三：Shizuku——进阶玩家的"隐藏 API"方案

实现文件：ShizukuAppLockService.kt、ShizukuActivityManager.kt

Shizuku 后端是设置页带Advanced（进阶）徽标的选项。它借助 Shizuku 框架获得的系统权限，直接调用IActivityTaskManager.getTasks()等隐藏 API（相关接口封装在项目 hidden-api 模块中），每 500ms 精确获取当前顶层 Activity，还能监听 Home 键、熄屏、解锁等设备事件，锁定行为更"聪明"。

选择它的前提：

• 手机上已安装 Shizuku 并保持运行（AppLock 启动前会先Shizuku.pingBinder()探活）；
• Shizuku 已授权给 AppLock（Android 11 以上通过弹窗直接授权，无需 USB 调试）。

如果 Shizuku 未运行或授权被收回，该服务会自动降级到用量统计后端继续工作，不会让 AppLock 处于"裸奔"状态。

🛟 稳锁不闪退的秘密：自动回退与重启限流

选错后端不可怕，AppLock 的核心稳定性来自 AppLockManager.kt 中的兜底设计：

1. 回退链路：Shizuku 失效 → 自动切换到用量统计；用量统计失效 → 提示切回无障碍服务接管；
2. 重启限流：服务重启最多连续尝试 3 次，间隔不低于 5 秒，30 秒冷却期内不再重试——避免"崩了→重启→再崩"的闪退死循环，这正是"不闪退"的关键；
3. 开机自启：BootReceiver.kt 在BOOT_COMPLETED后按你选定的后端拉起对应服务，重启手机后保护不中断；
4. 独占运行：切换后端时会先停掉其他锁定服务（stopAllOtherServices），保证任何时刻只有一个服务在监测，消除互相打架导致的闪退。

🎯 新手选型指南：三步选对后端

第一步：你愿意开无障碍权限吗？

• 愿意 → 直接选无障碍服务。零依赖、实时响应、还附带防卸载保护，官方描述就是"Standard method that works on most devices"，绝大多数用户的最终答案。

第二步：不想开无障碍、也不想装 Shizuku？

• 选用量统计。只需在系统设置中授予"使用情况访问"（AppLock 会直接跳转到对应设置页）。接受最多约 250ms 的锁定延迟即可。

第三步：追求极致精确、设备已折腾过 Shizuku？

• 选Shizuku 后端。即使 Shizuku 意外断开，它也会自动回退到用量统计，配合始终开启的无障碍兜底，形成"三重保险"。

📌 小贴士：三个后端随时可以在设置页的"Backend Implementation"卡片中切换，切换即时生效，无需重启手机；配合"触发排除（Trigger Exclusions）"功能还能避免误锁，详见 TriggerExclusionsScreen.kt。

常见问题（FAQ）

Q1：换了后端之后旧权限还要留着吗？建议保留无障碍服务开启。它是 AppLock 的"最后一道防线"，其他两个后端失效时由它接管。

Q2：为什么通知栏一直有一个 AppLock 图标？用量统计和 Shizuku 后端以前台服务方式运行，常驻通知是 Android 对前台服务的强制要求，保证锁机监测不被系统清理，不能也不需要关闭。

Q3：锁屏界面长什么样？检测到被锁 App 启动后，AppLock 会立即启动PasswordOverlayActivity覆盖层，支持密码、手势图案解锁及生物识别快捷通过，解锁界面样式可在设置中调整。

写在最后

一句话总结选型：求稳选无障碍，怕敏感权限选用量统计，追求精确选 Shizuku。理解了"事件驱动 vs 定时轮询"和"回退链路 + 重启限流"这两点，你就再也不会被 AppLock 的锁定后端难住了。

想深入阅读实现细节，可以从锁定服务的统一入口 AppLockManager.kt 入手，再顺藤摸瓜到三个后端服务的具体实现。