我有一些关于 WH_MOUSE 的问题。根据我的阅读，通过将钩子(Hook)放入 DLL 中，它会注入(inject)进程。这是否意味着捕获鼠标也适用于我的桌面、菜单启动等？那么应用程序的标题栏呢？我在 Internet 上看到过一些有此类问题的帖子，但不知道他们是否因某些原因失败或存在某种限制(或其他方法)。
我还有一个关于 WH_MOUSE 和 WH_MOUSE_LL 之间性能的问题。我在某处发现 WM_MOUSE 比 WH_MOUSE_LL 快，但它真的很明显吗？如果是这样，在什么情况下它会使系统减慢我们可以注意到的程度？如果我只想记录鼠标和键盘的点击，WH_MOUSE_LL 是否有效？
谢谢!
最佳答案
这两个 Hook 都可以让您在屏幕上的任何位置进行鼠标输入(下面列出的情况除外)，从这个高级功能的角度来看，它们本质上是相同的。
两者均受 UIPI 约束:当鼠标悬停在提升的进程上时，这两个钩子(Hook)都不会让您进行鼠标输入。
低级 Hook 不需要 DLL，因此可以由 C# 使用。另一种类型需要用非托管代码 (C/C++) 编写的单独 DLL。
如果在 64 位机器上运行，您可以混合运行 32 位和 64 位进程，低级 Hook 将接收来自两种类型进程的事件，但其他类型of hook 只会看到来自与其自身具有相同“位数”的进程的事件(此限制源于 hook DLL 的使用；32 位 hook DLL 只能挂接到 32 位进程，对于 64 位进程也是如此。 ) 因此，如果您关心这种情况，使用 LL Hook 您只需要一个进程，而使用其他类型的 Hook ，您需要两个协作进程，一个用于 32 位，一个用于 64 位。
LL hook 需要一个消息循环才能运行。
LL 钩子(Hook)写起来更简单，因为回调发生在你自己的进程中，所以你可以访问你自己的全局变量等等。对于其他类型的钩子(Hook)，回调发生在另一个进程中，因此您必须做额外的工作才能将信息传回主进程。 (在这两种情况下，您都应该将回调中的代码保持最少；只需进行基本的过滤和检查，从您的主线代码中执行任何重要的工作，而不是回调。)
LL Hook “较慢”，因为输入通知被编码到您的进程，在那里进行处理，然后上下文再次切换回原始进程。使用其他类型的 Hook ，没有上下文切换。然而，这可能会或可能不会被用户注意到，并且可能取决于您在回调中所做的事情、您处理信息的方式、 Hook 的安装时间以及其他因素。
标题栏的问题似乎已解决in this question ;总结是您在标题栏(和其他非客户区)上收到 WM_NCMOUSEMOVE 消息，在其他地方收到 WM_MOUSEMOVE 消息，因此您必须检查两者。
我的 2c:如果您正在编写一个简单的实用程序或为了好玩而编码，请选择 _LL；它要容易得多，并且可以为您处理大多数棘手的情况；您不必担心 64/32 位问题或进程之间的通信，因此您可以更快地启动和运行。当您的应用程序逻辑正常工作后，您可以稍后根据需要将代码转换为其他类型的 Hook 。另一方面，如果你想要一个更“专业”的应用程序，它是一个“好公民”，并将其对其他应用程序的影响降到最低，那么其他类型的 Hook 可能更合适；但与所有性能相关的东西一样，先测量，不要假设，所以即便如此，最好还是从 _LL 钩子(Hook)开始。
关于c++ - 鼠标 Hook - 限制和性能，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/11192713/