在 .NET Framework 4.7 以前,WPF 程序的触摸处理是基于操作系统组件但又自成一套的,这其实也为其各种各样的触摸失效问题埋下了伏笔。再加上它出现得比较早,触摸失效问题也变得更加难以解决。即便是 .NET Framework 4.7 以后也需要开发者手动开启 Pointer
消息,并且存在兼容性问题。
本文将通过解读 WPF 触摸部分的源码,分析 WPF 插拔设备触摸失效的问题。随后,会给微软报这个 Bug。
This post is written in multiple languages. Please select yours:
所谓“触摸失效”,指的是无论你如何使用手指或触摸笔在触摸屏上书写、交互,程序都没有任何反应。而使用鼠标操作则能正常使用。
本文所述的“触摸失效问题”我在 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 源码:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
// PenThreadWorker.ThreadProc
while(这里是两层循环,简化成一个以便理解)
{
// 以下的 break 都只退出一层循环而已。
if (this._handles.Length == 1)
{
if (!GetPenEvent(this._handles[0], 其他参数))
{
break;
}
}
else if (!GetPenEventMultiple(this._handles, 其他参数))
{
break;
}
// 后续逻辑。
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
// 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 组件可能也需要修复线程安全或其他与触摸硬件相关的问题
比较彻底的方案是以上两者都需要修复,但都 只能由微软来完成。
那我们非微软开发者可以做些什么呢?
- 降低 CPU 占用率
- 虽然这不由我们控制,不过我们如果能降低一些意料之外的高 CPU 占用,则可以大幅降低 WPF 触摸失效问题出现的概率。
然而作为用户又可以做些什么呢?
- 重新插拔触摸设备(如果你的触摸框是通过 USB 连接可以手工插拔的话)
触摸失效问题的分析过程
以上结论的得出,离不开对 .NET Framework 源码的解读和调试。
由于 WPF 的触摸原理涉及到较多类型和源码,需要大量篇幅描述,所以不在本文中说明。阅读以下文章可以更加深入地了解这个触摸失效的问题:
本文所有的 .NET Framework 源码均由 dnSpy 反编译得出,分析过程也基本是借助 dnSpy 的无 pdb 调试特性进行。关于 dnSpy 的更多使用,可以阅读:
本文会经常更新,请阅读原文: https://blog.walterlv.com/post/wpf-touch-fails-when-tablet-device-changed.html ,以避免陈旧错误知识的误导,同时有更好的阅读体验。
本作品采用 知识共享署名-非商业性使用-相同方式共享 4.0 国际许可协议 进行许可。欢迎转载、使用、重新发布,但务必保留文章署名 吕毅 (包含链接: https://blog.walterlv.com ),不得用于商业目的,基于本文修改后的作品务必以相同的许可发布。如有任何疑问,请 与我联系 ([email protected]) 。