★ FEATURED ARTICLE 1. 为什么手机端 GUI Agent 需要“双通道感知”做过手机端 GUI Agent 的人都有一个共同体会单靠一种感知方式几乎不可能把自动化任务做稳。我最早做的一版只依赖无障碍树Accessibility Tree来定位控件跑通率在简单页面上能到九成以上但一遇到自绘控件、游戏界面、视频播放器、WebView 里的混合内容就立刻抓瞎——节点要么是空的要么只给一个笼统的容器连按钮和文字都分不出来。后来我又试过纯靠投屏像素做视觉识别结果在文字密集的列表页里OCR 一抖动点击坐标就偏出去几十像素任务直接失败。所以这套“双通道感知”的思路本质上是被现实逼出来的无障碍树为主投屏像素兜底。前者提供结构化的语义信息快、准、省算力后者提供视觉兜底覆盖那些无障碍信息缺失的场景。两者不是简单的二选一而是有主次、有优先级、有融合策略的协作关系。这篇文章我想把整套设计拆开讲清楚为什么这么分工、两条通道各自怎么落地、融合逻辑怎么写、踩过哪些坑。适合正在做移动端自动化、GUI Agent、RPA 或者无障碍辅助工具的同行参考也适合刚接触这块、想少走弯路的同学。全文基于我在几个模拟项目里的实际经验涉及具体平台的地方我会用通用说法不绑定任何真实产品。先说结论性的判断无障碍树负责“知道这是什么”像素通道负责“确认它长什么样、在哪里”。把这两件事分开整个系统的稳定性会有质的提升。2. 双通道感知的整体架构设计2.1 两条通道的职责边界怎么划很多人一上来就想做“融合”把无障碍信息和视觉信息揉成一个统一表示。我试过效果反而不好因为两者的数据特性和更新频率完全不同。无障碍树是事件驱动的页面一变就刷新节点带 id、类名、文本、可点击状态像素是帧驱动的投屏一帧一帧过来需要做图像处理才能提取信息。硬揉在一起反而互相拖累。我的做法是明确划边界无障碍通道负责节点发现、语义理解、可点击区域计算、文本提取。它是主通道能拿到信息时优先用它。像素通道负责兜底定位、视觉校验、无障碍缺失时的元素识别。它是辅通道只在主通道失效或存疑时介入。这样划分的好处是主通道在大多数标准页面上能独立完成任务像素通道的开销只在必要时才付出。实测下来标准 App 页面里大约八成以上的操作可以纯靠无障碍树完成剩下两成才是像素通道的战场。2.2 主辅通道的优先级判定逻辑优先级判定是整套系统的核心。我的判定顺序是这样的先尝试从无障碍树里找到目标节点。如果找到且属性完整有明确的可点击边界、文本或描述直接用。如果无障碍树里找不到或者找到的节点边界异常比如宽高为 0、覆盖全屏、明显是容器标记为“存疑”。存疑或缺失时触发像素通道对当前投屏帧做区域分析尝试定位目标。两条通道都给出结果时做一致性校验一致则采信冲突则按预设策略裁决。这个顺序的关键在于“存疑”这个中间态。很多实现只有“找到”和“没找到”两种状态结果把一堆无效节点当成了有效结果点击自然就偏了。引入存疑判定后误判率明显下降。2.3 数据流与刷新机制两条通道的数据流是异步的需要设计好同步点。我的做法是无障碍通道通过监听无障碍事件来更新节点缓存事件类型包括窗口变化、内容变化、滚动等。像素通道按需抓帧不常驻运行避免持续占用算力。每次执行动作前先确保无障碍缓存是最新的可以主动触发一次刷新再决定是否需要抓帧。这里有个细节投屏帧和当前界面状态之间可能有延迟尤其是网络投屏。所以抓帧后要做一个“新鲜度”判断如果帧的时间戳和当前操作时间差太大宁可重新抓一帧也不要用旧帧做定位。提示不要为了省事让像素通道常驻抓帧。持续抓帧不仅耗电耗算力还会因为帧率不稳定引入更多噪声。按需触发才是正解。3. 无障碍树通道的落地细节3.1 节点抓取与属性解析无障碍树的抓取核心是把平台提供的节点结构转成我们自己的统一表示。不同平台字段名不一样但语义大同小异。我一般会提取这些属性属性用途备注节点 id唯一标识部分平台不稳定慎用作唯一键类名判断控件类型如按钮、输入框、列表项文本内容语义匹配最常用的定位依据内容描述补充语义图标按钮常靠它可点击状态判断是否可操作决定是否作为候选边界矩形计算点击坐标左上右下四个值层级路径辅助定位处理重复文本时有用解析时有个坑边界矩形可能是相对坐标也可能是绝对坐标取决于平台和节点层级。我踩过一次父节点坐标没累加导致点击位置整体偏移。后来统一做了坐标归一化把所有节点的边界都换算成屏幕绝对坐标问题才解决。3.2 节点匹配与语义定位策略定位一个目标我一般按这个优先级匹配精确文本匹配文本完全相等包含匹配文本包含关键词内容描述匹配类名加层级组合匹配模糊匹配编辑距离或相似度阈值精确匹配最稳但实际页面里文本经常带空格、换行、动态数字所以包含匹配用得最多。模糊匹配是最后手段阈值我一般设在 0.8 左右太低会误匹配太高又匹配不上。还有一个经验同一个文本可能对应多个节点比如列表里多个“删除”按钮。这时候要结合层级路径和边界位置来消歧选最符合当前上下文的那一个。我通常会优先选可见区域内、层级最深的那个。3.3 无障碍失效的典型场景无障碍树不是万能的以下场景基本拿不到有效信息自绘控件整个界面是一个大画布无障碍只给一个根节点。游戏和视频播放器内容渲染在独立图层无障碍树里是空的。部分 WebView混合内容里原生节点和网页节点混在一起结构混乱。动态加载内容节点还没生成查询就返回空。这些场景就是像素通道存在的理由。识别出“当前处于无障碍失效场景”本身也是一种能力我一般通过节点数量、根节点覆盖率、可点击节点占比这几个指标来判断。4. 投屏像素通道的兜底实现4.1 投屏帧的获取与预处理像素通道的第一步是拿到清晰的帧。投屏方案有很多种我这里不展开具体工具只说通用处理流程抓帧后先做尺寸归一化统一到固定分辨率方便后续坐标换算。做灰度化和降噪减少颜色和噪声干扰。必要时做对比度增强让文字和控件边界更清晰。预处理的目标是让后续的检测和识别更稳定。我试过不做归一化直接处理结果不同设备分辨率下参数全要重调非常痛苦。统一分辨率后一套参数基本能覆盖大部分场景。4.2 目标检测与 OCR 的配合像素通道里我主要用两类能力目标检测找出可能的按钮、图标、输入框区域。可以用轻量检测模型也可以用传统的边缘加轮廓方法。OCR识别区域内的文字用于和预期目标做匹配。两者的配合逻辑是先检测出候选区域再对区域做 OCR最后用文字匹配确认目标。如果 OCR 结果和预期文本匹配度高就采信这个区域如果匹配不上就退回到纯视觉特征匹配比如图标模板匹配。这里有个实用技巧OCR 不要对整帧做只对候选区域做。整帧 OCR 又慢又容易出错候选区域 OCR 又快又准。候选区域怎么来可以先用无障碍树里已知的节点边界做参考也可以先用检测模型框出大致范围。4.3 坐标换算与点击落点计算像素通道给出的坐标是图像坐标要换算成屏幕坐标才能点击。换算公式取决于投屏帧和真实屏幕的比例关系屏幕坐标 图像坐标 × (屏幕尺寸 / 图像尺寸) 偏移量偏移量通常来自投屏窗口的位置。如果投屏是全屏的偏移量为 0如果是窗口化的就要加上窗口左上角坐标。点击落点我一般取区域中心但对于某些控件比如带图标的按钮中心可能落在图标上而不是可点击区域这时候要结合无障碍信息或视觉特征微调。实测下来取中心在九成场景下是没问题的剩下的一成需要特殊处理。注意坐标换算一定要做边界检查防止换算后的坐标超出屏幕范围。我遇到过因为帧尺寸异常导致坐标飞到屏幕外的情况加了边界钳制后就稳了。5. 双通道融合与冲突裁决5.1 一致性校验机制两条通道都给出结果时先做一致性校验。校验维度包括位置一致性两个结果的中心点距离是否在阈值内我一般设 50 像素。语义一致性无障碍节点的文本和 OCR 文本是否匹配。尺寸一致性两个结果的边界大小是否接近。三个维度都通过直接采信无障碍结果因为它是主通道。如果位置一致但语义不一致以无障碍为准因为 OCR 可能识别错。如果位置不一致进入冲突裁决。5.2 冲突场景的裁决策略冲突主要有两类第一类无障碍找到节点但像素通道在别处也找到疑似目标。这种情况我优先信无障碍因为它的语义信息更可靠。像素通道的结果作为备选如果无障碍点击失败再尝试像素结果。第二类无障碍没找到像素通道找到了。直接用像素结果但要做二次校验比如点击后再抓一帧确认界面变化。还有一种棘手情况两条通道都找到但都存疑。这时候我会选择“放弃自动操作上报人工”而不是硬点。硬点的代价往往比放弃更大可能触发误操作。5.3 失败重试与降级路径任何一次操作都要有重试和降级设计。我的策略是主通道操作失败重试一次可能是时序问题。再失败切换到像素通道操作。像素通道也失败做一次全量刷新重新抓无障碍树和帧再试一次。仍然失败标记任务失败记录现场信息截图、节点快照供排查。这个降级路径看起来啰嗦但实际跑起来能救回不少边缘情况。尤其是时序问题导致的首轮失败重试一次往往就好了。6. 实操中的常见问题与排查技巧6.1 典型问题速查表问题现象可能原因排查方向解决思路点击位置偏移坐标未归一化检查父子节点坐标累加统一换算绝对坐标找不到目标节点无障碍未刷新检查事件监听是否生效主动触发刷新OCR 识别错误帧模糊或分辨率低检查抓帧质量提高帧清晰度或区域 OCR重复文本误匹配未做消歧检查匹配策略结合层级和位置消歧点击无反应落点在不可点区域检查节点可点击状态调整落点或换节点帧与界面不同步投屏延迟检查帧时间戳重新抓帧6.2 独家避坑经验坑一无障碍节点的边界会“骗人”。有些节点报告的可点击边界比实际大很多点击中心可能落在空白处。我的做法是对边界特别大的节点做二次确认必要时用像素通道校验实际可点区域。坑二投屏帧的颜色空间可能不一致。不同投屏方案输出的帧颜色空间可能是 RGB 也可能是 BGR如果预处理时没注意灰度化后图像会异常。我一般先做一次颜色通道校验确保顺序正确。坑三动态内容导致节点 id 变化。列表滚动后节点 id 可能完全变掉如果缓存了旧 id就会定位失败。所以缓存要带失效策略滚动或页面变化后主动清理。坑四OCR 对特殊字体识别率低。艺术字、细体字、带背景的文字OCR 容易出错。这时候可以退回到模板匹配或者结合无障碍文本做交叉验证。6.3 性能与稳定性调优双通道感知的性能开销主要在两块无障碍树的解析和像素通道的图像处理。优化方向无障碍树只解析需要的子树不要全量遍历。像素通道按需触发且只处理感兴趣区域。缓存常用节点的解析结果减少重复计算。图像处理用轻量算法避免引入重型模型。稳定性方面最重要的是异常兜底。任何一步都可能抛异常比如抓帧失败、节点解析出错、坐标换算越界。我习惯在每个关键步骤加 try-catch出错时记录上下文并走降级路径而不是让整个任务崩掉。7. 一些延伸思考这套双通道设计跑下来我最大的感受是不要迷信单一信息源。无障碍树再全也有它覆盖不到的地方像素再直观也有它识别不准的时候。两者互补才能把稳定性做上去。后续如果要继续优化我会考虑几个方向一是引入时序信息利用前后帧的变化来判断操作是否生效二是做更细的置信度评分让融合裁决更智能三是把常见页面的感知结果做成模板加速重复场景的处理。另外这套思路不只适用于 GUI Agent做无障碍辅助工具、自动化测试、界面监控的同行其实都能借鉴。核心就一句话结构化信息优先视觉信息兜底两者交叉验证。把这个原则吃透很多稳定性问题都会迎刃而解。我在实际项目里反复调整过主辅通道的切换阈值最后发现没有一劳永逸的参数得根据目标 App 的特点去调。标准应用可以更信任无障碍自绘多的应用就得多给像素通道权重。这个平衡点只能靠实测去找。
阅读完成 · 觉得有帮助？
