RPA破解duilib自绘UI：混合识别与坐标映射实战解析

做RPA最怕碰到的就是这种事：客户系统在本地跑得好好的，对方是一个老牌的C++桌面客户端，启动快、内存占用低、界面流畅，唯一的问题就是自动化脚本一进去，Inspect 一扫描，元素树里只有一个孤零零的窗口节点，里面什么都没有。按钮、输入框、列表、下拉框，全部隐身。这就是典型的 duilib 自绘UI给RPA出的难题。而曲辕RPA在处理这类“不支持无障碍接口的桌面元素”时，用的并不是魔法，而是一套完整的混合识别方案。这篇文章就把它的底层原理拆开讲清楚，包括 Windows 无障碍接口的工作机制、duilib 为什么天生不兼容、曲辕RPA 捕获桌面元素的四个核心环节，以及我在实际项目中踩过的各种坑。

这个内容适合两类人：一类是做RPA实施、需要面对各类国产或老旧客户端软件的工程师，另一类是桌面应用开发人员，想搞清楚自绘UI和系统无障碍适配之间到底隔着什么。

1. 先说清楚：RPA为什么拿duilib这类应用没辙

很多做RPA的同事第一次遇到duilib时，第一反应是“窗口是不是加载失败了”，然后去查句柄、查进程、反复刷新，最后才发现问题不是窗口挂了，而是RPA的可访问性模型在自绘UI面前根本“看”不到控件。

1.1 RPA识别桌面元素的常规路径

RPA工具识别桌面元素，通常有三条路：UI自动化接口、图像识别、坐标模拟。优先级排序也是这个顺序，能用UI自动化拿控件树，就绝不依赖图像和坐标，因为控件树最稳定、最准确，拿到属性的同时还能拿到控件状态和事件。

Windows上的UI自动化接口以两代为主：老一代的 MSAA（Microsoft Active Accessibility），通过 IAccessible 接口暴露控件信息，核心消息是 WM_GETOBJECT；新一代的 UI Automation（UIA），基于 IRawElementProvider 接口和 IUIAutomation 客户端API，能力更强、信息更丰富。Inspect 这类工具之所以能高亮出控件位置和属性，靠的就是这两套接口。RPA工具也一样，本质上就是向目标窗口发送查询请求，由应用自身来回答“我这里有哪些元素”。

这条路径能走通，前提是应用得“愿意配合”。无论控件是原生 Win32 的还是 WPF 的，框架底层都会把这些信息交给系统，RPA工具再通过系统拿过来。

1.2 duilib为什么“看不到”

duilib 是一个轻量级的 DirectUI 界面库，很多国内客户端软件都在用，包括一些装机量很大的软件。它的核心特点是：所有UI控件都不是独立的Windows窗口，而是在一个主窗口客户区内，用GDI/GDI+自绘出来的“画”。

Windows操作系统能够感知的最小界面单位是窗口句柄，也就是 HWND。系统管理和消息分发都以HWND为单元。原生应用中，每个按钮、编辑框都有自己独立的HWND，因此系统天然能枚举到它们，向它们发消息、获取它们的位置和名称都很容易。但duilib把所有控件画在同一个窗口的同一个HDC上，对Windows来说，整个界面就是一张白纸加一个顶层窗口。控件区域只是代码里维护的一个个 CRect 矩形，命中了就处理鼠标消息，没命中就不管。RPA工具用UIA扫描时，系统向这个窗口发 WM_GETOBJECT，duilib默认不处理这个消息，于是整个元素树就只能返回最顶层的窗口节点。

这就是核心矛盾所在：界面看起来有几百个可操作区域，但在系统的无障碍模型里，它们是“不存在”的。

1.3 曲辕RPA的总体思路

曲辕RPA应对这种问题，思路很直接：既然应用不主动暴露，那么RPA就在外部建立一套“感知层”，用多种手段组合出结构化的元素信息。整体可以分为四个环节：

• 窗口级定位：通过窗口句柄、进程模块信息确认目标窗口，并判断是否属于自绘UI。
• 图像语义识别：截取客户区图像，通过模板匹配和OCR引擎，找出按钮、文本框、图标的候选区域。
• 坐标映射与操作回放：把图像上的候选区域坐标换算为屏幕坐标，再以Windows消息或鼠标事件的方式执行点击、输入等操作。
• 不稳态校验：操作后再次截图，对比变化区域，确认操作生效。

这种方法不要求应用做任何改动，也不需要客户提供源码或SDK，属于“事后再建模”的做法，非常适合没法推动老系统改造的场景。

2. 无障碍适配的基础：Windows可访问性接口是怎么工作的

要理解曲辕RPA为什么选择外部感知这条路，得先把 Windows 无障碍接口的运作机制讲透。很多人听过MSAA和UIA，但不知道这两个接口在系统层面到底是怎么流转的。

2.1 从WM_GETOBJECT到IUIAutomation的完整链路

MSAA和UIA的核心，是Windows定义的一种契约：系统向窗口发送一个 WM_GETOBJECT 消息，应用的窗口过程如果实现了这套接口，就返回一个COM对象指针，系统通过这个指针查询控件的名称、角色、状态、位置，以及可执行的操作。

以UIA为例，系统客户端库（UIAutomationCore.dll）会向目标窗口发送 WM_GETOBJECT，lParam 参数表示请求的类型，比如 OBJID_CLIENT 表示请求客户端区域的顶级提供者。应用这边的 IRawElementProviderFragmentRoot 接口返回整个控件树的根节点，然后RPA工具再通过 Navigate、FindFirst、GetCurrentPropertyValue 这些方法遍历整棵树。

这套机制对原生Windows控件和WPF是自动的。User32 里的标准控件实现了MSAA，WPF和WinForms在框架层实现了UIA。所以RPA工具扫描这些应用时，根本不需要开发者额外做任何事。系统级无障碍适配早就是Windows平台的默认基础设施，只是很多自绘框架没有接入而已。

2.2 命中测试是什么样的机制

除了遍历元素树，无障碍接口还提供另一个重要能力：按坐标取元素。MSAA提供 AccessibleObjectFromPoint，UIA提供 ElementFromPoint。RPA工具内部常做的一件事就是：移动鼠标到某个位置，调用这个接口，拿到当前位置最顶层的可访问元素，再读取名称和属性。

但自绘UI的问题在于，ElementFromPoint 只会一路向下寻找子元素。当你传入窗口客户区内的某个坐标时，系统发现这个坐标对应的窗口是这个duilib主窗口，于是调用主窗口的提供者接口，此时如果duilib没有实现子节点，那么返回的还是顶层窗口节点本身。这导致即使你精确地知道“屏幕坐标(500, 300)处就是登录按钮”，也没法通过无障碍接口告诉RPA工具“这个坐标归属于一个名叫‘登录’的按钮”。

我用Inspect做过一次很直观的实验：把鼠标移到duilib窗口里的输入框上，Inspect显示的Element是窗口本身，Role是Pane，Name是窗口标题，没有任何子元素。这个结果基本宣告了纯无障碍路径不可行。

2.3 自绘应用做无障碍适配的两种做法

理论上，duilib应用是有办法让无障碍接口“看见”控件的。常见做法是自行实现 IRawElementProviderFragment，在 WM_GETOBJECT 响应里返回一个控件树的根节点，把每个 CLabelUI、CButtonUI 都映射成一个Fragment。这是最正统的方案，海外一些成熟DirectUI框架就是这么做的。但问题在于它需要应用开发方配合，而且对duilib这种高度自绘的框架来说，工作量相当大，很多控件坐标和状态的同步逻辑要写得很细。

另一种方式是做一个外挂式的“系统无障碍代理接口”，通过hook技术让RPA进程在系统查询时返回虚拟元素。但这个方案的脆弱性极高，一旦窗口结构、渲染方式或进程生命周期变化，代理就会失效，维护成本甚至比重写控件还高。曲辕RPA没有走这条路，而是在外部用视觉识别和坐标建模替代，背后考虑的是稳定性和实施成本之间的平衡。

3. 曲辕RPA破解duilib识别的核心环节

外部感知说到底是四件事：定位窗口、理解图像、映射坐标、操作回放。下面拆开讲，每一步都会附上实现细节和关键选择的原因。

3.1 第一阶段：窗口级定位与进程分析

曲辕RPA先做的不是截图，而是拿到目标窗口的句柄，并做一次进程模块分析。推荐用 EnumWindows 配合窗口标题和类名定位主窗口，找到句柄后再拿 GetWindowThreadProcessId 得到进程ID。拿到进程ID以后，遍历该进程的已加载模块，重点检查是否有duilib相关的DLL模块特征名。

csharp复制// 判断目标进程是否加载了duilib框架模块
Process process = Process.GetProcessById(processId);
bool isDuilib = process.Modules.Cast<ProcessModule>()
    .Any(m => m.ModuleName.ToLower().Contains("duilib"));

这一步为什么重要？因为不同框架对应的识别策略完全不同。如果是原生Win32应用，直接走UIA；如果是Qt，UIA有时也需要特殊配置；如果是duilib，就直接走视觉识别通道，省去一次无意义的UIA探测，提升效率。实测下来，一个加载完整duilib界面的应用，UIA探测通常要耗时几百毫秒到几秒不等，提前识别出来能显著减少自动化流程的空等。

窗口定位之后还要读取几个关键参数：窗口矩形、客户区矩形、DPI缩放比例、窗口是否最小化。这些参数后续全部参与坐标换算。另外需要注意，Windows 10及以上版本里，每个进程的DPI Awareness是独立的，RPA进程必须设置成Per-Monitor V2，否则在不同分辨率屏幕上算出来的坐标全都会偏。

3.2 第二阶段：图像切片、模板匹配与OCR的联动

拿到客户区图像后，曲辕RPA不会直接整张丢给OCR，而是先做图像切片和分层识别。这样做是为了准确性和性能的兼顾，整张大图跑OCR，小项目还能忍，大型客户端的完整界面一次OCR可能要三秒以上，自动化流程完全跑不动。

推荐的流程是：

1. 截取目标窗口客户区 PrintWindow 或 BitBlt，注意duilib窗口用 BitBlt 抓到的内容在某些系统上会缺失子窗口，建议优先试 PrintWindow。
2. 对截图做区域分割。常见分割维度是顶部导航区、左侧菜单区、中间内容区、底部状态栏。定义好区域后分别跑识别。
3. 图标类按钮走模板匹配。将预设的按钮图标模板在区域内做滑动窗口匹配，输出候选矩形和相似度分数，一般设置0.85相似度作为阈值。
4. 文字类元素走OCR。duilib里的文字都是直接绘制在画布上的，OCR引擎能直接识别，返回文字内容和文本框位置。
5. 把OCR得到的文本框位置、模板匹配得到的按钮位置合并到一个候选元素列表，剔除重叠过高的区域。

这一步的关键点在于：OCR和模板匹配都会产生误差，因此最后需要用业务规则去修正候选区域。举个例子，要找一个“登录”按钮，OCR可能同时识别出“登录”“退出登录”“登录历史”，这时候需要结合约束条件，比如只保留与输入框在垂直方向相近、高度在固定范围内的候选框。

3.3 第三阶段：坐标映射与操作回放

视觉识别得到的坐标是图像坐标，而RPA最终要执行的是屏幕坐标下的点击和输入。这里就涉及三层坐标系的换算：图像坐标、客户区坐标、屏幕坐标。

具体计算逻辑：假设截图的尺寸是 imageWidth * imageHeight，目标窗口客户区大小是 clientWidth * clientHeight，系统缩放比例是 scale = clientWidth / imageWidth。那么图像上的点 (px, py) 对应客户区坐标 (px * scale, py * scale)，再用 ClientToScreen 转成屏幕坐标。

cpp复制RECT clientRect;
GetClientRect(hwnd, &clientRect);
POINT screenPt;
screenPt.x = imagePointX * clientWidth / imageWidth;
screenPt.y = imagePointY * clientHeight / imageHeight;
ClientToScreen(hwnd, &screenPt);
// 此时的screenPt就是用于SendInput或鼠标事件的屏幕坐标

执行操作时，有两种选择：一是用 SendInput / mouse_event 在系统层面模拟真实鼠标事件，优点是对绝大多数应用有效，缺点是会抢占用户鼠标，而且窗口必须可见；二是向目标窗口发 WM_LBUTTONDOWN、WM_LBUTTONUP 消息，不需要前置置顶窗口，但duilib等自绘框架的命中测试依赖鼠标消息里的坐标，消息坐标必须准确换算进客户区坐标系。

我的实践经验是：能后台执行的流程尽量用 SendMessage 投递坐标消息，但当界面涉及拖拽、右键菜单这种复杂交互时，还是得切换到前台发硬件级鼠标事件，否则会被框架的鼠标捕获逻辑拦下来。

3.4 稳态校验与失败重试

视觉识别天然带有概率性，所以点击完之后绝对不能马上执行下一步，必须做一轮变化校验。最简单的做法是：操作前截一张图，操作后延迟300到500毫秒再截一张，计算两处指定区域的像素差异。

以登录流程为例，点击登录按钮后，通常会出现两种情况：要么登录成功的跳转，要么登录失败的提示。曲辕RPA会预先定义这些业务状态的截图模板。如果点击后500毫秒，页面没有任何变化，大概率是点击没生效或者命中了错误位置，这时候需要重试或者重新识别。

这里有一个我踩过很多次的坑：OCR识别出的“登录”候选框，在某些分辨率下会略微偏移几个像素，如果刚好按钮的响应区域比较小，点击就会落到按钮边缘，触发不了操作。解决方法是把最终执行坐标向按钮中心做一点收缩，或者对候选矩形做2到3像素的膨胀后再取中心点。

4. 实操记录：一次真实的duilib控件捕获流程

理论说完，拿一个实际案例走一遍流程。目标是一个基于duilib开发的客户端登录窗口，需要自动化完成“输入用户名、输入密码、点击登录”三个动作。环境是Windows 10 专业版，1920x1080分辨率，DPI缩放125%。

4.1 工具准备与初始分析

我习惯先把界面“摸”一遍再配置RPA流程，用到的工具包括官方Inspect、Spy++、以及曲辕RPA自带的元素探测窗口。第一步是用Spy++看整个窗口的句柄结构，确认是不是只有一个顶层窗口，子窗口列表为空。这个观察结果基本就能确认是duilib或同类DirectUI框架。

然后用曲辕RPA的“控件探测”功能框选用户名输入框区域。工具会自动把这块区域裁剪成图像模板，并提示命名。这一步实际上就是在定义这个输入框的视觉特征。我给三个控件分别命名为 login_user_edit、login_pwd_edit、login_btn_submit，并把对应截图存入工程资源目录。

4.2 配置候选区域和识别参数

曲辕RPA的元素配置里，每个控件有两层识别方式：第一层是基础识别，第二层是基准定位。基础识别是模板匹配和OCR关键词；基准定位是为了处理同一页面有多个相似元素的情况，例如多个相同图标的列表项。

我给“登录按钮”填的配置大概是这样的：

这种“相对基准”的配置在处理界面大小变化时很管用。即使整体尺寸缩放，上下元素之间的相对位置通常保持稳定，比绝对坐标可靠得多。

4.3 首次执行的失败与参数调优

第一次跑的时候，登录按钮匹配失败了。排查日志发现，OCR把按钮上的文字识别成了“登 录”，中间多了一个空格，关键词匹配被阻断。这是一个典型的OCR识别噪声问题，自绘字体渲染后的文字笔画断连，会导致识别偏差。

我把关键词从精确匹配改成了模糊匹配，并开启OCR“候选词多结果返回”模式，把相似度排名前3的结果都加入候选列表，同时要求候选词必须与“登录”的编辑距离≤1。调整之后识别成功率从72%升到接近100%。

同样是那次执行里，还出现了一个现象：模板匹配同时命中了三个相似度都超过0.9的区域——登录按钮、退出登录按钮、历史登录记录按钮。这属于模板相似度过高导致的多候选问题。解决的技巧是引入“就近排序+区域约束”：在配置里增加约束条件，只保留位于密码输入框下方、且距离不超过100像素的候选。这样多出来的两个干扰项直接被过滤掉。

4.4 隐藏坑位：DPI缩放、窗口阴影与最小化后台

这个案例里我专门复现了三个常见的异常场景，都是RPA落地的“隐形杀手”。

第一个是DPI缩放导致坐标偏移。系统缩放是125%，如果RPA进程没有正确声明DPI Awareness，GetSystemMetrics 拿到的分辨率就是虚拟化的，截图与真实渲染不一致，最终鼠标点击会整体偏移约20%的距离。解决办法是在程序入口调用 SetProcessDpiAwarenessContext(DPI_AWARENESS_CONTEXT_PER_MONITOR_AWARE_V2)，然后所有坐标计算都以物理像素为基准。

第二个是窗口阴影导致的截图污染。duilib窗口如果没有关闭装饰阴影，PrintWindow 抓到的图像在某些系统上会包含半透明的阴影边缘，导致模板匹配的参考点偏移。我处理的办法是把图像匹配的搜索范围向内收缩20像素，并统一以客户区左上角为原点计算，不去管窗口的扩展区域。

第三个是最小化后的后台识别。窗口最小化时，客户区内容是空的，OCR必然失败。曲辕RPA的处理是在任务序列里嵌入“窗口恢复”步骤：操作前先判断 IsIconic，如果是最小化状态就调用 ShowWindow 恢复，再等待200毫秒重绘完成后继续识别。此外，窗口被其他应用遮挡时虽然不一定影响截图，但会影响前台鼠标事件的执行，所以关键步骤建议统一在被遮挡窗口置顶后再操作。

5. 常见问题与排查技巧

曲辕RPA这套混合识别方案，遇到的最多问题其实不是算法本身，而是坐标系、截图方式、窗口状态这类基础设置。下面整理成一个速查表，基本都是我在交付项目时反复遇到的问题。

5.1 元素识别异常排查速查表

每次出现“上一台电脑跑得好好的，换一台就废了”的情况，我都会先做三查：查DPI、查窗口大小、查字体渲染。这三个因素会直接影响图像识别质量，是跨环境部署失败的最高频原因，这一点对任何使用图像识别的RPA工具都成立，不限于曲辕RPA。

5.2 这套方案的边界与适用条件

说点务实的话。图像识别加坐标映射这套方案，适合的是“界面结构稳定、控件不频繁变动”的客户端。duilib应用通常具备这个特点，版本升级周期长，按钮位置和图标基本固定，所以模板匹配能保持较长时间的稳定性。反过来，如果界面是高频变换的动态布局，或者窗口内容依赖GPU实时渲染，这套方案会非常吃力。

GPU渲染是图像识别方案的天敌。像部分游戏客户端、3D应用，窗口内容由GPU直接合成，PrintWindow 抓到的不一定是实际看到的画面，甚至可能是黑屏。遇到这种应用，还是得回归系统无障碍接口，或者要求应用方提供数据接口。

另外，需要明确一点：外部视觉识别方案最终只能做到“像正常人看屏幕操作”，它无法真正获得控件的能力边界。比如一个看起来像按钮的图形，实际可能是一张图片，底下并没有绑定任何可执行逻辑。所以在交付前，我会把自动化流程中的每个关键步骤都做两轮回归测试，确保识别和操作是稳定的，而不是“碰运气式的可运行”。

最后说点实际的

做这类自绘UI的RPA项目，我最大的体会是：动手写脚本之前，先花半天时间把目标应用的窗口结构、渲染方式、DPI体系摸清楚，能省下后面至少两天的返工时间。曲辕RPA选择用混合识别方式让duilib这类应用“可识别”，本质上不是让应用具备无障碍能力，而是让RPA在应用不存在无障碍接口时还能有一条稳定的自动化通道。

如果你手头要背锅的也是一个duilib老客户端，建议先跑通下面这四步：确认窗口句柄和模块特征，抓取客户区截图并确定OCR/模板匹配策略，写好坐标换算和DPI处理，最后加一轮点击后的页面变化校验。这一套下来，大部分自绘UI的自动化难题都能解决大半。

再分享一个小技巧：duilib里很多按钮虽然不暴露控件信息，但会响应键盘焦点和快捷键。如果某个按钮的图像识别一直不稳定，试试直接用键盘Tab加Enter操作，很多时候反而比视觉识别更稳妥。自动化不是一门非要跟技术较劲的学问，绕过去，才是最快到达终点的路径。