打开 A 应用 为什么 B 和 C 也被拉起来了 关联唤醒链拆解
关联唤醒是安卓后台混乱的核心原因之一
你打开了一个社交应用，过一会儿发现它拉起来了推送服务、输入法服务、支付 SDK……一长串后台进程。这就是关联唤醒链——应用之间通过系统 intent 和自定义 intent 互相"勾连"，形成一张庞大的唤醒网络。
唤醒链的典型模式
打开应用 A
→ 应用 A 发送/触发某个 intent（自定义 intent 或系统广播）
→ 应用 B 的 receiver 监听了这个 intent
→ B 的 receiver 被触发 → 启动 B 的 service
→ B 的 service 又发送了另一个 intent
→ 应用 C 的 receiver 监听了 → C 也被启动常见的唤醒触发场景
| 触发源 | 后续被唤醒的应用 |
|---|---|
| 登录某个社交 App | 输入法、支付 SDK、定位 SDK 等监听 PACKAGE_REPLACED 或 USER_PRESENT 的应用 |
| 安装/更新某个应用 | 监听 PACKAGE_ADDED 或 PACKAGE_REMOVED 的应用 |
| 连 Wi-Fi / 开关移动数据 | 监听 CONNECTIVITY_CHANGE 的应用（会自动跑数据同步） |
| 屏幕解锁 | 监听 USER_PRESENT 或 SCREEN_ON 的应用（广告 SDK 常用，解锁后推广告） |
| 开机 | 所有监听 BOOT_COMPLETED 的应用 |
怎么用 Bloker 断唤醒链
Bloker 断唤醒链的核心手段：关掉应用 B 和 C 的 receiver（那个监听 A 发出来的 intent 的 receiver）。
实操示例：某个应用"打开 A 就牵出 B"
- 先观察：打开应用 A → 立刻按最近任务 → 截图/记住被拉起的 B 和 C
- 回 Bloker → 进 B 的详情页 → receiver tab → 看 B 监听了哪些 intent
- 找监听"应用 A 相关事件"的 receiver（比如包名、action、自定义 intent 字符串里含 A 的名字）
- 关掉那个 receiver
- 同样处理 C
- 杀掉 B 和 C → 重新打开 A → 验证 B 和 C 还会不会被拉起
怎么判断哪个 receiver 在监听什么
Bloker 会根据 receiver 的 intent-filter 自动给 receiver 打标签（比如标上 BOOT_COMPLETED、SCREEN_ON）。如果没打标签，可以：
- 看 receiver 的短描述/注释（有些应用开发者写了有用的注释）
- 用 Bloker 的搜索页（底部右 tab）搜 receiver 的名字或 action 字符串
- 关掉一个 receiver → 杀掉所有相关应用 → 触发源事件 → 看 B/C 还会不会被唤醒（逐个排除法）
为什么 IFW 对断唤醒链更有效
关联唤醒里有些 receiver 用 PM 方式关掉后会被应用自动恢复——尤其是大厂应用的 SDK 内部有自恢复逻辑。用 IFW 方式关掉 receiver：
- 系统发 intent → IFW 拦截掉对这个 receiver 的转发
- receiver 根本收不到 intent → 不会被触发 → 后续 service 也不会启动
- 应用完全不知道 intent 被拦了 → 不会有任何恢复动作
断唤醒链推荐全程用 IFW 方式。