当前位置：首页 > news >正文

通过解读 WPF 触摸源码，分析 WPF 插拔设备触摸失效的问题（问题篇）

news 来源：原创 2024/4/27 15:19:59

在 .NET Framework 4.7 以前，WPF 程序的触摸处理是基于操作系统组件但又自成一套的，这其实也为其各种各样的触摸失效问题埋下了伏笔。再加上它出现得比较早，触摸失效问题也变得更加难以解决。即便是 .NET Framework 4.7 以后也需要开发者手动开启 Pointer 消息，并且存在兼容性问题。

本文将通过解读 WPF 触摸部分的源码，分析 WPF 插拔设备触摸失效的问题。随后，会给微软报这个 Bug。

本文使用多种语言编写，请选择适合你阅读的语言：

通过解读 WPF 触摸源码，分析 WPF 插拔设备触摸失效的问题（问题篇）
WPF Applications Stop Responding to Touches after Adding or Removing Tablet Devices

所谓“触摸失效”，指的是无论你如何使用手指或触摸笔在触摸屏上书写、交互，程序都没有任何反应。而使用鼠标操作则能正常使用。

本文所述的“触摸失效问题”我在 WPF 程序无法触摸操作一文中有所提及，但本文偏向于分析其内部发生的原因。
本文与林德熙的 WPF 插拔触摸设备触摸失效所述的是同一个问题。那篇文章会更多的偏向于源码解读，而本文更多地偏向于分析触摸失效的过程。

WPF 程序插拔设备导致触摸失效问题

无论你写的 WPF 程序多么简单，哪怕只有一个最简单的窗口带着一个可以交互的按钮，本文所述的触摸失效问题你都可能遇到。

具体需要的条件为：

运行 任意的 WPF 程序
插拔带有触摸的 HID 设备（可以是物理插拔，也可以是驱动或软件层面的插拔）

以上虽说是必要条件，但如果要提高触摸失效的复现概率，需要制造一个较高的 CPU 占用：

当前系统中有 较高的 CPU 占用率

可能还有一些尚不确定的条件：

是否对 .NET Framework 的版本有要求？
是否对 Windows 操作系统的版本有要求？

将以上所有条件组合起来，对于触摸失效的问题描述为：

当运行任意的 WPF 程序时，如果此时操作系统有较高的 CPU 占用，并且此时存在带有触摸的 HID 设备插拔，那么此 WPF 程序可能出现“触摸失效”问题，即此后此程序再也无法触摸操作了。
如果此时系统中同时运行了多个 WPF 程序，多个 WPF 程序可能都会在此时出现触摸失效问题。

触摸失效原因初步分析

WPF 从收集设备触摸到大多数开发者所熟知的 Stylus 和 Mouse 事件需要两个不同的线程完成。

主线程，负责进行 Windows 消息循环
StylusInput 线程，负责从 WPF 非托管代码和 COM 组件中获得触摸信息

主线程中的 Windows 消息循环处理这些消息：

LBUTTONDOWN, LBUTTONUP
DEVICECHANGE, TABLETADDED, TABLETREMOVED

Stylus Input 线程主要由 PenThreadWorker 类创建，在线程循环中使用 GetPenEvent 和 GetPenEventMultiple 这两个函数来获取整个触摸设备中的触摸事件，并将触摸的原始信息向 WPF 的其他触摸处理模块传递。传递的其中一个模块是 WorkerOperationGetTabletsInfo 类，其的 OnDoWork 方法中会通过 COM 组件获取触摸设备个数。

而导致触摸失效的错误代码就发生在以上 Stylus Input 线程的处理中。

PenThreadWorker 的 GetPenEventMultiple 方法传入的 _handles 为空数组，这会导致进行无限的等待。
WorkerOperationGetTabletsInfo 的 OnDoWork 因为 COM 组件错误出现 COMException 或因为线程安全问题出现 ArgumentException；此时方法内部会 catch 然后返回空数组，这使得即时存在触摸设备也会因此而识别为不存在。

为了方便理解以上的两个 Bug，可以看看我简化后的 .NET Framework 源码：

// PenThreadWorker.ThreadProc
while(这里是两层循环，简化成一个以便理解)
{
    // 以下的 break 都只退出一层循环而已。
    if (this._handles.Length == 1)
    {
        if (!GetPenEvent(this._handles[0], 其他参数))
        {
            break;
        }
    }
    else if (!GetPenEventMultiple(this._handles, 其他参数))
    {
        break;
    }
    // 后续逻辑。
}

// WorkerOperationGetTabletsInfo.OnDoWork
try
{
    _tabletDeviceInfo = PenThreadWorker.GetTabletInfoHelper(pimcTablet);
}
catch(COMException)
{
    _tabletDevicesInfo = new TabletDeviceInfo[0];
}
catch(ArgumentException)
{
    _tabletDevicesInfo = new TabletDeviceInfo[0];
}
// 其他异常。

以上的问题分析中，ArgumentException 异常几乎可以肯定是线程安全问题所致；COMException 不能确定；而 GetPenEventMultiple 中的参数 handles 实际上是用来进行非托管和托管代码线程同步用的 ResetEvent 集合，所以实际上也是线程同步问题导致的死锁。

同时联系以上必要复现步骤中，如果当前存在高 CPU 占用则可以大大提高复现概率；我们几乎可以推断，此问题是 WPF 对触摸的处理存在线程安全的隐患所致。

此触摸失效问题的解决方法

在推断出初步原因后，根本的解决方法其实只剩下两个了：

修复 WPF 的 Bug
- 由于我们无法编译 .NET Framework 的源码，所以几乎只能由微软来修复这个 Bug，即需要新版本的 WPF 来解决这个线程安全隐患
- 当然，此问题的修复可以跟随 .NET Framework 更新，也可以跟随即将推出的 .NET Core 3 进行更新。
更新 Windows（传说中的补丁）
- 新的 Windows 提供给 WPF 的 COM 组件可能也需要修复线程安全或其他与触摸硬件相关的问题

比较彻底的方案是以上两者都需要修复，但都 只能由微软来完成。

那我们非微软开发者可以做些什么呢？