跳到主要内容

目标应用变了，也让流程继续能用

建立在"屏幕长什么样"之上的自动化，就对"屏幕长什么样"有一份长期依赖。当你自动化的应用发布更新——或者你改了模拟器的分辨率——有些东西会坏，有些不会。分清哪些是哪些，能省下重建那些本来没坏的东西。

什么会坏，按可能性排序​

东西能扛过界面改动吗？为什么
图像模板不能——最先坏匹配基于像素。重新配色的按钮就是另一张图
手输坐标不能没有任何东西把它锚定到你真正想指的对象上
画出来的区域通常能按屏幕百分比存储，能扛过分辨率变化——但扛不过元素挪位置
OCR 内容类型通常能就算字体变了，Number 还是 Number
流程结构、变量、子流程调用能绑定的是 id 和名字，不是外观

现实推论：一次界面更新通常是模板问题，不是流程问题。 别去重建那张图。

按这个顺序修​

1. 先确认它是你想的那回事​

对失败的检测节点跑 Test Node，读真实置信度。这能区分两种感觉完全一样的情况：

  • 置信度远低于阈值 → 模板不再匹配了。重拍。
  • 置信度没问题，但点击点偏了 → 模板匹配得上，是位置挪了。检查搜索区域。

没有这个数字就去猜阈值，正是一个还好的模板被扔掉的原因。

2. 把模板重拍得更紧​

只裁有辨识度的那一小块——那个字形、那个图标、那个标签。围着它的背景恰恰是应用换皮时会变的东西，你多框进去的每一个背景像素，都是一个可能让你出问题的像素。

TEMPLATE_QUALITY_TOO_LOW 意思是这块裁剪太小或太平淡，匹配不可靠；那就稍微裁大一点，或者换一个更有辨识度的元素。

3. 复查搜索区域，而不只是模板​

如果是元素挪了位置，那模板没问题，错的是搜索区域。在 Live Preview 上画区域，不要手输坐标——而且区域还会让匹配更快，所以这是现有最便宜的运行时加速手段。

4. 最后才去动阈值​

为了让一个差模板通过而降阈值，是给以后买一个误报。先修模板；等 Test Node 显示一次真正良好的匹配只是刚好卡在线下时，再去调阈值。

分辨率变化是另一种坏法​

如果你改了模拟器的分辨率或缩放，模板会成批失效——匹配基于像素。两个选择：

  • 在新分辨率下重拍。 可靠，也是大多数人该做的。
  • 在流程的功能开关里启用多尺度检测。 每次匹配更贵；当一个流程必须服务不同尺寸的实例时有用。

也要看队列：一个队列项保存着你确认过的那对流程/实例分辨率。任一边变了，你旧的那次 "Add anyway" 就不再适用——那就是 QUEUE_RESOLUTION_MISMATCH，是系统拒绝替你假设"你还是那个意思"。

让每个实例都保持在文档给出的 1280×720 · DPI 240 · 30 FPS 基线上，才是让一套模板到处都能用的前提。见配置 MuMu。

把它建成下次改动更省事的样子​

下面这些是把"坏掉"变成"耸个肩"的设计选择。

把每个会复用的矩形放进 Region Library。 这样元素挪位置是改一处，不是改五处。五个各自重画同一个矩形的节点，就是五次独立的修补。

永远不要相信你没验证过的画面。 一个动完就往下走的流程没法告诉你应用变了；它只会安静地做错事。动作 → 沉降 → 验证。见第 02 课。

自己拥有一套"回到已知界面"的例程。 一个按几次 BACK 再确认已经回到主界面的 Sub Flow，能让其他每个流程都可以放心开跑。应用变了，你修那一套例程，而不是修每个流程的开场动作——见第 09 课。

优先用检测，而不是记住的位置。 把 Click 的坐标来源指向一个 Find Image 节点，而不是一个固定区域。这样元素挪了，点击也跟着挪，你什么都不用改。

给每条失败 route 一个诚实的去处。 "按钮不在那儿"应该走到一个带消息的 Stop，而不是从图的末端掉下去。

应用更新之后：一个 10 分钟的巡检​

  1. 在真实实例上用 Test Flow 把每个流程跑一遍。
  2. 对每个失败，在报出的节点上跑 Test Node，读置信度。
  3. 重拍那些掉下去的模板；没掉的就别动。
  4. 给挪了位置的东西复查搜索区域。
  5. 重跑。如果开场动作坏了，先修"回到已知界面"那套例程——下游的一切都依赖它。
  6. 只有到这一步才去看阈值。

要紧的是像素变没变，不是应用的版本号怎么说。

相关页面​