很多玩安卓自动化的朋友应该都有过这种体验辛辛苦苦用控件工具抓了一大堆 ID结果 App 一改版脚本一夜回到解放前。坐标写死的方案更难受手机分辨率一换整个脚本直接报废。最近我在用 Yyds.Auto 做纯 AI 图像识别的自动点击脚本算是把这条老路彻底走通了——不依赖控件、不依赖坐标只需要给一张目标图片剩下交给模型去匹配识别。这篇就记录一下我从原理到落地跑通的全过程包括踩过的坑和实测数据给想入坑安卓 AI 自动化脚本的朋友一份能直接上手的参考。1. 为什么放弃控件抓取和固定坐标传统自动化脚本的三个硬伤先说结论不是控件和坐标方案不能用而是维护成本高到让人怀疑人生。Yyds.Auto 这类工具之所以把图像识别作为核心卖点本质上是想解决三个我在实际项目里反复踩的痛点。第一个硬伤是控件树的失效频率远比想象中高。现在主流 App 基本都是混合开发Flutter、React Native、小程序容器嵌套比比皆是。早期我用控件方案抓 RecyclerView 里的子项经常遇到整个列表只有一个大大的控件节点、子项全部原生绘制的情况——不是我没配置好是厂商压根没往控件树里吐信息。更别说游戏类应用、直播类应用整个屏幕压根就是一个自定义 SurfaceView无障碍服务能拿到的控件信息几乎是零。这时候如果不走图像识别就只有一条路逆向源码那成本完全不是写自动化脚本该承受的。第二个硬伤是坐标的脆弱性。固定坐标方案看起来最简单粗暴截个图、量个坐标、写进去但它在真机环境里就是个定时炸弹。不同手机的密度、状态栏高度、全面屏手势区、系统字体缩放任何一项变了坐标就整体偏移。我手里一台红米 K70 和一台 Pixel 5同一张截图量的坐标在两个屏幕上实际点击位置能差出几十像素。屏幕适配这件事坐标方案除非做分辨率映射表否则很难真正解决。第三个硬伤是验证逻辑的天花板。点击之后到底有没有成功——控件方案可以用属性断言坐标方案几乎只能靠 sleep 硬等或者触发下一个动作之后再判断。但图像识别方案直接就把验证闭环补齐了点击之后再识别一次页面元素是否出现就能判断操作是否真正落地。这相当于给脚本装了一双眼睛而不仅仅是给了一只手。所以我的结论很明确如果你的目标是做长稳运行的自动化任务或者要兼容多台不同型号的手机AI 图像识别这条路值得尽早切换。2. 核心链路拆解图像识别自动点击脚本是怎么看见屏幕的既然标题是纯 AI 图像识别自动点击那得把这条链路的每一环讲透。Yyds.Auto 在我实际使用中整个识别点击的过程大致分为四步。第一步屏幕截图与图像输入。这一步没什么黑魔法就是通过系统无障碍服务或者 MediaProjection 拿当前屏幕的 Bitmap。但这里有个容易被忽略的细节截图的色彩格式。Yyds.Auto 默认会做一次图像预处理把截图压缩成脚本指定的尺寸再送入识别引擎。压缩在这里不是坏事识别引擎对 1080P 的原图做全局扫描的开销远远大于缩小后的图但压缩比如果超过 0.5小目标元素的识别精度又会大幅下跌。我实测下来长边控制在 1280 像素左右信息量保留得最均衡。第二步目标特征匹配。Yyds.Auto 的识别原理和传统模板匹配不太一样。传统模板匹配是拿一张小图去原图上滑窗算相似度慢且怕缩放。而它内部走的是深度特征提取的路线——把截图和目标模板图都转成特征向量/特征图在特征空间里找哪块区域跟目标图最像。形象点说传统模板匹配是拿照片找人特征匹配是拿通缉画像找人能容忍光照变化和一定程度的透视变形但要先理解目标是什么。这一步直接决定了识别的上限。我试过把目标图设计得过大比如截了整个卡片区域结果 App 字体微调后匹配置信度从 0.91 掉到 0.74直接识别失败。后来把目标图聚焦到卡片上的核心图标和按钮置信度才稳定到 0.88 以上。目标图越聚焦、内容越单一识别效果越稳。第三步最佳坐标计算与点击注入。识别引擎会返回目标在截图中的矩形区域通常是(x, y, width, height)或者中心点坐标。脚本拿到区域后以中心点作为点击坐标再通过auto.click()注入点击事件。这里面有个手指逻辑识别出来的往往是按钮区域但真正要点的位置有时需要微调。比如关闭广告按钮识别区域是整个弹窗的右上角卡片而实际可点击的像素点是卡片里的 X这时候就要在返回坐标基础上做人工偏移。第四步结果校验与状态循环。纯识别脚本的价值就在这一步。点击动作注入之后脚本不会盲目 sleep 两秒而是再次截图识别目标页面的新元素用页面是否出现特定图像来判断动作是否生效。举个例子我点击签到随后识别页面上是否出现签到成功四个字的区域——识别到了就继续下一步没识别到就重试或者上报失败。有这层校验脚本才敢说自己是自动化而不是盲自动。3. 从零写一个识别-点击-校验的最小可用脚本环境准备这部分我不想堆步骤只说两个容易卡住的点。一个是 Yyds.Auto 安装后必须到 App 内的无障碍服务入口开启权限另一个是截屏权限需要在系统的悬浮窗权限页面里打开。这两个权限缺失的表现完全不同无障碍缺失会导致点击事件注入时报ACCESSIBILITY_PERMISSION_DENIED截屏权限缺失会直接让截图返回 null。我建议把这两个权限的检测写在脚本启动阶段避免线上跑到一半才暴露。下面这个脚本是我自己一直在用的最小模板跑通之后再往里面加业务逻辑不迟const auto require(yyds.auto); // 启动前先确认权限 auto.requestScreenCapture(); if (!auto.accessibilityServiceEnabled()) { toast(请先开启无障碍权限); exit(); } // 读取目标模板图片 const templates { signButton: /sdcard/templates/sign_btn.png, // 签到按钮 signSuccess: /sdcard/templates/sign_success.png // 签到成功提示 }; function findAndClick(imgPath, threshold) { const res auto.findImage({ template: imgPath, threshold: threshold || 0.82, region: null }); if (res res.confidence threshold) { // 计算按钮中心点 const clickX Math.round(res.x res.width / 2); const clickY Math.round(res.y res.height / 2); auto.click(clickX, clickY); return { success: true, confidence: res.confidence }; } return { success: false, confidence: 0 }; } function waitForImage(imgPath, timeout) { const start Date.now(); while (Date.now() - start timeout) { const res auto.findImage({ template: imgPath, threshold: 0.80 }); if (res) return true; sleep(500); } return false; } function main() { // 1. 识别并点击签到按钮 const clickRes findAndClick(templates.signButton, 0.82); if (!clickRes.success) { log(签到按钮未找到当前置信度为 clickRes.confidence); return; } // 2. 等待签到成功提示出现最多等 5 秒 const verify waitForImage(templates.signSuccess, 5000); if (verify) { log(签到成功校验通过); } else { log(未检测到签到成功提示可能出现异常); } } main();几个值得细说的设计threshold 的取值不是越高越好。0.82 是我在多个 App 之间实测后觉得比较舒服的值。取太高0.95 以上只要 App 换了一层皮肤或者按钮颜色稍有变化识别就挂了取太低0.7 以下又会频繁把相似图案误判成目标产生乱点。如果你发现同一个模板在不同页面都能匹配上那就是 threshold 太低需要调高。调试阶段可以先打印 confidence 值看正常页面是多少、干扰页面是多少取两者的中间值作为阈值。waitForImage 里的 sleep(500) 和 timeout 参数是一个缓冲逻辑。点击之后页面加载需要时间如果立即截图识别大概率拿到的是旧页面校验会误报失败。半秒一次的轮询频率既不会响应太慢也不会给 CPU 造成过大压力。这里的时间参数需要根据目标 App 的实际加载速度调整慢的页面可以放宽到 8 秒。region 参数是性能救星。我的示例代码里写死了region: null也就是全屏搜索。但很多场景下目标按钮只会出现在某个固定区域比如底部导航栏的我的按钮永远在屏幕下方。这时把 region 限定为{x: 0, y: 1000, width: 1080, height: 300}搜索面积减小 70%识别速度能快三倍以上。开销能省则省这也是把脚本往大批量任务上推之前必须要做的优化。4. 实测中的三个意外情况识别偏移、分辨率适配和性能损耗跑通最小脚本只算入门真正让人头大的是真实环境里的那些意外。我整理了自己在实际项目中遇到最多的三类问题以及对应的处理思路。意外一返回坐标与实际可点击位置存在系统性偏移。这个问题最早出现在一艘全面屏手机上。Yyds.Auto 拿到的截图坐标系和实际触摸坐标坐标系并不是天然对齐的状态栏高度、导航栏高度、屏幕圆角切割区域都会造成偏移集中在屏幕边缘区域的元素尤其明显。解决方式是在脚本初始化阶段做一次像素校准先准备一张已知精确坐标的参考图点击后用 toast 打印识别结果和实际点击位置计算出 X/Y 方向的常量偏差在最终点击前统一加上这个偏移量。我自己的项目里这个偏移量通常是 0 到 20 像素左右但不同手机品牌差异明显不做校准很容易出现识别到了但点歪了的现象。意外二相同脚本在不同分辨率手机上表现差异大。这个问题的根源不在于 Yyds.Auto而在于截图像素密度变化后目标模板图并不能自动跟着缩放。我的实测案例同一张 208 像素高的按钮模板在 1080P 屏幕上识别正常放到 2K 屏幕上识别率直接降到 0.59。解决办法是准备多套同源的模板图每个分辨率级别一套或者在脚本启动时先读取屏幕分辨率再按比例加载对应目录下的模板。后者代码上更优雅本质是以存储换稳定性。不要妄想让一个模板通吃所有机型至少在商业 App 上这是行不通的。意外三识别引擎的 CPU/内存占用比预期高。纯 AI 图像识别不是免费的识别一帧 1080P 截图大概要占用 200MB 左右内存CPU 峰值能跑到单核 80%。如果在低端机上跑脚本会明显拖慢手机本身的操作。我的优化策略有三条一是尽量用 region 缩小搜索范围二是把连续识别的间隔拉长到秒级三是把模板图尺寸控制到 100 到 200 像素范围不要天真地用大尺寸模板提高精度识别精度主要靠特征质量而非像素量堆砌。做完这三条之后CPU 占用从峰值 80% 降到了 30% 左右续航影响也能接受。5. 与主流替代方案的横向对比Yyds.Auto 到底值不值得选评测一个自动化工具好不好用不能脱离场景。我拿 Yyds.Auto 和同一赛道的另外两类方案做了个横向对比。方案识别原理适用场景优势劣势控件节点方案如 uiautomator、Appium读取无障碍控件树标准原生控件 App速度极快、定位准确对 Flutter/游戏/自绘 UI 失效坐标脚本方案如传统按键精灵固定坐标点击分辨率固定的设备简单直接、兼容所有 UI换设备就废毫无自适应能力图像识别方案Yyds.Auto 为代表视觉特征匹配游戏、自绘 UI、跨设备不依赖控件、不依赖坐标消耗性能、需要模板和维护阈值从我个人的项目经验看它和另外两类方案并不是纯粹的替代关系更像是互补。处理标准列表页我会沿用控件节点方案读取节点信息来快速遍历一旦进入自定义控件区域或者游戏界面立刻切换到图像识别模块。Yyds.Auto 提供了在同一脚本里混用这两类 API 的能力这也是我选中它的一个重要原因。另外有个点必须提Yyds.Auto 是一个可以离线的本地识别引擎脚本跑的每一帧截图都只在本机处理不涉及任何云端回传。这一点对我这种对数据出镜比较敏感的场景至关重要。有些同类产品宣传的云识别虽然准确率更高但需要把屏幕截图上传到服务器对我来说一票否决。6. 进阶把单次点击脚本进化成可复用的小型自动化框架脚本写得多了我开始厌倦每次都要处理权限检测、模板加载、日志输出这些重复代码。所以我把上面这些逻辑抽成了一个基础模块现在新的任务脚本只需要写业务步骤本身。这个思路分享给大家代码不复杂但能极大提高后续脚本的开发效率。// yydsHelper.js —— 公共模块 const auto require(yyds.auto); class YydsHelper { constructor() { this.resolution ; this.offset { x: 0, y: 0 }; } init() { auto.requestScreenCapture(); if (!auto.accessibilityServiceEnabled()) { throw new Error(无障碍服务未开启); } this.calibrateOffset(); } calibrateOffset() { // 加载已知基准点模板计算坐标偏移量 const anchor auto.findImage({ template: /sdcard/templates/anchor.png, threshold: 0.9 }); if (anchor) { // 假设 anchor 的实际中心点在截图中的理论位置已知 this.offset { x: anchor.x anchor.width / 2 - EXPECTED_ANCHOR_X, y: anchor.y anchor.height / 2 - EXPECTED_ANCHOR_Y }; } } findAndClick(imgPath, threshold, region) { const res auto.findImage({ template: imgPath, threshold, region }); if (!res) return false; const x res.x res.width / 2 this.offset.x; const y res.y res.height / 2 this.offset.y; auto.click(Math.round(x), Math.round(y)); return true; } waitFor(imgPath, timeout, threshold) { const start Date.now(); while (Date.now() - start timeout) { if (auto.findImage({ template: imgPath, threshold: threshold || 0.8 })) { return true; } sleep(400); } return false; } log(msg) { console.log([${new Date().toLocaleTimeString()}] ${msg}); } } module.exports YydsHelper;个人强烈建议所有模板图命名遵循功能_描述_尺寸的规则。比如sign_btn_1080.png、close_ad_1440.png这样在脚本里出现问题排查的时候一眼就能看出是哪台设备、哪个目标图出了问题。文件命名这个习惯虽然不起眼但在脚本量超过十个之后真的能救命。还有一个很容易被忽略的细节截图目录和模板目录要定期清理。Yyds.Auto 默认会把运行日志和调试截图存到/sdcard/脚本目录/下跑久了会积累几百 MB 的垃圾文件。我专门写了一个清理函数每周自动删除三天前的调试截图避免存储占满导致截图接口报错。把 Yyds.Auto 的实际能力跑明白之后我的核心感受是纯 AI 图像识别自动点击这条路的门槛不高但天花板很高。门槛不高是因为 Yyds.Auto 已经把特征提取、匹配、坐标计算这些复杂流程封装成了几个简单 API写个能跑的脚本半个晚上就够了。天花板高是因为识别阈值怎么调、模板怎么裁、区域怎么限定、多分辨率怎么适配处处都是可以深挖的细节每一项都直接影响脚本在真实设备上的存活率。我目前这套基于模板匹配加轮询校验的方案已经稳定跑了两周日常签到、任务领取这类重复操作基本不再需要手动干预。如果你也在用 Yyds.Auto 或其他图像识别方案做自动化建议优先把校验闭环和坐标校准这两件事补齐脚本的稳定性会有一个质的提升。 
长河君 · 2026/9/16 22:32:18 · 阅读 1.2k 安卓AI图像识别自动点击脚本实战：告别控件与坐标依赖
很多玩安卓自动化的朋友应该都有过这种体验辛辛苦苦用控件工具抓了一大堆 ID结果 App 一改版脚本一夜回到解放前。坐标写死的方案更难受手机分辨率一换整个脚本直接报废。最近我在用 Yyds.Auto 做纯 AI 图像识别的自动点击脚本算是把这条老路彻底走通了——不依赖控件、不依赖坐标只需要给一张目标图片剩下交给模型去匹配识别。这篇就记录一下我从原理到落地跑通的全过程包括踩过的坑和实测数据给想入坑安卓 AI 自动化脚本的朋友一份能直接上手的参考。1. 为什么放弃控件抓取和固定坐标传统自动化脚本的三个硬伤先说结论不是控件和坐标方案不能用而是维护成本高到让人怀疑人生。Yyds.Auto 这类工具之所以把图像识别作为核心卖点本质上是想解决三个我在实际项目里反复踩的痛点。第一个硬伤是控件树的失效频率远比想象中高。现在主流 App 基本都是混合开发Flutter、React Native、小程序容器嵌套比比皆是。早期我用控件方案抓 RecyclerView 里的子项经常遇到整个列表只有一个大大的控件节点、子项全部原生绘制的情况——不是我没配置好是厂商压根没往控件树里吐信息。更别说游戏类应用、直播类应用整个屏幕压根就是一个自定义 SurfaceView无障碍服务能拿到的控件信息几乎是零。这时候如果不走图像识别就只有一条路逆向源码那成本完全不是写自动化脚本该承受的。第二个硬伤是坐标的脆弱性。固定坐标方案看起来最简单粗暴截个图、量个坐标、写进去但它在真机环境里就是个定时炸弹。不同手机的密度、状态栏高度、全面屏手势区、系统字体缩放任何一项变了坐标就整体偏移。我手里一台红米 K70 和一台 Pixel 5同一张截图量的坐标在两个屏幕上实际点击位置能差出几十像素。屏幕适配这件事坐标方案除非做分辨率映射表否则很难真正解决。第三个硬伤是验证逻辑的天花板。点击之后到底有没有成功——控件方案可以用属性断言坐标方案几乎只能靠 sleep 硬等或者触发下一个动作之后再判断。但图像识别方案直接就把验证闭环补齐了点击之后再识别一次页面元素是否出现就能判断操作是否真正落地。这相当于给脚本装了一双眼睛而不仅仅是给了一只手。所以我的结论很明确如果你的目标是做长稳运行的自动化任务或者要兼容多台不同型号的手机AI 图像识别这条路值得尽早切换。2. 核心链路拆解图像识别自动点击脚本是怎么看见屏幕的既然标题是纯 AI 图像识别自动点击那得把这条链路的每一环讲透。Yyds.Auto 在我实际使用中整个识别点击的过程大致分为四步。第一步屏幕截图与图像输入。这一步没什么黑魔法就是通过系统无障碍服务或者 MediaProjection 拿当前屏幕的 Bitmap。但这里有个容易被忽略的细节截图的色彩格式。Yyds.Auto 默认会做一次图像预处理把截图压缩成脚本指定的尺寸再送入识别引擎。压缩在这里不是坏事识别引擎对 1080P 的原图做全局扫描的开销远远大于缩小后的图但压缩比如果超过 0.5小目标元素的识别精度又会大幅下跌。我实测下来长边控制在 1280 像素左右信息量保留得最均衡。第二步目标特征匹配。Yyds.Auto 的识别原理和传统模板匹配不太一样。传统模板匹配是拿一张小图去原图上滑窗算相似度慢且怕缩放。而它内部走的是深度特征提取的路线——把截图和目标模板图都转成特征向量/特征图在特征空间里找哪块区域跟目标图最像。形象点说传统模板匹配是拿照片找人特征匹配是拿通缉画像找人能容忍光照变化和一定程度的透视变形但要先理解目标是什么。这一步直接决定了识别的上限。我试过把目标图设计得过大比如截了整个卡片区域结果 App 字体微调后匹配置信度从 0.91 掉到 0.74直接识别失败。后来把目标图聚焦到卡片上的核心图标和按钮置信度才稳定到 0.88 以上。目标图越聚焦、内容越单一识别效果越稳。第三步最佳坐标计算与点击注入。识别引擎会返回目标在截图中的矩形区域通常是(x, y, width, height)或者中心点坐标。脚本拿到区域后以中心点作为点击坐标再通过auto.click()注入点击事件。这里面有个手指逻辑识别出来的往往是按钮区域但真正要点的位置有时需要微调。比如关闭广告按钮识别区域是整个弹窗的右上角卡片而实际可点击的像素点是卡片里的 X这时候就要在返回坐标基础上做人工偏移。第四步结果校验与状态循环。纯识别脚本的价值就在这一步。点击动作注入之后脚本不会盲目 sleep 两秒而是再次截图识别目标页面的新元素用页面是否出现特定图像来判断动作是否生效。举个例子我点击签到随后识别页面上是否出现签到成功四个字的区域——识别到了就继续下一步没识别到就重试或者上报失败。有这层校验脚本才敢说自己是自动化而不是盲自动。3. 从零写一个识别-点击-校验的最小可用脚本环境准备这部分我不想堆步骤只说两个容易卡住的点。一个是 Yyds.Auto 安装后必须到 App 内的无障碍服务入口开启权限另一个是截屏权限需要在系统的悬浮窗权限页面里打开。这两个权限缺失的表现完全不同无障碍缺失会导致点击事件注入时报ACCESSIBILITY_PERMISSION_DENIED截屏权限缺失会直接让截图返回 null。我建议把这两个权限的检测写在脚本启动阶段避免线上跑到一半才暴露。下面这个脚本是我自己一直在用的最小模板跑通之后再往里面加业务逻辑不迟const auto require(yyds.auto); // 启动前先确认权限 auto.requestScreenCapture(); if (!auto.accessibilityServiceEnabled()) { toast(请先开启无障碍权限); exit(); } // 读取目标模板图片 const templates { signButton: /sdcard/templates/sign_btn.png, // 签到按钮 signSuccess: /sdcard/templates/sign_success.png // 签到成功提示 }; function findAndClick(imgPath, threshold) { const res auto.findImage({ template: imgPath, threshold: threshold || 0.82, region: null }); if (res res.confidence threshold) { // 计算按钮中心点 const clickX Math.round(res.x res.width / 2); const clickY Math.round(res.y res.height / 2); auto.click(clickX, clickY); return { success: true, confidence: res.confidence }; } return { success: false, confidence: 0 }; } function waitForImage(imgPath, timeout) { const start Date.now(); while (Date.now() - start timeout) { const res auto.findImage({ template: imgPath, threshold: 0.80 }); if (res) return true; sleep(500); } return false; } function main() { // 1. 识别并点击签到按钮 const clickRes findAndClick(templates.signButton, 0.82); if (!clickRes.success) { log(签到按钮未找到当前置信度为 clickRes.confidence); return; } // 2. 等待签到成功提示出现最多等 5 秒 const verify waitForImage(templates.signSuccess, 5000); if (verify) { log(签到成功校验通过); } else { log(未检测到签到成功提示可能出现异常); } } main();几个值得细说的设计threshold 的取值不是越高越好。0.82 是我在多个 App 之间实测后觉得比较舒服的值。取太高0.95 以上只要 App 换了一层皮肤或者按钮颜色稍有变化识别就挂了取太低0.7 以下又会频繁把相似图案误判成目标产生乱点。如果你发现同一个模板在不同页面都能匹配上那就是 threshold 太低需要调高。调试阶段可以先打印 confidence 值看正常页面是多少、干扰页面是多少取两者的中间值作为阈值。waitForImage 里的 sleep(500) 和 timeout 参数是一个缓冲逻辑。点击之后页面加载需要时间如果立即截图识别大概率拿到的是旧页面校验会误报失败。半秒一次的轮询频率既不会响应太慢也不会给 CPU 造成过大压力。这里的时间参数需要根据目标 App 的实际加载速度调整慢的页面可以放宽到 8 秒。region 参数是性能救星。我的示例代码里写死了region: null也就是全屏搜索。但很多场景下目标按钮只会出现在某个固定区域比如底部导航栏的我的按钮永远在屏幕下方。这时把 region 限定为{x: 0, y: 1000, width: 1080, height: 300}搜索面积减小 70%识别速度能快三倍以上。开销能省则省这也是把脚本往大批量任务上推之前必须要做的优化。4. 实测中的三个意外情况识别偏移、分辨率适配和性能损耗跑通最小脚本只算入门真正让人头大的是真实环境里的那些意外。我整理了自己在实际项目中遇到最多的三类问题以及对应的处理思路。意外一返回坐标与实际可点击位置存在系统性偏移。这个问题最早出现在一艘全面屏手机上。Yyds.Auto 拿到的截图坐标系和实际触摸坐标坐标系并不是天然对齐的状态栏高度、导航栏高度、屏幕圆角切割区域都会造成偏移集中在屏幕边缘区域的元素尤其明显。解决方式是在脚本初始化阶段做一次像素校准先准备一张已知精确坐标的参考图点击后用 toast 打印识别结果和实际点击位置计算出 X/Y 方向的常量偏差在最终点击前统一加上这个偏移量。我自己的项目里这个偏移量通常是 0 到 20 像素左右但不同手机品牌差异明显不做校准很容易出现识别到了但点歪了的现象。意外二相同脚本在不同分辨率手机上表现差异大。这个问题的根源不在于 Yyds.Auto而在于截图像素密度变化后目标模板图并不能自动跟着缩放。我的实测案例同一张 208 像素高的按钮模板在 1080P 屏幕上识别正常放到 2K 屏幕上识别率直接降到 0.59。解决办法是准备多套同源的模板图每个分辨率级别一套或者在脚本启动时先读取屏幕分辨率再按比例加载对应目录下的模板。后者代码上更优雅本质是以存储换稳定性。不要妄想让一个模板通吃所有机型至少在商业 App 上这是行不通的。意外三识别引擎的 CPU/内存占用比预期高。纯 AI 图像识别不是免费的识别一帧 1080P 截图大概要占用 200MB 左右内存CPU 峰值能跑到单核 80%。如果在低端机上跑脚本会明显拖慢手机本身的操作。我的优化策略有三条一是尽量用 region 缩小搜索范围二是把连续识别的间隔拉长到秒级三是把模板图尺寸控制到 100 到 200 像素范围不要天真地用大尺寸模板提高精度识别精度主要靠特征质量而非像素量堆砌。做完这三条之后CPU 占用从峰值 80% 降到了 30% 左右续航影响也能接受。5. 与主流替代方案的横向对比Yyds.Auto 到底值不值得选评测一个自动化工具好不好用不能脱离场景。我拿 Yyds.Auto 和同一赛道的另外两类方案做了个横向对比。方案识别原理适用场景优势劣势控件节点方案如 uiautomator、Appium读取无障碍控件树标准原生控件 App速度极快、定位准确对 Flutter/游戏/自绘 UI 失效坐标脚本方案如传统按键精灵固定坐标点击分辨率固定的设备简单直接、兼容所有 UI换设备就废毫无自适应能力图像识别方案Yyds.Auto 为代表视觉特征匹配游戏、自绘 UI、跨设备不依赖控件、不依赖坐标消耗性能、需要模板和维护阈值从我个人的项目经验看它和另外两类方案并不是纯粹的替代关系更像是互补。处理标准列表页我会沿用控件节点方案读取节点信息来快速遍历一旦进入自定义控件区域或者游戏界面立刻切换到图像识别模块。Yyds.Auto 提供了在同一脚本里混用这两类 API 的能力这也是我选中它的一个重要原因。另外有个点必须提Yyds.Auto 是一个可以离线的本地识别引擎脚本跑的每一帧截图都只在本机处理不涉及任何云端回传。这一点对我这种对数据出镜比较敏感的场景至关重要。有些同类产品宣传的云识别虽然准确率更高但需要把屏幕截图上传到服务器对我来说一票否决。6. 进阶把单次点击脚本进化成可复用的小型自动化框架脚本写得多了我开始厌倦每次都要处理权限检测、模板加载、日志输出这些重复代码。所以我把上面这些逻辑抽成了一个基础模块现在新的任务脚本只需要写业务步骤本身。这个思路分享给大家代码不复杂但能极大提高后续脚本的开发效率。// yydsHelper.js —— 公共模块 const auto require(yyds.auto); class YydsHelper { constructor() { this.resolution ; this.offset { x: 0, y: 0 }; } init() { auto.requestScreenCapture(); if (!auto.accessibilityServiceEnabled()) { throw new Error(无障碍服务未开启); } this.calibrateOffset(); } calibrateOffset() { // 加载已知基准点模板计算坐标偏移量 const anchor auto.findImage({ template: /sdcard/templates/anchor.png, threshold: 0.9 }); if (anchor) { // 假设 anchor 的实际中心点在截图中的理论位置已知 this.offset { x: anchor.x anchor.width / 2 - EXPECTED_ANCHOR_X, y: anchor.y anchor.height / 2 - EXPECTED_ANCHOR_Y }; } } findAndClick(imgPath, threshold, region) { const res auto.findImage({ template: imgPath, threshold, region }); if (!res) return false; const x res.x res.width / 2 this.offset.x; const y res.y res.height / 2 this.offset.y; auto.click(Math.round(x), Math.round(y)); return true; } waitFor(imgPath, timeout, threshold) { const start Date.now(); while (Date.now() - start timeout) { if (auto.findImage({ template: imgPath, threshold: threshold || 0.8 })) { return true; } sleep(400); } return false; } log(msg) { console.log([${new Date().toLocaleTimeString()}] ${msg}); } } module.exports YydsHelper;个人强烈建议所有模板图命名遵循功能_描述_尺寸的规则。比如sign_btn_1080.png、close_ad_1440.png这样在脚本里出现问题排查的时候一眼就能看出是哪台设备、哪个目标图出了问题。文件命名这个习惯虽然不起眼但在脚本量超过十个之后真的能救命。还有一个很容易被忽略的细节截图目录和模板目录要定期清理。Yyds.Auto 默认会把运行日志和调试截图存到/sdcard/脚本目录/下跑久了会积累几百 MB 的垃圾文件。我专门写了一个清理函数每周自动删除三天前的调试截图避免存储占满导致截图接口报错。把 Yyds.Auto 的实际能力跑明白之后我的核心感受是纯 AI 图像识别自动点击这条路的门槛不高但天花板很高。门槛不高是因为 Yyds.Auto 已经把特征提取、匹配、坐标计算这些复杂流程封装成了几个简单 API写个能跑的脚本半个晚上就够了。天花板高是因为识别阈值怎么调、模板怎么裁、区域怎么限定、多分辨率怎么适配处处都是可以深挖的细节每一项都直接影响脚本在真实设备上的存活率。我目前这套基于模板匹配加轮询校验的方案已经稳定跑了两周日常签到、任务领取这类重复操作基本不再需要手动干预。如果你也在用 Yyds.Auto 或其他图像识别方案做自动化建议优先把校验闭环和坐标校准这两件事补齐脚本的稳定性会有一个质的提升。