先初始化，再识别
鸿蒙自动化脚本里所有图像相关的识别能力都挂在 image 和 ocr 两个对象上，用之前有一个必须先做的动作：初始化 OpenCV。忘了这一步，现象是识别结果一直为空，而且不报错，很容易卡很久。
初始化之后建议顺手把图片存储切到 mat 格式。官方实测的收益很直接：内存减少一半到八成，CPU 减少两到三成，速度提升一到两倍。跑鸿蒙群控的批量任务时，这个差别会被设备数量放大。
// 先初始化 opencv，找图找色都依赖它
image.initOpenCV();
// 抓到图、读到图、找图找色都会切到 mat 格式，更快也更省内存
image.useOpencvMat(1);识别用的截图一般走全屏抓取。如果流程里要连续抓很多帧，可以用流式截图的方式，避免每帧都重新建连接。用完的图片对象记得回收，长时间跑脚本时，不回收会逐步吃掉内存。
找图实战：模板与阈值
找图的调用形态是给一张模板图，让它在当前截图里找位置。返回值里带着匹配到的坐标，拿坐标就能点。
let screen = image.captureFullScreen();
let tpl = image.readBitmap("/sdcard/ec/tpl_confirm_btn.png");
let pos = image.findImage(screen, tpl, { threshold: 0.9 });
if (pos) {
logd("找到确认按钮: " + JSON.stringify(pos));
} else {
logw("没找到确认按钮");
}
image.recycle(screen);三个实战经验：
模板在目标设备上截。拿 A 机型的截图去跑 B 机型，尺寸和渲染都可能不一样，识别率会掉。
模板别太小。太小的话画面里到处都像，阈值稍微松一点就误匹配。
模板里尽量别包含会变的文字。文字部分交给 OCR 更合适，模板只保留稳定的图形特征。
阈值怎么定？先按经验值跑，然后看日志里识别的实际相似度，再往上收到刚好不误报的位置。不同分辨率的设备，阈值可能需要分别调。
找色实战：单点比色与多点找色
找色比的是颜色值，比找图轻得多。
单点比色适合判断某个固定位置的状态。比如一个按钮，可点和不可点的时候颜色不同，直接比这个位置的颜色就够，比找图快很多。
// 单点比色：判断某个坐标的颜色是否落在允许范围内
let c = image.getPixelBitmap(screen, x, y);
let hit = image.cmpColor(screen, "#FF5252", 0.9, 0, x, y);多点找色解决的是唯一性问题。单个颜色在画面里可能有很多处，用相对偏移把几个点的颜色绑成一组，唯一性就上来了。
还有一种反向用法是按颜色找图：先用颜色圈出大致区域，再在这个区域里做图像匹配，比全屏匹配快得多、也准得多。
找色的软肋是抗变化能力弱。主题色改了、深色模式切了、背景换图了，都可能失效。所以它适合做快筛和兜底，不适合当唯一的判断依据。
OCR 实战：模型选择与调参
OCR 的选择比找图找色多一点，先挑模型类型。
内置的 PP-OCRv6_small 对应的是偏快的路线，日常正立界面够用。可选类型里还有 ocrLite、tesseract、以及 Onnx 系列的 V4 和 V5，不同模型在精度和速度上各有取舍。下面这段初始化用的是 PPOCR 的 V6 路线。
ocr.releaseAll();
let engine = ocr.newOcr();
let ok = engine.initOcr({
type: "paddleOcrOnnxV6",
numThread: 2,
matMode: 1,
maxSideLen: 640,
doAngleFlag: 0,
mostAngleFlag: 0
});
if (!ok) {
loge("OCR 初始化失败: " + engine.getErrorMsg());
return;
}调参按这个顺序试：
padding 最值得先动。它给文字框外扩一圈白边，文字没被框全的时候，调大立刻改善。
检测框的置信度阈值。调大召回率降但更准，调小更容易找到但可能误报。
maxSideLen。把图像最大边限制在 640，速度会明显快，代价是特别小的字可能识别不到。
文字方向检测和角度投票。只有图片倒置的场景才需要开，日常正立界面关掉更省时间。
识别返回的是一个数组，每项带文字内容、置信度和坐标范围，按坐标就能点。调试阶段建议把 label 和 confidence 都打到日志里，识别不准的时候能看出是没认出来还是认错了。
YOLO 什么时候值得上
YOLO 处理的是前面三条路都覆盖不了的场景：目标形态多变、位置不固定，但你知道它属于某个类别。
它多了一层模型文件，初始化和调参都比前面复杂，训练方式与安卓侧一致。除非确实遇到非它不可的识别任务，一般不必优先上。判断标准很简单：如果找图、找色、OCR 识别组合起来能把流程跑稳，就不需要引入模型。
识别失败时的排查顺序
按这个顺序走，基本能定位到问题：
先确认截图拿到了。截图返回空的时候，后面所有识别都必然失败，先看这一步。
再确认坐标系统一致。HarmonyOS Next 上的点击和识别都基于截图坐标，如果中途设过屏幕尺寸，要确认两边是同一套。
然后确认 OpenCV 已初始化、mat 模式切换成功。
最后把识别到的坐标和当次截图一起打到日志。很多「找不到元素」其实是找到了但坐标偏了，对着截图一看就清楚。
还有一个习惯值得养成：脚本跑崩的时候，先把当次截图存下来再退出。事后翻日志不如直接看现场。
关于 EasyClick：手机自动化 AI 智能体平台，覆盖安卓免 root、iOS 免越狱、鸿蒙 Next 三大生态，提供脚本开发、苹果群控、本地中控投屏与云控系统。→ 了解全部产品
想要真实跑起来？
本文介绍的方案均可基于 EasyClick 能力在 iEasyClick 落地。官网提供完整文档、开发工具与自动化产品，免费体验。