EasyClick OCR文字识别实战：截图、坐标换算与脚本集成

1. 屏幕文字识别这件事为什么值得单独拎出来讲做自动化脚本的朋友大概都有过这种体验界面上的按钮没有固定 ID控件树里翻半天找不到那个该死的文本节点或者干脆整个页面就是一张图渲染出来的。这时候你盯着屏幕想要是脚本能看懂屏幕上的字就好了。EasyClick 调用 OCR 文字识别 API 这个事本质上就是给自动化脚本装上一双能读字的眼睛——把屏幕截图喂给识别引擎拿回文字内容和坐标然后脚本就能根据这些信息做判断、做点击、做流程分支。这套东西解决的核心问题很明确当传统控件定位手段失效时用视觉识别作为兜底方案。它适合谁适合已经会用 EasyClick 写基础脚本、但被动态界面、游戏画面、图片化 UI 卡住的中级使用者也适合刚接触自动化、想搞明白截图→识别→定位→操作这条链路怎么跑通的新手。我见过太多人卡在知道有 OCR 这回事但不知道怎么把它接进自己的脚本里这个环节网上搜到的要么是纯 API 文档要么是零散的代码片段拼不起来。这篇就把整条链路拆开从选型到代码到踩坑一次讲透。需要先说明一点EasyClick 本身提供了多种 OCR 接入方式包括调用系统能力、对接第三方识别服务、以及使用内置的识别模块。不同版本、不同运行环境安卓真机、模拟器、云控支持程度不一样。下面讲的是基于常见实践的通用思路具体接口名和参数请以你手上那个版本的官方文档为准我会把逻辑和关键点讲清楚你对照着改就行。2. 整体方案设计与技术选型拆解2.1 为什么是截图 OCR 坐标回填这条链路自动化脚本识别屏幕文字绕不开三个环节拿到画面、识别文字、把文字位置映射回可操作的坐标。这三个环节的顺序不能乱因为 OCR 引擎返回的坐标是相对于你喂进去的那张图的如果截图时做了缩放坐标就得按比例换算回真实屏幕坐标否则点下去就是偏的。我选择先截图存本地或内存再调识别接口最后按缩放比例回填坐标这个流程而不是直接对实时画面做流式识别原因有三。第一可控性截图是一个确定的时间点识别结果和那一刻的画面严格对应不会出现识别的时候画面已经变了的错位。第二可调试图存下来识别错了可以回看原图判断是图糊了还是引擎认错了排查效率高一个量级。第三性能可预期截图和识别是两段独立的耗时可以分别做优化比如截图用最快的方式识别做区域裁剪只送关键区域。有人会问为什么不直接用控件文本读取因为控件读取依赖无障碍服务的节点树很多应用尤其是游戏、Flutter/RN 渲染的界面、Canvas 绘制的页面根本不暴露文本节点或者暴露的是混淆过的内容。OCR 是像素级的只要字画在屏幕上它就能读这是它不可替代的价值。2.2 识别引擎怎么选内置、第三方、还是本地模型这是整个方案里最影响成败的决策。我把常见选项列个表你对照自己的场景挑。方案类型典型特点适合场景主要代价平台内置识别模块接入简单无需额外配置通用界面文字、清晰印刷体复杂背景、小字、艺术字识别率一般第三方云识别服务识别率高支持多语言和版面分析复杂版面、票据、多语种需要网络、有调用配额和费用、有延迟本地离线识别模型不依赖网络隐私性好内网环境、对稳定性要求高包体大、首次加载慢、需要自行部署我的实际选择逻辑是这样的先用内置模块跑通链路识别率不够再换第三方网络环境受限才考虑本地模型。为什么因为链路本身截图、坐标换算、结果解析跟用哪个引擎无关先用最简单的引擎把链路验证通后面换引擎只是替换一个调用函数的事。上来就折腾本地模型部署很可能链路还没通人已经被环境配置劝退了。这里有个容易被忽略的点不同引擎返回的数据结构不一样。有的返回纯文本行有的返回带坐标的块有的返回逐字的框。你的解析代码要按引擎的实际返回来写别照抄别人的示例否则拿到的字段是 undefined排查半天以为是识别失败其实是字段名不对。2.3 区域裁剪性能优化的第一刀全屏识别是最省事但最费时的做法。一张 1080x2400 的截图全屏送识别耗时可能是只识别一个 400x200 区域的五六倍。所以我的习惯是能圈定区域就绝不送全屏。区域怎么定两种思路。一种是固定区域比如你知道目标文字永远出现在屏幕上方某个条带里直接写死坐标裁剪。另一种是相对区域按屏幕宽高的百分比来算适配不同分辨率。后者更稳因为换台设备分辨率一变写死的绝对坐标就废了。裁剪的时候有个细节留边距。你圈的区域如果刚好卡在文字边缘识别引擎可能把字切掉一半识别结果就成了乱码。我一般上下左右各留 10 到 20 像素的余量宁可多送一点背景也别把字切了。这个余量值不是拍脑袋是按你目标文字的字号来估的字号越大留得越多。3. 核心细节解析与实操要点3.1 截图环节速度与清晰度的平衡截图看着简单其实坑不少。第一个坑是截图方式的选择。EasyClick 里常见的截图手段有截全屏、截指定区域、以及从缓存取最近一帧。从缓存取最快但可能拿到的是旧画面实时截全屏最准但慢。我的做法是对时效性要求高的场景比如等一个弹窗出现用实时截图对静态页面做批量识别用缓存帧。第二个坑是图片格式和压缩。有些截图接口默认返回压缩过的图字边缘会有噪点OCR 识别率直接掉一截。如果接口支持指定格式优先选无损的比如 PNG。如果只能拿到压缩图识别前可以考虑做一次简单的锐化或二值化预处理但这个要看引擎吃不吃这套有的引擎自己会做预处理你再处理反而帮倒忙。第三个坑是截图权限和时机。部分环境下截图需要额外授权或者在某些界面比如带安全标记的页面截出来是黑屏。这个不是代码问题是环境限制遇到了别死磕换个思路——比如改用控件读取或者固定坐标点击来绕过。提示截图存本地调试时记得定期清理不然跑一晚上脚本存储里堆几千张图设备卡到怀疑人生。我一般只保留最近若干张或者调试阶段才存图正式跑的时候走内存。3.2 坐标换算最容易翻车的一环OCR 返回的坐标是相对于送入图片的而点击需要的是屏幕绝对坐标。这中间的换算是新手翻车率最高的地方。换算公式本身不复杂屏幕X 裁剪区域左上角X 识别结果X * 缩放比例X 屏幕Y 裁剪区域左上角Y 识别结果Y * 缩放比例Y关键在于缩放比例从哪来。如果你送识别的图就是原尺寸裁剪那比例是 1直接加偏移就行。但很多识别接口为了提速内部会把图缩放到某个固定宽度再识别返回的坐标是基于缩放后的图。这时候你得知道它缩了多少。有的接口会在返回结果里带上原图尺寸有的不带不带的话你就得自己控制——送进去之前先自己缩放到已知尺寸这样比例你自己算得出来。我踩过的一个真实坑某次识别结果坐标总是偏右下查了半天发现是裁剪时用了相对坐标计算但计算时把状态栏高度算进去了而截图本身不含状态栏导致偏移量多了几十像素。这种偏移不会报错就是点不准特别隐蔽。所以我的经验是换算完先打日志把识别坐标、偏移量、最终点击坐标都打出来肉眼核对一两个点确认对了再往下走。3.3 识别结果解析从一堆框里挑出你要的那一个OCR 返回的往往是一堆文字块每个块带文本和位置。你要做的是从里面精准捞出目标。常见匹配策略有三种精确匹配文本完全等于目标。适合固定文案比如确定取消。包含匹配文本包含目标子串。适合文案有前后缀的情况比如确定(3)。正则匹配按模式捞。适合数字、时间、带变量的文案比如剩余\d次。选哪种取决于你的目标文案稳不稳定。我的建议是能用精确就别用包含能用包含就别用正则因为匹配越宽松误匹配的概率越高。曾经有个脚本用包含匹配找确定结果页面上有个不确定的提示文字脚本直接点歪流程全乱。后来改成精确匹配加长度校验才稳。还有一个细节多个匹配结果怎么选。页面上可能同时出现两个确定比如弹窗和底层页面各一个你得定个规则比如取最上面的、取面积最大的、取离某个参照物最近的。这个规则要写进代码别指望引擎帮你选。3.4 识别前的图像预处理什么时候需要什么时候别碰预处理是把双刃剑。合适的预处理能显著提升识别率过度的预处理会把字搞没。我总结了几种常见情况和对应处理画面情况建议处理理由浅色字深色底反色或二值化多数引擎对深字浅底更友好背景有花纹干扰灰度化 适度二值化降低背景噪声字很小低于 20px 高放大 2 倍再识别引擎对小字敏感度低画面本身清晰、对比度高不处理直接送处理反而引入噪点判断要不要处理最土但最有效的办法是把图存下来人眼看一遍。人眼都费劲的字引擎大概率也费劲这时候才值得上预处理。人眼一眼就看清的别折腾直接送。4. 完整实操流程与核心代码实现4.1 环境准备与前置检查动手写代码前先把这几件事确认了能省掉后面一半的排查时间。第一确认你的 EasyClick 版本支持 OCR 相关接口。不同版本接口名可能有差异打开官方文档搜一下识别关键词看看有没有对应的方法。第二确认运行环境有截图能力跑个最简单的截图脚本把图存下来看看是不是正常画面。第三如果用的是需要联网的识别服务确认网络通、配额够、密钥配置对。我习惯写一个冒烟测试小脚本就干三件事截一张图、调一次识别、打印结果。这三步都通了再往正式脚本里集成。别小看这个习惯它能帮你把环境问题和逻辑问题隔离开不然脚本跑不通你都不知道该查哪。4.2 核心代码一条完整的识别链路下面这段是基于常见接口形态写的示例接口名和参数你需要按自己环境的文档调整但结构和逻辑是通用的。// 第一步定义识别区域相对屏幕比例适配不同分辨率 var screenW getScreenWidth(); var screenH getScreenHeight(); var roi { x: Math.floor(screenW * 0.1), y: Math.floor(screenH * 0.3), w: Math.floor(screenW * 0.8), h: Math.floor(screenH * 0.2) }; // 第二步截图并裁剪到目标区域 var fullShot captureScreen(); // 截全屏具体方法名按文档 var roiShot cropImage(fullShot, roi.x, roi.y, roi.w, roi.h); // 第三步调用识别接口 var ocrResult ocrRecognize(roiShot); // 返回结构按实际引擎调整 // 第四步解析结果并换算坐标 var targetText 确定; var hit null; for (var i 0; i ocrResult.length; i) { var item ocrResult[i]; if (item.text targetText) { // 精确匹配 hit item; break; } } if (hit) { // 假设识别结果坐标基于裁剪图原尺寸比例为 1 var clickX roi.x hit.x Math.floor(hit.w / 2); var clickY roi.y hit.y Math.floor(hit.h / 2); log(命中目标点击坐标 clickX , clickY); click(clickX, clickY); } else { log(未识别到目标文字); }这段代码里有几个我特意写出来的细节值得单独说。取文字框中心点点击而不是点左上角因为左上角可能落在字的边缘甚至框外中心点最稳。坐标计算用 Math.floor 取整避免浮点数传给点击接口出问题。日志打全命中没命中、坐标多少都打出来出问题一眼能看出来卡在哪一步。4.3 参数计算缩放比例到底怎么定前面提到缩放比例是换算的关键这里给个具体的计算过程。假设你的裁剪区域是 800x400但识别接口内部会把图缩放到宽度 400 再识别很多引擎有这个限制那么缩放比例 原图宽度 / 识别时宽度 800 / 400 2识别返回的坐标如果是 (100, 50)换算回裁剪图坐标就是 (200, 100)再加上裁剪区域偏移才是屏幕坐标。如果你不知道引擎内部缩了多少那就自己先缩放把裁剪图主动缩放到一个你确定的尺寸比如宽度固定 720送进去这样比例就是你缩放时用的那个值心里有数。还有一种情况是引擎返回的坐标本身就是归一化的0 到 1 之间的小数那换算就是坐标 * 图宽别当成像素值直接用否则点出来全在屏幕左上角一小块区域里。4.4 把识别封装成可复用的函数正式脚本里识别逻辑会被调用很多次别每次都复制一遍。我一般封装成两个函数一个负责找文字并返回坐标一个负责找文字并点击。function findText(text, roi) { var shot cropImage(captureScreen(), roi.x, roi.y, roi.w, roi.h); var result ocrRecognize(shot); for (var i 0; i result.length; i) { if (result[i].text text) { return { x: roi.x result[i].x Math.floor(result[i].w / 2), y: roi.y result[i].y Math.floor(result[i].h / 2) }; } } return null; } function clickText(text, roi, timeout) { var deadline Date.now() (timeout || 5000); while (Date.now() deadline) { var pos findText(text, roi); if (pos) { click(pos.x, pos.y); return true; } sleep(500); } return false; }clickText里加了超时重试因为界面渲染有延迟你截图的瞬间文字可能还没出来。重试间隔 500 毫秒是个经验值太短了空转浪费性能太长了反应迟钝。超时时间按场景定弹窗一般 3 到 5 秒够加载慢的页面给到 10 秒。5. 常见问题与排查技巧实录5.1 识别不到文字按这个顺序查识别失败是最常见的问题别一上来就怀疑引擎不行按链路从前往后查效率最高。排查顺序检查项判断方法常见原因1截图是否正常存图人眼看黑屏、权限不足、截错区域2区域是否圈对看裁剪后的图坐标算错、分辨率适配问题3文字是否清晰人眼能否看清字太小、压缩失真、背景干扰4匹配逻辑是否对打印全部识别结果字段名错、匹配条件太严5引擎能力是否够换清晰图测试艺术字、特殊字体不支持我遇到最多的是第 4 步——识别其实成功了但代码里字段名写错或者匹配时多了个空格。把引擎返回的原始结果整个打印出来是排查这类问题最快的手段没有之一。5.2 识别到了但点不准坐标换算专项排查点不准基本锁定在坐标换算环节。先打印三个值识别返回的原始坐标、你算出的偏移量、最终点击坐标。然后手动在屏幕上量一下目标文字的实际位置对比一下差多少。差一个固定值多半是偏移量算错比如漏加了裁剪区域起点差一个比例值多半是缩放比例没算对随机偏可能是识别框本身不准那就改点框中心或者做二次校准。还有一种隐蔽情况点击接口本身有偏移。某些环境下点击坐标和实际落点有系统性偏差比如状态栏高度没算这个跟 OCR 无关但你排查时会误以为是识别问题。验证方法很简单写死一个已知坐标点一下看落点对不对对不上就是点击环节的问题。5.3 速度太慢三个立竿见影的优化识别慢影响脚本节奏优化按性价比排序第一缩小识别区域。这是收益最大的区域减半耗时可能减半还多。第二降低截图分辨率。如果引擎对分辨率不敏感把图缩小再送速度快很多但要注意别缩到字看不清。第三减少识别频率。不是每一帧都要识别加个间隔或者用画面变化检测触发识别能省大量无效调用。注意优化速度时别把准确率优化没了。我见过为了提速把图缩到字都糊了识别率从九成掉到五成反而更慢因为要重试。速度和准确率要一起看找到平衡点。5.4 稳定性问题跑久了就失灵怎么办脚本跑一段时间后识别开始不稳定常见原因有两个。一是内存或资源泄漏截图对象没释放越积越多。检查代码里有没有及时释放图片对象尤其是循环里反复截图的场景。二是环境状态漂移比如屏幕亮度变了、弹了系统通知遮挡、应用界面自己更新了。这类问题靠代码防不住得加兜底逻辑识别失败几次就重启应用或者重置状态别死循环硬刚。我的习惯是在关键流程节点加健康检查比如连续三次识别失败就截图存证并走异常分支这样出问题时至少有现场可查而不是脚本默默卡死。6. 我在这套方案上的一些实战体会这套截图 OCR 坐标回填的链路我从最早的粗糙版本一路改到现在最大的感受是识别引擎的能力固然重要但决定脚本稳不稳的往往是链路里的工程细节。区域圈得准不准、坐标换算对不对、失败重试有没有、日志打得全不全这些看着不起眼的点才是区分能跑和跑得稳的关键。另外一个体会是别把 OCR 当成万能钥匙。它是控件定位失效时的兜底不是首选。能用控件 ID 定位的优先用控件又快又准OCR 留给那些实在没辙的界面。把 OCR 用在刀刃上脚本的整体性能和稳定性都会好很多。最后分享一个小技巧调试阶段把每次识别的原图、识别结果、最终点击坐标都存成一条记录跑一段时间后回看这些记录你能发现很多平时注意不到的规律——比如某个界面在特定时刻识别率特别低或者某类文字的坐标总是偏一点。这些规律攒下来就是你优化脚本的第一手依据比任何通用教程都值钱。