异步请求捕获：解决微信支付宝模块的唤醒问题

在 FPA 的功能亮点清单里，有一条非常具体的技术描述：「异步通信解决方案：通过 Hook 技术捕获系统通知，解决微信/支付宝等模块注入后的功能唤醒问题」。这条能力直接决定了聊天类、支付类应用上的模块体验。

问题是什么：模块「醒不来」

很多应用的的核心交互不是「打开就完成」的一次性动作，而是事件驱动的：来了一条消息、收到一个支付回调、弹出一条系统通知——应用由这些异步事件唤醒并处理。模块想增强这类功能（防撤回、消息提醒、自动回复……），就必须在事件发生的那一刻被触发。

传统注入方案在这里有个经典痛点：模块注入后，事件唤醒链路上的某些环节绕过了模块的钩子——事件来了，模块却没被叫醒，功能表现为时灵时不灵，或者彻底沉默。

FPA 的解法：Hook 住通知本身

FPA 用 Hook 技术在框架层捕获系统通知：事件到达时先经过框架的耳朵，再交由模块处理。相当于在异步事件的必经之路上加了一道转发哨——不管应用内部调用路径怎么绕，通知层面的事件都逃不过捕获。社区资料把这称为 FPA 的「独创异步请求捕获技术」。

对使用者的实际意义

• 聊天类应用（微信/QQ/TIM）：消息防撤回、消息增强类模块的可靠性明显提升——这类功能全靠消息事件驱动；
• 支付相关场景：模块注入后的支付回调唤醒不再是盲区（注意：这里是「模块能感知事件」，与「重签名后调起支付」是两回事，后者是功能失灵讲的固有代价）；
• 音乐、内容类应用：后台播放、通知栏控制这类依赖通知机制的功能同样受益。

一条能力，两个语境

异步唤醒处理解决的是「模块活不活」的问题；模块活了之后效果好不好，仍然取决于 API 实现面与模块本身的适配（哪些模块能挂）。能力锦上添花，不改变实测为准的总纪律。

到这里，原理篇的四块拼图就齐了：LSPlant、Pine、注入全流程、本篇。最后一块知识版图在版本与社区：FPA 版本历史。