Windows平台鼠标按下标题栏的阻塞问题研究（使用Qt框架）-Toy模板网

这篇具有很好参考价值的文章主要介绍了Windows平台鼠标按下标题栏的阻塞问题研究（使用Qt框架）。希望对大家有所帮助。如果存在错误或未考虑完全的地方，请大家不吝赐教，您也可以点击"举报违法"按钮提交疑问。

Windows平台鼠标按下标题栏的阻塞问题研究

以下内容是Windows平台特有问题，其他平台可以忽略。
一直以来使用Qt开发桌面程序，拖拽移动窗口时，偶尔会发现明显的“掉帧”，以为是机器性能或者Qt框架的机制引起的刷新异常便没有在意。最近在使用QTimer定时在QWidget上渲染视频时，才发现比想象的更严重。

经过测试当鼠标按住标题栏不动时，画面会卡500ms；当鼠标右键按住标题栏不抬起，整个画面卡住直到抬起才恢复。跟刘大师和群友沟通后，确认了这个问题确实存在。

Windows的坑

网络上几乎没有这个问题的讨论，可能是无边框设计盛行，用户也不会去按住标题栏不动，也就没有什么反馈。所以一开始考虑是Qt的问题，便从Qt源码入手，找出问题所在。

Qt源码也是使用Windows的消息处理过程来处理消息，当一个消息没有被处理时，会调用Win32的默认处理过程 DefWindowProc：

// qwindowscontext.cpp
extern "C" LRESULT QT_WIN_CALLBACK qWindowsWndProc(HWND hwnd, UINT message, WPARAM wParam, LPARAM lParam)
{
    ...
    const bool handled = QWindowsContext::instance()->windowsProc(hwnd, message, et, wParam, lParam, &result, &platformWindow);
	...
    if (!handled)
        result = DefWindowProc(hwnd, message, wParam, lParam);
    ...
}

因为调试断点命中时，鼠标状态会更改，一开始没发现这块的异常，就陷入了误区，精力全放在了找阻塞代码，无果。最后一点一点打印时间，发现 DefWindowProc 在处理 WM_NCLBUTTONDOWN 和 WM_NCRBUTTONDOWN 时，会阻塞在该函数内，左键会最多等待500ms返回，右键则一直阻塞。经过三天的调试，最终得出个惊人的结论：居然是Windows自己的问题。

如何解决

DefWindowProc 毕竟不开源，也只能尝试自己处理 WM_NCLBUTTONDOWN 、 WM_NCRBUTTONDOWN 和相关消息的逻辑，避开 DefWindowProc 的调用。

所以重写 QWidget::nativeEvent，或者使用 QAbstractNativeEventFilter 做全局的过滤，在消息的特定场景下，直接处理并返回true。

目前的解决方案完全基于推理，基于 Win10 19044 版本测试，不保证解决所有场景。同时，本文不提供完整源码，需要自行实现！

主要的消息参数

WM_NCRBUTTONDOWN 和 WM_NCRBUTTONUP

右键相对比较简单，这两个消息的 wParam 参数表示是在非客户区什么元素上触发的点击，来源于WM_NCHITTEST 的返回值，这是个更早一点的消息。

Windows标题栏的右键只有一个表现，是在鼠标抬起时弹出菜单。经过测试可以在WM_NCRBUTTONUP时发送 WM_CONTEXTMENU 消息解决：
```
PostMessage(msg->hwnd, WM_CONTEXTMENU, 0, msg->lParam);
```
这里 msg->lParam 是 WM_NCRBUTTONUP 消息的参数，表示坐标。最终表现跟默认会有些差异，不过可以接受。

（一开始是考虑是用 GetSystemMenu 获取系统菜单并触发显示，但不知道怎么初始化菜单状态）
WM_NCLBUTTONDOWN 和 WM_NCLBUTTONUP

左键会非常复杂，这里涉及到Windows鼠标移动窗口时到底做了什么（实际也只能猜测）。通常标题栏分为三大区域，即wParam参数代表的类型：
- 左侧程序图标位置
  
  wParam为HTSYSMENU，在此点击会触发菜单，跟右键菜单一样，但位置固定。
  
  该区域点击不会产生阻塞，不需要处理。
- 右侧按钮区域
  
  wParam有多个值，主要是HTMINBUTTON、 HTMAXBUTTON、HTCLOSE三个。HTHELP比较少，图标是问号。当按钮抬起时，触发对应的功能。
  
  这些按钮的点击，都有对应的命令。通过手动发送 WM_SYSCOMMAND 消息，附带对应按钮的命令参数即可，可以参考文档。如：
```
PostMessage(msg->hwnd, WM_SYSCOMMAND, SC_MAXIMIZE, 0);
```
  这部分的逻辑，需要判断按下、抬起的wParam是不是一致，按下时需要缓存数据。
- 中间拖拽区域
  
  wParam为HTCAPTION，主要实现移动窗口，拖拽到桌面边界会有最大化等布局效果。
  
  虽然有SC_MOVE实现移动逻辑，但该命令没有最大化等布局效果。所以只能走 DefWindowProc 的逻辑。这里做个猜测，当收到左键按下后，进入 DefWindowProc 阻塞，内部会拦截后续消息；当收到移动消息时，进入拖拽逻辑。此过程会延迟500ms，有可能是为了等待双击消息执行最大化（仅仅是猜测）。
  
  所以考虑了一种方案是，当鼠标在该区域按下，记录必要的状态，直接返回true；当之后收到 WM_NCMOUSEMOVE 的时候，向窗口发送上次收到的 WM_NCLBUTTONDOWN （按下）消息参数和此次的 WM_NCMOUSEMOVE（移动）参数，标记一下，只发送一次；窗口会再次收到对应按下和移动的消息，但不做任何处理。
  
  流程大体如下：
  
  发送的左键按下消息、移动消息会被窗口再次处理，这时候走默认逻辑，就能正确触发拖拽移动逻辑。
  
  需要注意的是，在该区域拦截 WM_NCLBUTTONDOWN ，窗口不会激活，需要调用激活窗口的接口。但是在按钮区域，却能自行激活（都是什么鬼设计）。
  
  这里面仍然有一些奇怪的问题，放到后面一并说明。

其他问题

上面的方案基本是解决了主要的交互，由于整个需要缓存一些状态和参数来模拟Windows本身的行为，所以必须要在合适的时机给清除掉。另外，用户也总是会有奇怪的操作。但最大的问题是，不要指望Windows会给你想要的消息！！

关于按键顺序
关于移动方案

移动方案有个细节问题，我假设在按下鼠标左键，默认行为会等待 WM_NCMOUSEMOVE消息然后触发移动，所以模拟发送消息。但表现是窗口没有立刻移动，等继续移动鼠标才会。而Windows默认行为能保证立刻移动。
关于鼠标抬起

当拦截按下消息后，鼠标抬起能收到相关UP消息。但实际的默认行为，应该是将UP消息吞掉了。对于左键，取而代之的是WM_EXITSIZEMOVE，即结束移动；右键因为触发了菜单，会出现 WM_INITMENUPOPUP、WM_ENTERMENULOOP 等消息。

当鼠标左键在右侧按钮区域按下，或者右键在任何区域按下，移动鼠标能移动到窗口之外，然后抬起，也没有相应的UP消息，只有 WM_NCMOUSELEAVE，即鼠标离开了非客户区。

所以一些清除状态的代码得在这些消息里处理。
关于右键菜单

通常右键弹出菜单后，如果点击菜单外区域，菜单会自动关闭。

但如果此时直接按住拖拽区域，执行移动窗口呢？实际按下鼠标左键的同时，会收到WM_NCMOUSEMOVE，此时必须需要忽略该消息，等下次收到时再进行模拟发送消息，否则应该是导致了 DefWindowProc 内部出现了异常，整个状态都乱了。

解决方案参考问题2。
关于多窗口

如果程序有多窗口A和B，A处于激活状态，B处于非激活状态，此时在B窗口标题栏拖拽区域按下，又是类似问题3，虽然也有些特性消息，但都不好代表这种操作。

我个人在 WM_WINDOWPOSCHANGING 时做个标记，忽略一次WM_NCMOUSEMOVE消息。理论上WM_ACTIVATE比较准确。
关于窗口退出激活状态

这个比较好理解，窗口处于非激活状态，那必然没有鼠标按下等，需要完全清理状态。