企业官网建设流程全解析

手机上的重复操作，做久了真的会让人怀疑人生——每天点开同一个 App、滑到同一个位置、点同一个按钮，动作完全一样，却必须手动完成。AutoJS 就是来解决这类问题的：它是一套跑在 Android 设备上的 JavaScript 自动化框架，靠系统的无障碍服务拿到界面控件信息，再用脚本代替手指去点击、滑动、输入。这篇内容不讲空话，我会把 AutoJS 从环境搭建、控件定位、滑动翻页，一直讲到实际场景里的元素查找和稳定性排查，把我自己踩过的坑一条条摊开。适合两类人看：一类是写过一点 JS、想把手机操作自动化的开发者；另一类是没写过代码，但愿意照着例子改参数、能看懂逻辑的动手派。需要提前说清楚，脚本能省下的是你自己的重复劳动，不是拿来批量刷量、卡平台规则漏洞的，这个边界后面我会展开讲。

1. 先把问题想明白：手机 App 自动化到底难在哪

很多人对 AutoJS 的第一印象是"能自动点屏幕"，于是上来就写click(500, 1000)，跑两次能用，第三次就点空了。这不是脚本写得差，而是没搞清楚手机自动化的本质难点在哪。桌面端的自动化，窗口位置固定、控件句柄稳定、屏幕分辨率不变；手机端这三样全都在变——通知栏会弹出来遮住半屏、键盘会顶起布局、不同机型的分辨率差出好几倍、App 一次热更新就可能把按钮挪个位置。所以真正决定脚本能不能长期跑的，不是点击那行代码，而是"你怎么找到要点的东西"。

1.1 三条技术路线的取舍：坐标点击、控件驱动、图像识别

手机自动化的定位手段基本就三条路，各有各的适用面，我在不同项目里三种都用过。

坐标点击最简单，click(x, y)一行搞定。它的前提是界面布局绝对固定。优点是不依赖任何权限、执行快；缺点是脆得可怕，换台手机、改个字体大小、弹个广告就废了。我一般只把它当兜底，绝不作为主方案。

控件驱动是 AutoJS 的核心能力。Android 的界面本质上是一棵控件树，每个按钮、每个文本都有一个节点，节点上带着id、text、desc、className、bounds这些属性。脚本可以通过选择器精确描述"我要那个文字是'立即购买'的按钮"，然后拿到它的实时坐标再点击。界面挪位置没关系，只要属性没变，脚本就还能找到它。这条路最稳，但要求你会看控件树。

图像识别是第三条路，靠截图做模板匹配或者找色。它的优势是能处理那些没有控件属性的东西——游戏画面、视频画面、Canvas 绘制的元素，这些在控件树里往往只是一整块空白。代价是耗性能、对分辨率敏感、阈值调不好就误判。

实际项目里我基本是"控件优先、图像兜底、坐标最后"的组合拳，下面会具体讲怎么串起来。

1.2 AutoJS 的能力边界，以及它不适合干什么

先说清楚它能干什么：读取当前界面的控件信息、模拟点击和长按、模拟滑动和手势、输入文本、读取通知、截图、做图像处理、定时任务、读写本地文件、发 HTTP 请求。这些东西组合起来，覆盖了绝大多数"界面上的重复劳动"。

再说它干不了什么，这点比上面更重要。它不能修改别人的 App、不能绕过登录验证、不能突破平台的风控策略；它执行的是"一个手脚很快的用户"的操作，而不是什么后台特权。所以凡是需要"绕过""破解""批量"的需求，AutoJS 都不该被用在那里——一是平台规则不允许，二是账号风险完全由使用者承担，脚本本身没有任何保护能力。

我个人给 AutoJS 划的适用范围只有一条：处理自己账号下、平台允许手动完成的重复性操作。比如批量整理自己手机里的文件、把固定的信息录入到自己的记录表、给自己的设备做定时任务。越出这条线，技术上的收益远小于风险，不值得。

2. 从零把环境跑通：权限顺序错了会白折腾

AutoJS 装完打不开脚本、开了无障碍还是提示未开启、运行两分钟就报服务断开——这些几乎全是权限顺序和系统省电策略的问题。我见过太多人卡在这一步就放弃了，实际上只要按顺序把几项设置做对，后面基本不会再管它。

2.1 设备侧必须打开的几项设置

关键顺序是这样的，别跳步：

1. 先允许安装来自未知来源的应用，把 AutoJS 装上。
2. 打开无障碍服务。路径大致是"设置 → 无障碍/辅助功能 → 已安装的服务 → 找到 AutoJS → 开启"。第一次开启时系统会弹一个风险提示，确认即可。这一步是核心，控件读取和模拟点击全靠它。
3. 授予悬浮窗权限。调试时的悬浮控制台要靠它，没有这个权限，脚本跑起来你就只能干瞪眼。
4. 授予截图权限（需要用到图像识别时才要）。这个权限一般不能提前在设置里给，得在脚本运行时通过requestScreenCapture()动态申请。
5. 把 App 加入电池优化白名单，并在最近任务里锁定它。不同厂商叫法不同，有的叫"自启动管理"，有的叫"后台运行权限"。

注意：第 5 步是最容易被忽略、也最容易导致"脚本跑着跑着就不动了"的一步。系统在息屏或内存紧张时会回收后台进程，无障碍服务一断，所有控件操作全部失效，脚本却不会报错，只是安静地卡在那里。

还有一个坑：不要把 AutoJS 的省电策略设成"智能限制"或"优化"，要设成"无限制/不限制"。这个设置在应用信息页的电池选项里，改完之后建议重启一次 App 让服务重新绑定。

2.2 编辑与调试方式的选择

AutoJS 自带一个简易编辑器，写小脚本够用，但代码一多就很难受，没有代码折叠、没有跳转定义、补全也弱。我的习惯是两种方式混用：

• 写复杂逻辑：在电脑上用 VS Code 写好，通过局域网文件同步或者直接复制粘贴到手机上的脚本文件里。
• 调参数：在手机自带编辑器里改，因为要边跑边调，来回同步太慢。

调试输出我基本不用console.log弹窗，而是用console.show()打开一个悬浮日志窗口，然后用log()打时间戳和当前状态。悬浮窗的好处是脚本跑的时候你还能看到实时输出，不用退出 App。

// 打开悬浮日志窗口，方便观察运行状态 console.show(); console.setSize(device.width * 0.9, device.height * 0.3); function logStep(msg) { log("[" + new Date().toTimeString().slice(0, 8) + "] " + msg); }

时间戳这一步看着不起眼，但排查"卡在哪一步"的时候，有没有时间戳完全是两种效率。我踩过一次坑：脚本在某个循环里静默卡了四十分钟，因为没有日志，只能从头重跑复现。

2.3 第一个能跑起来的脚本

别一上来就写复杂逻辑，先用五行代码确认环境是通的：

// 等待无障碍服务就绪，最多等 10 秒 auto.waitFor(); toast("服务已就绪"); logStep("屏幕尺寸: " + device.width + " x " + device.height); // 打开设置页，验证控件读取和启动能力 app.launchPackage("com.android.settings"); sleep(2000); // 试着读取当前界面上所有可见文本 var texts = textMatches(/.+/).find(); logStep("当前界面文本节点数量: " + texts.length);

这段跑通，说明无障碍、启动应用、控件读取三条链路都正常。texts.length如果是 0，别怀疑代码，回去检查无障碍服务是不是真的开了——有时候系统显示已开启，实际进程已经被回收，需要关掉再开一次。

3. 控件定位：整个自动化里最吃功夫的一环

脚本写得漂不漂亮无所谓，定位准不准才是生死线。我做过一个统计，一个稳定的自动化脚本，调试时间大概有七成花在"找元素"上。这一节把控件定位的方法论拆开讲。

3.1 用布局分析工具读懂控件树

AutoJS 自带布局分析功能，开启后会在屏幕上显示一个悬浮球，点开能看到当前界面的层级结构，点任意一个控件就能看到它的全部属性。这个工具用熟之后，定位效率能提升好几倍。

看控件树的时候，我会重点关注四个属性：

id是首选，因为它跟显示文字无关，切语言也不受影响。但国内的 App 很多做了资源混淆，id变成a1b、c2d这种无意义字符串，而且每次发版还会变，这种情况就只能退到text或desc。

还有一个技巧：如果要点的是一个图标按钮，它本身没有text，但通常它的父节点或者旁边的兄弟节点有文字标签。这时候可以用className加上boundsInside限定区域来筛，比盲目全屏找要快得多。

3.2 选择器语法与几种常用匹配策略

AutoJS 的选择器写法很直观，字符串参数匹配text，带Contains的是包含匹配：

// 精确匹配 var btn = text("立即领取").findOne(3000); // 包含匹配，适合文字前后带数字或空格的情况 var btn2 = textContains("领取").findOne(3000); // 正则匹配，适合文字格式固定但内容变化的情况 var btn3 = textMatches(/剩余\d+次/).findOne(3000); // 多条件组合：类名 + 可点击 var btn4 = className("android.widget.Button").clickable(true).findOne(3000);

几个我反复验证过的经验：

• findOne()一定要给超时参数。不给的话默认是无限等待，一旦元素不存在，脚本就永久挂死在那里，连日志都不打。
• 优先用textContains而不是text。界面上经常出现"领取"后面跟个角标数字，或者前后带空格，精确匹配反而找不到。
• 匹配结果可能有多个时，用find()拿到数组，再按bounds()的位置排序取最靠上或最靠左的那个，避免点到列表里重复出现的同名按钮。
• 需要操作一个不可点击的节点时，可以往上找它的父节点：node.parent()，或者用clickable(true)反查最近的祖先。我遇到过很多次点击无效，最后发现点的是TextView，真正能响应的是它外面包的那层LinearLayout。

3.3 控件找不到时的兜底：图像匹配与坐标回退

再怎么优化选择器，也总有一些元素在控件树里查不到——视频画面上的浮层、游戏渲染的元素、被 WebView 绘制出来的东西。这时候就得上图像识别。

图像匹配的流程是：先截取一张目标元素的小图作为模板存到本地，运行时截图整屏，用模板去匹配，拿到匹配区域的中心坐标。

// 申请截图权限（只需一次） if (!requestScreenCapture()) { toast("截图权限被拒绝"); exit(); } // 读取模板图 var template = images.read("/sdcard/tpl_btn.png"); // 截取当前屏幕 var screen = captureScreen(); // 模板匹配，similarity 是相似度阈值 var point = findImage(screen, template, { threshold: 0.85 }); if (point) { click(point.x + template.width / 2, point.y + template.height / 2); } else { logStep("模板未匹配到目标"); } // 及时回收，否则内存会涨得很快 screen.recycle(); template.recycle();

这里有几个必须注意的点：

注意：模板图必须从目标设备本身截取，不要用另一台手机截的图。不同分辨率、不同屏幕密度下，同一个按钮的像素尺寸可能差一倍，模板匹配直接失败。

注意：threshold不要一上来就设 0.95。界面有渐变、有半透明遮罩、有轻微压缩噪声，阈值过高会频繁匹配失败。我的经验起点是 0.8，稳定后再往上加。

坐标回退是最后一招，只在"界面完全固定且无法用其他方式定位"时用，而且必须写成相对坐标：

// 相对坐标，避免不同分辨率下失效 var x = device.width * 0.5; var y = device.height * 0.85; click(x, y);

图像识别的性能开销不小，一帧匹配在中端机上可能要几百毫秒。所以不要在死循环里高频调用，通常是先跑控件查找，找不到再走图像，两三次失败就退出，别硬耗。

4. 滑动翻页：为什么你的脚本总是滑不动

滑动看着最简单，实际上是我被问得最多的一个问题。"我写了 swipe，脚本也执行了，但页面纹丝不动"——这类问题九成出在参数上，而不是代码本身。

4.1 swipe 和 gesture 到底差在哪

这两个 API 表面上都是滑动，底层机制差别很大。

swipe(x1, y1, x2, y2, duration)是模拟一次带速度的手势。关键在于duration这个参数：

• duration很短（比如 100 到 200 毫秒）时，系统会把它识别为一次快速滑动，带惯性，松手后页面会继续滑行一段距离再停下。
• duration中等（500 毫秒左右）时，接近手指匀速拖动的效果，惯性较小。
• duration很长（超过 1000 毫秒）时，系统可能把它识别成长按拖动，某些列表会触发选中或者拖拽排序，完全不是你想要的效果。

gesture(duration, [x1, y1], [x2, y2], ...)则是按你给定的路径点均匀分配时间，几乎不产生惯性，滑到哪就停在哪。需要精确控制滑动距离的时候，我基本都用它。

// 带惯性的快速滑动，适合"刷信息流"这种需要连续翻页的场景 swipe(device.width / 2, device.height * 0.75, device.width / 2, device.height * 0.25, 300); sleep(500); // 精确滑动，滑多少就走多少，适合"必须停在第 N 屏"的场景 gesture(600, [device.width / 2, device.height * 0.75], [device.width / 2, device.height * 0.25]);

选择逻辑很简单：要"翻页快、不用管停在哪"用swipe短时长；要"每次滑动的距离一致、可预测"用gesture。

4.2 滑动起止点与距离的计算

滑动起止点不能随便写，踩过的坑都在这几个地方：

起点不要贴边。很多手机在屏幕底部三分之一区域有系统返回手势，顶部有下拉通知栏的手势。如果你的起点落在这些区域，滑动会被系统截走，App 根本收不到事件。我的经验值是纵向留出 15% 的安全边距。

滑动距离不要太大。一次滑过屏幕高度的 60% 以上，页面可能直接跳过你想要的区域，甚至触发"回到顶部"的快捷操作。半屏左右是比较稳的距离。

横向滑动的边界同理。左右滑动通常要避开屏幕左右各 10% 的区域，那里是系统返回手势的触发带。

综合下来，我常用的翻页参数是这样的：

var startY = device.height * 0.72; // 起点偏下，避开中间内容区的按钮 var endY = device.height * 0.28; // 终点偏上，避免触碰顶部标题栏 var midX = device.width * 0.5; // 横向居中，避开左右边缘手势 // 向上翻页（看后面的内容） gesture(500, [midX, startY], [midX, endY]); // 向下翻页（往回看），把起止点反过来 gesture(500, [midX, endY], [midX, startY]);

autojs往上翻页这个需求对应的其实就是第二种——起止点反过来写。方向搞错是最低级的错误，但真有人调了半天参数才发现是方向反了。

4.3 循环翻页的终止条件怎么写

翻页本身不难，难的是"什么时候该停"。写个while(true)死循环翻下去，轻则耗电耗流量，重则触发 App 的异常检测。终止条件我一般用三种组合：

第一种，目标出现即停。每翻一页检查一次目标元素是否存在：

var found = false; for (var i = 0; i < 30; i++) { if (textContains("目标关键词").exists()) { found = true; logStep("第 " + (i + 1) + " 页找到目标"); break; } gesture(500, [midX, startY], [midX, endY]); sleep(800); }

第二种，页面不再变化即停。到底了还继续滑，页面内容不变，这就是终止信号。判断方式是比较滑动前后某个标志性元素的坐标或文本：

var lastAnchor = ""; var sameCount = 0; while (sameCount < 3) { var anchor = ""; var node = className("android.widget.TextView").findOnce(); if (node) anchor = node.text(); if (anchor === lastAnchor && anchor !== "") { sameCount++; } else { sameCount = 0; lastAnchor = anchor; } gesture(500, [midX, startY], [midX, endY]); sleep(800); } logStep("连续 3 次无新内容，判定已到底");

第三种，次数上限硬约束。不管有没有满足前两个条件，最多翻 N 页就退出。这是保命机制，防止逻辑判断出错时无限跑下去。

提示：三种条件建议同时用。次数上限是兜底，页面无变化是正常终止，目标出现是提前结束。只写其中任何一种，都会在某些分支场景下出问题。

另外一个细节是sleep的时长。滑动之后要给页面留出渲染时间，800 毫秒是个比较保守的值。设太短的话，你读到的是上一页的控件树，判断自然全错。这个坑我在做信息流翻页时踩过好几次，日志里显示"检测到目标"，截图一看还在上一屏。

5. 实战拆解：定位直播间里的浮动元素

autojs 找抖音福袋的位置这个搜索词背后，其实是一个很典型的 UI 定位难题：目标元素是浮动的、位置随机、出现时间有限、还会被其他元素遮挡。这类问题的解法思路，可以推广到所有"动态浮层定位"的场景。需要提前说明，下面讲的纯属 UI 定位的技术思路，实际使用请遵守对应平台的使用规则，不要做批量或多账号操作。

5.1 为什么固定坐标在这类场景一定翻车

直播间的浮动元素有几个特性，决定了坐标方案必然失效：

位置随机。浮层可能出现在屏幕右下、左下、或者中部悬浮，不同直播间、不同时间的位置都不一样。写死一个click(800, 1200)，可能十次里对三次。

尺寸随内容变化。浮层上带着倒计时数字或者状态文字，数字位数变化时宽度会变，控件本身的bounds也跟着变。

会被遮挡。弹幕、礼物特效、连麦窗口都可能盖在它上面，导致你点下去点到的是别的东西。

有时效性。它可能只在特定时间窗口内存在，脚本慢了就消失了，这时候再去点，操作落到的是底下的内容区，可能触发完全无关的动作。

所以正确的思路是"实时定位"，每次操作前都重新查一次它的当前坐标，而不是缓存第一次找到的位置。

5.2 多策略组合定位与超时重试

我处理这类元素的套路是三层查找，逐层降级：

function locateFloatingElement(maxWaitMs) { var deadline = new Date().getTime() + maxWaitMs; while (new Date().getTime() < deadline) { // 策略一：控件特征匹配（最稳） var node = descContains("福袋").findOnce() || textContains("福袋").findOnce(); if (node) { var b = node.bounds(); if (b.width() > 0 && b.height() > 0) { logStep("控件定位成功: " + b.centerX() + "," + b.centerY()); return { x: b.centerX(), y: b.centerY(), by: "control" }; } } // 策略二：图像模板匹配（兜底） var tpl = images.read("/sdcard/tpl_fudai.png"); if (tpl) { var screen = captureScreen(); var p = findImage(screen, tpl, { threshold: 0.82 }); screen.recycle(); tpl.recycle(); if (p) { logStep("图像定位成功: " + p.x + "," + p.y); return { x: p.x + tpl.width / 2, y: p.y + tpl.height / 2, by: "image" }; } } sleep(300); } logStep("超时未找到目标"); return null; }

这段代码里有几个设计意图，值得单独说：

为什么用findOnce()而不是findOne()？findOne自带等待，在里面套一层 while 循环会导致等待时间层层叠加，实际响应反而变慢。用findOnce()立即返回，由外层循环控制节奏，超时时间是可控的。

为什么每次循环都重新读模板图？理论上可以提到循环外读一次，但实际调试时我保留了在内部读取的写法，方便替换模板。正式跑的时候应该提到外面，避免重复 IO。

为什么循环间隔是 300 毫秒？太密会占满 CPU，导致截图变慢、反而错过时机；太疏可能元素出现后 1 秒才被检测到，窗口期就过了。300 毫秒是我实测比较平衡的值。

为什么判断bounds的宽高？有些节点虽然存在，但处于不可见或者零尺寸状态，bounds()返回的是空矩形，直接取中心点会点到(0,0)。这个判断帮我避开过好几次莫名其妙的点击。

5.3 点击之后的确认动作

点完就完事，是脚本出 bug 的主要来源之一。点击这个动作本身只表示"事件发出去了"，不代表"操作成功了"。所以每次点击之后都要有一个确认动作：

var target = locateFloatingElement(8000); if (target) { click(target.x, target.y); sleep(600); // 确认动作：看目标元素是否消失，或者出现了预期的结果提示 var stillThere = descContains("福袋").findOnce(); if (!stillThere) { logStep("点击生效，目标已消失，定位方式: " + target.by); } else { logStep("点击可能未生效，准备重试"); // 这里可以加一次重试，但最多一次，避免陷入循环 } }

确认逻辑要看场景而定。有些场景是"目标消失"代表成功，有些是"新页面出现"代表成功，还有的是"出现了一个 toast 提示"。核心原则是：任何一个有副作用的操作，都必须有一个可观测的确认信号。没有确认信号的自动化脚本，出问题时你连"是哪一步错了"都不知道。

另外补一个细节：click()有返回值，返回true表示事件成功注入。但这个返回值只能说明"事件发出成功"，不能说明"业务处理成功"。真正可靠的是上层的界面状态判断，别把click的返回值当成成功标志。

6. 稳定性与问题排查实录

脚本能跑通一次和能稳定跑一个月，中间隔着一整个工程实践的距离。这一节是我整理的问题清单和几条长期跑下来的习惯。

6.1 常见故障速查表

这张表里的每一条都是我自己撞过的。其中"点击无反应"是最耗时间的，因为现象是沉默的——脚本不报错，只是什么都没发生。我的排查顺序是：先用日志打出节点的bounds，确认矩形位置和大小正常；再打出clickable属性；最后用布局分析工具在手点的情况下看看到底激活的是哪个节点。

6.2 让脚本跑得久的几个工程习惯

第一，所有等待都要有上限。findOne()给超时、while循环给最大次数、waitFor()给超时时间。任何没有上限的等待，都是定时炸弹。

第二，关键节点打日志，但要节制。我习惯在"定位成功/失败""点击前后""每轮循环开始"这三个位置打日志。频率太高的日志（比如每次截图都打）会拖慢执行，也会把有用信息淹掉。

第三，资源一定要回收。图像处理是内存消耗大户，captureScreen()拿到的对象和images.read()读到的模板都占内存，用完必须recycle()。我做过对比，同一段跑两小时的脚本，加回收和没加回收，内存占用能差好几倍，没回收的那个基本撑不过一小时。

第四，把易变的参数抽出来放开头。屏幕比例、等待时长、重试次数、相似度阈值，这些全都提到脚本顶部集中定义。App 更新后要调整，改一行就够了，不用在几百行代码里翻。

// ===== 可调参数集中区 ===== var CFG = { swipeStartRatio: 0.72, // 滑动起点纵向比例 swipeEndRatio: 0.28, // 滑动终点纵向比例 swipeDuration: 500, // 滑动时长（毫秒） renderWait: 800, // 翻页后等待渲染的时间 maxPages: 30, // 最大翻页次数 matchThreshold: 0.82, // 图像匹配相似度阈值 retryLimit: 3 // 单步最大重试次数 };

第五，异常要捕获，不能让整个脚本崩掉。用try...catch把主循环包起来，出错时记录日志、释放资源、决定是继续还是退出。自动化脚本运行时间长，环境变化多，没有任何异常处理的脚本基本上活不过一天。

try { mainLoop(); } catch (e) { logStep("运行异常: " + e); // 释放图像资源 images.releaseScreenCapture(); } finally { logStep("脚本结束"); }

第六，别把频率拉满。不管什么场景，操作间隔都留出自然的停顿。一方面是为了等界面渲染，另一方面也是让脚本的行为更接近正常使用节奏。把点击间隔压到几十毫秒，除了让设备发烫、更快触发异常，没有任何好处。

我个人在长时间跑的脚本里还有个小习惯：加一个"健康检查"计步器，每跑满 100 轮就在日志里打一次运行时长和当前内存占用。这个习惯帮我抓到过一次内存缓慢增长的问题——脚本跑三小时后开始变卡，日志显示内存曲线一直在涨，最后定位到是某处截图忘了解析释放，补上之后就稳了。自动化脚本的稳定性问题，十有八九都藏在这种细节里，而日志是唯一能把它们挖出来的工具。