PostMessage()向HWND_BROADCAST发送消息的耗时及性能影响问询

核心结论 #

直接在低级键盘钩子回调中调用PostMessage(HWND_BROADCAST)确实存在超时风险，且耗时会随系统顶层窗口数量增加而上升，可能导致钩子被Windows静默卸载。以下是具体分析和解决方案：

1. PostMessage(HWND_BROADCAST)的耗时特性 #

• 该调用的耗时与系统中顶层窗口的数量线性正相关：系统运行的应用越多、顶层窗口（包括隐藏窗口）数量越多，遍历所有窗口并投递消息的时间就越长。
• 虽然PostMessage是异步API（仅将消息放入目标窗口的消息队列就返回），但遍历所有顶层窗口的过程是同步执行的，这部分时间会直接占用钩子回调的执行时长。
• 系统满载时，窗口管理子系统的响应速度下降，会进一步拉长这个调用的耗时。

2. 钩子被静默卸载的本质原因 #

Windows对全局钩子（包括低级键盘钩子）的回调执行时间有严格限制（通常为几百毫秒，具体取决于系统版本）。如果钩子回调在规定时间内未返回，系统会判定该钩子无响应，将其静默卸载。

• 你之前.NET应用的钩子被卸载，确实大概率是全量GC导致钩子回调线程被暂停，超过了系统的时限。
• 纯C程序避免了GC问题，但如果PostMessage(HWND_BROADCAST)的耗时超过时限，同样会触发卸载逻辑。

3. 避免钩子超时的可行方案 #

• 将广播逻辑移出钩子回调：
  钩子回调只做最轻量化的工作——比如记录触发的按键事件，然后通过事件通知、信号量等方式，让独立的工作线程去执行PostMessage广播操作。这样钩子回调能瞬间返回，完全规避超时风险。
• 替换HWND_BROADCAST为定向投递：
  不要盲目广播给所有顶层窗口，改为让客户端主动向钩子进程注册（比如通过命名管道、共享内存或者自定义注册消息），维护一个已注册客户端窗口句柄的列表，只向列表中的窗口投递消息，大幅减少需要处理的窗口数量。
• 使用唯一的自定义消息：
  调用RegisterWindowMessage获取全局唯一的消息ID，避免自定义消息与其他应用的消息冲突，防止不必要的消息处理开销。
• 实测耗时：
  开发阶段可以用QueryPerformanceCounter在钩子回调中统计PostMessage(HWND_BROADCAST)的实际耗时，确认是否在安全范围内。

内容的提问来源于stack exchange，提问作者PhilCoder