如果你经常需要处理一些重复性的手机操作——比如每天定时解锁手机、清空通知、把阅读类App里的文章一篇一篇划过去——你大概率动过用脚本自动搞定的念头。Auto.js就是干这个的一个基于JavaScript的安卓自动化工具能模拟点击、滑动、输入文字、识别屏幕控件也支持定时、无障碍、进程通信等等。而一旦你的手机是小米跑的是MIUI恭喜你踩坑之旅正式开启。这篇文章是我自己在MIUI系统上从零折腾Auto.js的真实记录目标非常明确解锁手机 → 启动阅读类App → 自动翻页/滑动 → 准确退出同时保证脚本能在锁屏状态下稳定执行、不被MIUI的后台清理机制杀掉。内容会覆盖版本选型、权限配置、锁屏解锁、滑动策略、保活方案和排错速查全部基于我实际测试过的场景不是照着文档念。适合谁来读想用Auto.js写个人工具脚本的入门者、被MIUI权限搞到头大的小米用户、以及想系统了解安卓无障碍自动化的朋友。先说好所有内容都建议用在自动化学习、个人效率工具开发这类合规场景里别拿去搞刷量、薅羊毛之类的灰色操作平台规则和法律红线都要守。1. 先认清Auto.js和MIUI这对组合1.1 Auto.js到底是个什么东西Auto.js本质上是一个运行在安卓设备上的JavaScript脚本引擎它把系统无障碍服务、悬浮窗、按键模拟、文件读写、网络请求这些能力全部封装成了简单易用的API。你不需要Root也不需要写原生安卓代码只要会用JavaScript的基础语法就能让手机自己“看屏幕、动手指”。它工作的底层原理值得先搞清楚安卓系统有一个叫做AccessibilityService的服务原本是为了帮助视障人群操作手机而设计的它可以读取界面上的控件信息也能模拟点击和滑动操作。Auto.js先把无障碍服务激活然后通过这个服务获取当前屏幕上所有控件的坐标、文本、ID等属性再调用click()、swipe()这类API去执行动作。理解这一点后你就知道写Auto.js脚本的核心思路其实只有一个先找到目标控件再决定怎么操作它。找到控件的方式可以是根据文本text(下一页)、根据IDid(btn_next)、根据控件层级关系className、desc等也可以退而求其次用坐标直接模拟。前者最稳定后者是兜底方案这两个在后面实战里都会用到。1.2 为什么MIUI的适配难度天然就高很多人在网上搜“Auto.js 脚本”拿过去一跑就报错换个小米手机更是各种莫名其妙的问题。这不全是脚本作者的锅MIUI本身的系统策略决定了它和自动化脚本“八字不合”。MIUI对应用权限的管理比原生安卓收紧得多。原生安卓里无障碍服务开启后就基本能用但MIUI会额外管你“自启动”“后台弹出界面”“省电策略”“锁屏显示”等等一大堆权限。任何一个没开脚本就会出现奇奇怪怪的症状解锁后不到30秒脚本被杀、定时任务不执行、屏幕锁了之后脚本直接停摆、悬浮窗按钮不显示……这些都是我在实际使用中一条条踩出来的。另外MIUI对后台进程的清理非常激进尤其默认的“均衡”省电模式下非白名单应用在锁屏后很短时间就会被冻结。Auto.js这种需要常驻后台的工具型应用如果不进行专门配置大概率活不过一个锁屏周期。所以在MIUI上配置权限的时间比写脚本的时间还长这是正常现象不必怀疑人生。1.3 版本选型和资源获取的坑先聊版本。Auto.js的版本线比较混乱常见的有几个阵营早期的官方开源版Auto.js 4.x后来的Auto.js Pro8.x以及一些基于旧版二次开发的修改版。用下来我的建议是Auto.js 4.x开源版免费、轻量、API文档齐全适合学习基础入门。但它对安卓高版本的适配一般部分设备上无障碍服务不稳定。Auto.js Pro 8.x多了打包APK、插件市场、更好的后台存活能力稳定性高不少。唯一的问题是它是付费软件而且官方渠道已经停售只能通过其他渠道获取。这里必须提一嘴资源获取的坑。Auto.js Pro官方停售后网上大量资源都是通过网盘分享流传的最常见的形式就是蓝奏云链接配一个解压密码。下载下来的东西五花八门有的版本比较老有的内嵌了额外推广甚至有被二次打包、夹带私货的风险。我踩过的坑是下载过一个“豪华版”装上之后无障碍服务老是自动关闭后来发现是被某个模块强制篡改了系统设置。所以我的建议就三条第一优先用Auto.js 4.x开源版学习API和Pro版90%以上是通用的第二非要找Pro版资源尽量找知名度高、在技术社区里被讨论过的版本别碰来路不明的“破解版”第三装好后第一时间检查应用申请的权限列表有明显异常的立刻卸载。脚本和依赖库优先从GitHub、Gitee或作者随包附带的蓝奏云目录里获取不要图方便去下载人家整合好的“一键全家桶”。2. 权限配置是成败的关键MIUI权限全家桶这一节是整篇文章里最枯燥、但最不能跳过的部分。我把在MIUI以MIUI 14、HyperOS为例不同版本菜单名称略有差异上跑Auto.js所涉及的权限一一列出来每个都会说明路径、作用和不开会有什么后果。2.1 无障碍服务一切自动化的地基设置路径设置 → 更多设置 → 无障碍 → 已下载服务 → Auto.js或已安装的服务→ 开启。这个权限是Auto.js模拟点击、滑动、读取控件信息的唯一通道相当于给脚本装了一双眼睛和一只手。不开它Auto.js可以启动但脚本一执行就报“无障碍服务未开启”。需要注意的坑是MIUI在某些情况下会自动关闭无障碍服务。常见触发场景包括——系统更新后、清理后台时误点、部分“省电模式”策略干预。所以我每次给脚本写完新功能第一件事都是检查无障碍服务是否还活着。另外开启无障碍服务会有一个系统弹窗提醒内容是“此服务可以监控您的操作”这是正常现象不用慌。2.2 锁屏显示与锁屏后运行设置路径设置 → 应用设置 → 应用管理 → Auto.js → 权限管理 → 锁屏显示 → 允许。如果你希望脚本在锁屏状态下还能继续执行这一项必须打开。MIUI默认会限制应用在锁屏后的显示行为不开启的话手机一锁屏Auto.js的界面渲染和相关任务就会被挂起屏幕上可能什么都看不见脚本看起来就像“死掉”了一样。另一个相关的选项是“锁屏后运行”不同MIUI版本位置不太一样有的直接在权限管理里有的在省电策略里。设置原则是锁屏显示设置为“允许”省电策略设置为“无限制”。这两个组合是我测试下来最稳定的配置。2.3 后台弹出界面、自启动与省电策略这三个权限我放在一起说因为它们的共同目标是解决一个核心问题让Auto.js在后台不被MIUI杀死并且在需要时能自己弹起来。自启动设置 → 应用设置 → 应用管理 → Auto.js → 自启动 → 开启。不开的话开机后Auto.js不会自动启动你的定时任务自然就废了。后台弹出界面设置 → 应用设置 → 应用管理 → Auto.js → 权限管理 → 后台弹出界面 → 允许。这个权限影响的是应用在后台时能否直接弹出界面或悬浮窗。脚本里如果有app.startActivity()之类的操作不开启会被拦截。省电策略设置 → 应用设置 → 应用管理 → Auto.js → 省电策略 → 无限制。这一项极其关键。MIUI的省电策略有三个档位智能限制、限制后台、无限制。默认的“智能限制”就足够让Auto.js在锁屏后被冻结。我见过很多人脚本写着写着突然不动了十有八九就是省电策略没有改成“无限制”。权限设置路径MIUI/HyperOS作用不开的后果无障碍服务设置-更多设置-无障碍-已下载服务模拟点击/滑动/读取控件脚本无法执行锁屏显示应用管理-Auto.js-权限管理锁屏后正常显示界面锁屏后脚本挂起自启动应用管理-Auto.js-权限管理开机自动启动定时任务失效后台弹出界面应用管理-Auto.js-权限管理后台时弹出界面/悬浮窗部分Activity启动被拦截省电策略应用管理-Auto.js-省电策略后台存活关键锁屏后台被冻结悬浮窗应用管理-Auto.js-权限管理显示悬浮控制按钮无法快捷启动脚本通知权限应用管理-Auto.js-通知管理常驻通知/日志提示前台服务被系统判定为低优先级2.4 悬浮窗与通知权限悬浮窗权限在应用管理-Auto.js-权限管理-显示悬浮窗里它的作用是在屏幕上方显示一个小悬浮按钮方便你随时启动/停止脚本。MIUI对悬浮窗的权限控制是逐应用级别的开了这个权限之后还要额外允许“在后台显示”否则脚本一退到后台悬浮按钮就会消失。通知权限看起来最不起眼但对保活帮助很大。Auto.js在使用“前台服务”模式时需要对应通道的通知才能保持前台服务状态如果通知权限被关掉前台服务的权重会大幅下降系统在内存紧张时会优先处理它。我的习惯是给Auto.js的通知权限设为“允许”并设置一个专用的低优先级通知通道这样既不会频繁打扰我又能保证服务稳定。配置完这一堆权限后有件事一定别忘了做重启一遍手机再回来确认各项权限没有被打回去。我遇到过MIUI在某些系统界面下应用权限设置看起来生效了但重启后又被恢复成默认值的情况。这个概率不高但一旦发生排查起来极其痛苦。3. 从解锁手机开始一次稳妥的锁屏自动化权限配好之后终于可以进入核心代码环节。这一节我会从零到一写一个“检测锁屏 → 滑动解锁 → 输入密码 → 等待解锁完成”的流程并解释每一步为什么要这么做。3.1 如何检测当前是否处于锁屏状态解锁的前提是先判断手机到底锁没锁。这个判断用Auto.js的device.isScreenOn()只能拿到屏幕是否亮起拿不到锁屏状态。比较靠谱的做法是结合两个信号屏幕状态和当前页面的类名。function isScreenOn() { return device.isScreenOn(); } function isLocked() { // 通过当前Activity名称判断是否在锁屏界面 let current currentActivity(); // 不同MIUI版本的锁屏Activity名称略有差异 if (current.includes(Keyguard) || current.includes(LockScreen)) { return true; } return false; }currentActivity()返回的是当前前台Activity的完整名称MIUI锁屏界面的Activity通常带有Keyguard或LockScreen关键字。实测下来这个判断在大多数MIUI版本上都是可靠的但也要注意一些小概率情况比如手机处于“息屏但未锁屏”的过渡状态这时候currentActivity()拿到的可能还是解锁前的App。所以更稳的判断逻辑是先等屏幕亮起再循环检测当前Activity是否包含锁屏关键字同时判断屏幕上有没有锁屏特有的元素比如时间显示控件、解锁提示文字。两者至少满足其一才认为手机处于锁屏状态避免误判。3.2 亮屏与滑动解锁的时序问题MIUI手机息屏状态下需要先有一个“点亮屏幕”的动作然后才能滑动解锁。Auto.js里点亮屏幕的方式有好几种// 方式1按下电源键亮屏 device.wakeUpIfNeeded(); // 方式2如果唤醒失败模拟按下电源键 if (!device.isScreenOn()) { KeyCode(KEYCODE_POWER); sleep(500); }这里有个关键的时序坑亮屏之后不能立刻滑动必须等待锁屏界面完全渲染出来。我实测过部分MIUI版本在亮屏后300毫秒内滑动滑动事件会被系统当成“误触”直接忽略甚至可能触发紧急求救连续按电源键、快速滑动等。稳妥的做法是亮屏后先sleep(800)再用swipe()做解锁动作。MIUI的锁屏滑动有两种常见形式向上滑动或向右滑动取决于系统设置。Auto.js里的滑动是纯坐标操作// 获取屏幕宽高 let w device.width; let h device.height; // 从屏幕底部偏上位置向上滑 function swipeUpToUnlock() { let startX w / 2; let startY h - 400; let endY 400; swipe(startX, startY, startX, endY, 300); }这个滑动的起点和终点不能太靠近屏幕边缘否则MIUI的“底部上滑手势”会误触发多任务或者返回桌面。我的经验是纵向上至少离开屏幕上下边缘各200像素以上滑动时长控制在200-400毫秒太快会被判定为无效手势太慢则可能被识别为长按拖动。3.3 图案解锁和密码输入的坑如果手机设置了锁屏密码或图案滑动之后还需要填写密码。图案解锁看起来最简单实际上是最容易翻车的因为MIUI的图案解锁界面每隔一段时间会随机变换一次九宫格坐标这是防第三方录屏的一个机制所以你不能把坐标写死。我的方案是在解锁前先通过无障碍服务读取锁屏界面的控件树找到九宫格的根节点位置再根据根节点坐标计算每个点的相对位置。九宫格通常是一个宽高接近正方形的控件我们可以拿到它的bounds()然后把区域三等分得到9个格子的中心点。function getPatternPoints(patternRoot) { let rect patternRoot.bounds(); let w rect.width() / 3; let h rect.height() / 3; let points []; for (let row 0; row 3; row) { for (let col 0; col 3; col) { points.push({ x: rect.left w * (col 0.5), y: rect.top h * (row 0.5) }); } } return points; }然后传入一个定义好的图案序列比如“从1滑到5再滑到9”就表示从points[0]滑动到points[4]再滑动到points[8]。注意两点每两个点之间的滑动延时不要太短50-100毫秒比较合理另外滑动路径如果跨过中间点系统要求必须经过中间点这个要按具体图案处理别自己优化路线。密码输入相对简单MIUI的密码键盘控件的文本属性一般可以直接读取用textContains(1)的方式定位数字然后click()。如果密码包含字母和符号就更依赖控件识别纯坐标方案基本不可靠。这里的原则是能识别控件就绝不写死坐标因为键盘布局在不同屏幕分辨率下差异很大。3.4 解锁完成后的“防呆”处理解锁完成不等于可以立刻执行阅读任务。很多人在解锁后马上启动App结果界面还没完全加载click()点到了错误位置整个流程就崩了。我习惯在解锁后加一个“等主屏幕出现”的确认逻辑// 等桌面图标出现最多等10秒 let launched false; for (let i 0; i 20; i) { sleep(500); if (text(设置).exists() || desc(通知栏).exists()) { launched true; break; } } if (!launched) { // 说明可能还在锁屏或异常界面 toast(解锁失败请检查锁屏方式); exit(); }这里的“设置”图标和“通知栏”描述只是示例不同系统版本要按实际情况调整。核心思想很简单每一步操作之后都要等待前一步的结果被确认再执行下一步这是自动化脚本稳定运行的第一准则。4. 自动阅读脚本的实战落地解锁完成后就进入重头戏自动阅读。这一节我会以常见的阅读类App资讯流、小说阅读器都适用为例讲清楚怎么设计一套既稳定、又不容易被系统或App判定为异常操作的自动阅读脚本。4.1 阅读类App的界面特征与自动化策略阅读类App的典型界面可以分成两类信息流式和翻页式。信息流式常见于新闻资讯App内容是上下滚动的长列表翻页式常见于小说阅读器每页固定文本点击或滑动后切换下一章。两种界面的自动化策略截然不同信息流式核心操作是模拟“上滑”隔一段时间滑一次直到出现某个内容或达到阅读时长。翻页式核心操作是模拟“翻页”有可能是点击屏幕右侧也可能是向左滑动每翻一页需要等待页面加载。写脚本之前先明确目标App属于哪一种再决定策略。混用两种策略会导致阅读进度异常、甚至被App检测到。我自己的做法是用一个配置变量控制模式方便不同App间切换const CONFIG { mode: scroll, // scroll 信息流, flip 翻页 intervalMin: 8000, intervalMax: 15000, maxScrollPerHour: 200, targetDuration: 30 * 60 * 1000 // 目标阅读时长,单位毫秒 };4.2 控件识别优先、坐标模拟兜底在自动阅读场景里最怕的是误触广告、误点评论区、误刷到不同频道。如果你写死坐标去滑动一旦App改版或者分辨率不同脚本就会“瞎点”。所以我强烈建议使用控件识别为主、坐标模拟为辅的混合方案。以信息流App为例我想找一个标志性的内容卡片比如文本“推荐”标签或某个标志性按钮。找到之后以这个控件的位置作为参考点向上滑动时从它上方开始滑滑到它下方结束这样能保证滑动区间始终落在列表区域内不会滑到顶部的Tab栏或底部的导航栏。function isElementInList(element) { let rect element.bounds(); let screenH device.height; // 判断元素是否位于屏幕中间60%区域 return rect.top screenH * 0.2 rect.bottom screenH * 0.8; } function scrollToNextPage() { // 先尝试找到列表容器里的某个已知控件 let anchor text(热榜).findOne(3000); if (anchor isElementInList(anchor)) { let rect anchor.bounds(); let startY rect.top - 200; let endY rect.bottom 300; let startX device.width / 2; swipe(startX, startY, startX, endY, 600); } else { // 兜底全屏中央上滑 let w device.width; let h device.height; swipe(w / 2, h * 0.8, w / 2, h * 0.2, 600); } }这个函数我每次写自动滑动都会套用它能在绝大多数情况下滑到正确位置。核心逻辑就是让滑动动作的起始点和结束点都落在内容列表区域内避免滑到非目标区域造成误触。兜底方案保证就算没找到锚点控件脚本也不会直接崩掉。4.3 滑动节奏、“伪随机”与“防检测”设计这是全篇最需要强调经验的地方。很多新手写自动阅读为了快每5秒滑一次每次滑一下间隔全部一样这种脚本活不过半小时——轻则被App风控逻辑判定为“异常活跃”重则直接封号。我实测过单纯为了快速刷页面的脚本用不了多久就会出现“阅读进度不计入”“需要验证码”等问题。更好的做法是模拟真人阅读的节奏阅读停留时间每滑一屏后停留几秒到十几秒不等模拟阅读速度。滑动距离不要每次都滑满屏有些滑动只滑半屏有些滑一屏半制造阅读的“随机性”。间隔时间把间隔宽度拉大平均10秒左右但允许在6到18秒之间浮动。伪随机用JavaScript自带的random()就够function randomInterval(min, max) { return Math.floor(Math.random() * (max - min 1)) min; } // 在主循环里 let waitTime randomInterval(CONFIG.intervalMin, CONFIG.intervalMax); sleep(waitTime);这里要提醒一句所谓“防检测”不是让你去做歪门邪道而是在自动化测试场景下模拟真实用户行为避免给App服务器制造异常压力。正经做自动化测试也好、做个人效率脚本也好模拟真实节奏都是基本功。4.4 阅读进度终止与异常判断自动阅读脚本不能无限跑下去否则你手机屏幕会一直亮着既费电又容易被发现。我通常设定一个总时长目标任务完成后自动回到桌面并锁屏。判断任务是否完成有三条路按时间判断阅读满指定时长后终止。按滑动次数判断比如最多滑动100次达到即停。按界面判断检测到“阅读完成”“任务完成”一类文本时终止。第三种最理想但不同App文案差距大。我更推荐组合使用时间为主次数兜底界面检测作为加速退出条件。let startTime new Date().getTime(); let currentDuration 0; let scrollCount 0; while (currentDuration CONFIG.targetDuration scrollCount CONFIG.maxScrollPerHour) { // 实际滑动逻辑 scrollToNextPage(); scrollCount; let waitTime randomInterval(CONFIG.intervalMin, CONFIG.intervalMax); sleep(waitTime); currentDuration new Date().getTime() - startTime; }这里面还有一个体验细节任务结束后最好把屏幕关闭恢复到执行前的状态。用device.sleep()或者KeyCode(KEYCODE_POWER)都可以MIUI下实测device.sleep()对部分机型无效所以我会加一个备用唤醒/休眠键方案保证在极端情况下也能灭屏。4.5 日志与容错脚本不崩的秘密跑自动阅读脚本最怕的是“弹窗打断”。阅读App里经常弹出广告、青少年模式弹窗、网络错误提示这些弹窗会挡住阅读区域导致后续滑动误触。我的做法是在主循环的每一步都检查一遍是否有弹窗常见的弹窗关键词比如“跳过”“关闭”“我知道了”“以后再说”都要做一次防御性点击。function closePopupIfAny() { let closeTexts [跳过, 关闭, 我知道了, 以后再说, 取消]; for (let i 0; i closeTexts.length; i) { let btn text(closeTexts[i]).findOne(500); if (btn) { btn.click(); sleep(1000); } } }同时我建议把每一步的关键日志写到一个本地文件里方便事后排查function log(msg) { let line [ new Date().toLocaleString() ] msg \n; let file new java.io.File(/sdcard/AutoJsLog/reader.log); files.append(file.getPath(), line); }有了日志脚本哪天出了问题你拿日志一看就知道卡在了哪一步比在那干瞪眼猜原因高效得多。这个习惯我是在踩了无数次坑之后才养成的。5. 稳定性与保活让脚本在MIUI下活得更久脚本写好了权限配好了结果每次锁屏后跑个10分钟就悄无声息地“消失”了。这是MIUI上运行Auto.js最让人崩溃的问题。这一节专门讲保活把我测试过的方案和效果都列出来。5.1 MIUI为什么总爱杀后台MIUI的后台机制有几个特点极低的空闲内存阈值、比较积极的内存回收策略以及一套独立的“应用生命周期管理”。简单说当系统觉得某个应用长时间没有“前台交互”或者它占用的资源比较多就会把它加入清理队列。Auto.js这种长期挂机、又需要模拟操作的应用恰好是清理策略的重点目标。要理解为什么省电策略设置为“无限制”是必要条件可以这么类比MIUI把每个应用看成一个个“房间”默认状态下你离开房间一段时间管理员就会把灯关掉、空调停掉确保省电。而“无限制”相当于你和管理员申请了“VIP室”离开后设备也能持续运行。没有这个VIP资格脚本再怎么写也白搭。5.2 前台服务常驻通知除了系统权限Auto.js自身也提供保活机制——“前台服务”模式。在Auto.js 4.x中可以用thread.start()配合setInterval()做定时任务也可以用engines.execScriptFile()来启动脚本文件。但这些都不如直接调用前台服务可靠。// 启动前台服务保活 typeof requestScreenCapture ! undefined requestScreenCapture(); // 可选需要截屏时使用 let notification new android.app.Notification.Builder(context) .setContentTitle(Auto.js 任务运行中) .setContentText(当前正在执行自动阅读任务) .setSmallIcon(android.R.drawable.ic_popup_reminder) .build(); // 通过context.startForegroundService启动前台服务 let service new android.content.Intent(context, com.stardust.autojs.core.service.OpService); context.startService(service);这段代码里有几个地方要根据自己的Auto.js版本调整不一定所有版本都支持com.stardust.autojs.core.service.OpService。更通用的做法实在Auto.js设置里开启“使用前台服务”选项大部分版本都集成在设置界面里。开启前台服务后通知栏会出现一个常驻通知提示“Auto.js正在运行”之类。这个通知就是保活的“凭证”系统知道这个应用有高优先级的前台任务就不会轻易回收。5.3 定时执行与开机自启自动阅读很多时候不是手动点的而是要定时在每天某个点执行。Auto.js的定时任务用起来不复杂但MIUI下有个最大的坑定时任务依赖Auto.js进程存活。如果Auto.js被系统杀了定时器自然就没了。解决思路是组合拳第一Auto.js设置里开启开机自启动并配合自启动权限第二用系统“动态广播”注册的方式让Auto.js接收BOOT_COMPLETED开机广播后自动拉起脚本第三在Auto.js内部用timers.setInterval()注册一个持久任务每次执行完任务后重新注册下一次任务。// 在Auto.js脚本内注册一个每24小时执行的任务 let lastExecuted files.read(/sdcard/AutoJsLog/last_run.txt) || 0; let now new Date().getTime(); let interval 24 * 60 * 60 * 1000; function mainTask() { // 实际解锁、阅读、退出的完整流程 } if (now - parseInt(lastExecuted) interval) { mainTask(); files.write(/sdcard/AutoJsLog/last_run.txt, String(now)); } // 设置一个8秒后再次执行的定时器用于循环检查 setInterval(() { let t new Date().getTime(); if (t - parseInt(lastExecuted) interval) { mainTask(); files.write(/sdcard/AutoJsLog/last_run.txt, String(t)); } }, 10000);这种方法不需要依赖系统闹钟或第三方调度工具Auto.js自身就能循环驱动。当然它的代价是Auto.js必须常驻内存所以保活方案要配套到位。5.4 异常自恢复与心跳监控常驻进程还有一个不可避免的问题万一某一步异常崩溃了如果没有自恢复机制整个自动化流程就“静默死亡”了。我的做法是给脚本加一个“看门狗”线程通过一个独立的全局标志位监控主任务是否还在运行。let heartbeat 0; function watchdog() { let lastTick 0; setInterval(() { // 如果心跳超过5分钟没有更新说明主任务卡死或崩溃 if (heartbeat - lastTick 5 * 60 * 1000) { log(心跳超时准备恢复); // 重新拉起主任务 mainTask(); lastTick heartbeat; } }, 60000); } watchdog();这种设计思路很朴素但有效不纠结于具体是哪一行代码出了问题而是在更高的层面保证“只要能跑就跑、挂了就重启”。对长时间无人值守的自动化任务来说这个能力比代码写得多优雅更重要。6. 高频问题排查速查表以下是我在MIUI上跑Auto.js过程中实际遇到、以及在技术社区里高频出现的经典问题整理成表格方便你排查。现象常见原因排查步骤解决方案脚本一执行就提示“无障碍服务未开启”无障碍服务被系统自动关闭设置-更多设置-无障碍里确认状态重新开启无障碍服务检查省电策略是否为无限制锁屏后脚本停止执行锁屏显示权限未开应用管理-Auto.js-权限管理-锁屏显示允许锁屏显示省电策略改为无限制定时任务到点不执行Auto.js进程被杀查看任务管理器Auto.js是否在后台开启自启动、无限制省电策略、常驻通知解锁后滑动无反应亮屏后滑动太早锁屏界面未渲染完成看日志中sleep时长亮屏后至少sleep 800ms再滑动图案解锁偶尔失败九宫格坐标被MIUI更换查看logcat控件树信息每次都通过控件bounds计算九宫格位置不写死坐标点击控件执行了但没效果控件被广告弹窗遮挡截图看当前界面是否被弹窗覆盖增加弹窗关闭逻辑后再执行点击脚本运行一段时间后变慢内存泄漏或任务堆积观察Auto.js内存占用定时重启Auto.js进程减少常驻变量自动阅读被App风控滑动间隔太短、节奏太机械检查脚本日志中的滑动时间点用随机间隔不规则滑动距离模拟真人6.1 排错方法论先看日志再改代码遇到问题不要急着改一行代码重新跑先把日志拉出来看。很多时候问题根本不在代码逻辑而在系统权限、网络、或者App界面变化。我自己的排错流程固定四步看日志/sdcard/AutoJsLog/目录下有没有报错信息是哪一步开始不对的。看屏幕截图运行到报错时当前屏幕长什么样是不是被弹窗挡住了或者界面根本没有切换成功。看系统权限去设置里再确认无障碍、省电策略、锁屏显示这几个核心权限有没有被动过。看App版本目标App最近有没有自动更新更新后页面结构变了脚本里的text()或者id()就可能失效了。这四步走完绝大多数问题都能定位。真正需要改代码的情况反而不多。6.2 我遇到的几个“反常识”案例有几个案例特别值得多说一嘴因为它们不看日志根本想不通。第一个是“无障碍服务自动关闭”。我排查了很久最后发现是某个“手机管家”的清理功能在“扫描垃圾文件”时会把无障碍服务权限清掉。这不是Auto.js独有的问题任何使用无障碍服务的应用都会中招。解决方案是把Auto.js加入手机管家的“不清理列表”中而不是简单改一下权限就完事。第二个是“解锁后当前Activity名称为空”。MiUI在某些情况下锁屏解锁完成但Activity切换还没结束currentActivity()返回的是空字符串或者上一个App的名称。这种瞬时状态处理不当会导致脚本以为还在锁屏状态疯狂做解锁动作反而把锁屏又触发出来了。解决方法是检测到Activity为空时多等1-2秒再重新检测不要立刻下结论。第三个是“定时任务执行时屏幕还是暗的”。靠设备wakeUpIfNeeded()唤醒屏幕其实是一个比较“粗暴”的操作部分MIUI版本上必须同时满足“有电源键权限”和“当前非锁屏”的条件才有效。我的替代方案是先用device.wakeUpIfNeeded()尝试失败的话再模拟一次音量键按下这在MIUI上通常能亮屏再不行就最后用电源键。6.3 合规使用和其他机型参考最后再啰嗦一句合规问题。Auto.js是一个强大的自动化工具用好了是效率神器用歪了就是给自己找麻烦。阅读类App的积分规则、平台协议里大多明确禁止自动化操作作为技术学习者我建议把脚本重点放在自己可控的个人效率场景定时备份、自动打卡提醒、自动化测试、辅助操作等。不要去刷平台收益、不要批量注册、不要给他人提供“代刷”服务法律和平台的风控都不是吃素的。另外这篇文章虽然以MIUI系统为主线但大部分原理在原生安卓、ColorOS、OriginOS等系统上也能复用只是权限设置路径会有所不同。具体到你的机型原则是一致的先保证无障碍服务和省电策略再处理锁屏和后台弹窗然后跑通一个最小的解锁滑动测试最后再叠加业务逻辑。我的做法是始终在脚本开头打印一个版本号和权限自检清单每次换新手机第一步就是跑这个自检脚本把所有权限一键检查一遍比自己凭记忆去设置里翻快得多function checkPermissions() { let issues []; if (!auto.service) { issues.push(无障碍服务未开启); } // 这里可以通过accessibility service检查更多系统权限状态 return issues; }最后的实际操作体会折腾Auto.js和MIUI适配这么长时间我最深的体会是这类自动化任务代码只占三成功夫七成功夫都在系统配合和异常处理上。把权限配置当成项目的一部分去对待把日志当成必需品而不是可选项脚本的稳定性才会有质的提升。如果你刚准备入坑我的建议是先不要急着写自动阅读这种复杂流程先从解锁手机开始把每一步的返回值和状态都打印出来确认每个环节都稳定之后再叠加业务动作。我见过太多人上来就抄一个完整脚本跑不通就开始改最后越改越乱其实只要把“解锁”这一关做扎实了后续的阅读、退出都是简单叠加。目前我手上的自动化任务已经稳定跑了几百小时MIUI版本跨了好几个大版本中途只因为系统更新改过一次Activity名称。这套思路和代码框架被你拿过去之后大概率也需要微调但核心原则——控件优先、日志必备、权限拉满、保活挂住——是通用的。照着这几个方向去调MIUI这块骨头就啃下来一大半了。
之Pod生命周期(下))
