最近好几个群友私信我说照网上的Auto.js脚本改一改拿去跑快手极速版自动刷视频结果要么闪退要么卡在开屏页不动要么刷了半天一看收益没变化。我每次回消息都先从“你是不是版本没对齐”开始问起十个里有九个都中招。这个问题的根源其实不是Auto.js不好用而是绝大多数脚本把“某个手机、某个App版本、某个时间点能跑”当成了“所有环境都能跑”的默认条件。这篇把我自己维护快手极速版刷视频脚本期间踩过的坑、反复推翻的逻辑完整梳理一遍也把这版3.0脚本的核心实现讲清楚。建议别直接拉到代码区前两部分看完再动手后面能省掉很多排查时间。1. 为什么很多人拿到的脚本“一跑就废”版本与权限的错位1.1 那些一夜之间失效的脚本大多不是代码问题我自己最早也是从别人的开源脚本改起的那时候遇到的问题很典型昨天还跑得好好的今天打开快手极速版脚本像是瞎了一样控件抓不到、点击没反应、日志也看不出异常。后来才明白App每隔一两周就会发版发版时研发顺手改了一堆控件ID和布局层级这是常态。Auto.js脚本依赖的是界面控件树不是截图识别所以只要App把组件ID换掉、把某个TextView改成自定义View你原来写死的那套find()自然全部失效。另一个高频翻车点是无障碍服务。Auto.js绝大多数能力依赖无障碍服务但国产手机在内存紧张、后台清理、系统更新之后经常把无障碍服务自动关掉。你感觉脚本“没反应”进去设置一看无障碍开关早就被系统偷偷关了。这不是代码问题是环境问题。脚本启动时如果没做无障碍服务的自检和提示用户根本不知道问题出在这。还有一类问题是“权限没给全”。Auto.js至少要无障碍服务、悬浮窗、后台弹出界面这三样权限缺了悬浮窗或者后台弹出界面任务切到后台再回来就可能直接卡死。很多一键搬运的脚本根本不提这些用户装上就开始跑等于让一个没有眼睛的人去画画。1.2 环境准备Auto.js版本选择和三个关键权限先说Auto.js的版本选择。目前主流可用的其实是两条线一条是早期开源的Auto.js 4.x优点是免费、社区资料多、用的人多缺点是维护停更在Android 10以上部分机型无障碍事件会延迟另一条是Auto.js Pro或社区维护的变体版本兼容性和后台保活更强但要么收费要么签名不太统一安装有门槛。我日常调试用的是4.x系列的最后一个稳定分支因为群里大部分人的手机还是Android 9到13之间4.x在这块的兼容性够用。如果你手机是Android 14以上建议别折腾开源版了直接上支持新系统的付费版省下的时间比省下的几十块钱值。权限方面列一个自查清单按顺序搞无障碍服务设置-辅助功能-Auto.js开启并保持开启。这一步是自动化的地基App界面里所有控件查找、点击、滑动都靠它。悬浮窗Auto.js 的日志和部分调试功能需要悬浮窗权限。没有它脚本运行时报错你根本看不见只能在通知栏翻日志。后台弹出界面 / 后台运行权限不同品牌命名不一样华为叫“后台弹出界面”小米叫“后台弹出权限”vivo叫“后台启动”反正都要允许。否则脚本在切换App的时候后台拉起快手极速版会被系统拦截屏幕上会短暂闪一下再回来流程就断了。另外在手机管家里把Auto.js加入“电池优化白名单”和“自启动白名单”允许它在后台一直活着。这一项不做脚本跑着跑着被系统杀掉比脚本本身崩溃还要频繁。还有一个容易被忽略但很重要的东西不要通过“从电脑安装ADB授权”之类的方式给Auto.js系统权限。很多人图省事给Auto.js升成了系统应用结果一旦系统版本升级授权失效脚本和系统之间就出现各种诡异问题。非root环境下老老实实用普通方式安装权限虽然多点但稳定得多。2. 快手极速版新版界面的“脾气”脚本设计必须顺着App的习惯来2.1 控件树与Activity为什么同一段代码上午能跑下午就报错快手极速版和快手大版的界面结构不太一样。极速版更轻量但同样大量使用自定义绘制组件。你在Auto.js的“布局分析”里看会发现很多区域的控件类型并不是标准Button或TextView而是Android自带的View子类。这就意味着用text()和id()去找某些元素时会扑空因为这些控件根本不在无障碍节点里输出文本或者ID每次启动都会变。第二个坑是Activity跳转。快手极速版从冷启动到首页会经历至少两三个Activity切换比如启动页、开屏广告页、主界面。如果脚本启动App之后马上就去找“视频卡片”大概率会扑空因为此时界面还停在开屏页。正确做法是先等待主界面特征控件出现再执行后续动作。很多半吊子脚本为了省事sleep个固定秒数就往下走这种写法在网速波动、开屏广告时长变化时必挂。第三个坑是“短视频信息流”本质是RecyclerView它里面的子项在滑动过程中会被回收和复用。也就是说你刚拿到一个视频节点的引用一滑就失效了。正确操作是每个循环都重新查找当前页面里的视频节点而不是把节点缓存起来反复用。这个点我后面3.0脚本里也专门做了处理。2.2 滑动方式的三种写法与取舍刷视频这个场景里最核心的动作是“切换到下一个视频”。在Auto.js里实现方式大体有三种各有利弊坐标固定滑动直接swipe(deviceWidth/2, deviceHeight0.7, deviceWidth/2, deviceHeight0.3, duration)。优点是简单粗暴不受控件变化影响缺点是如果屏幕分辨率/全面屏手势区域不同上滑距离和触发位置会有偏差有时候会误触评论区或者不触发翻页。通过控件查找滑动先找到当前视频卡片节点再对这个节点做bounds().center()取中点然后从这个中点滑到下方。优点是定位准缺点是控件树变化时查找逻辑要跟着改。通过RecyclerView滑动用“滚动到下一个子项”的语义让列表自身执行滑动更像用户手势但快手极速版有些版本禁止了这种方式或者触发不了惰性加载。我的选择是第一种为主、第二种辅助默认用屏幕坐标滑动但如果检测到当前界面存在明显的“视频描述区域”控件就按它的坐标来计算滑动起点这样既稳定又不容易误触。有人担心固定坐标在全面屏上会偏实测下来只要把起点设置在屏幕高度60%~70%之间、终点在20%~30%之间绝大多数机型都能正常翻页。你要做的只是在自己手机上微调一次参数。2.3 脚本不是“越快越好”短视频播放有它自己的节奏刷视频自动化的核心矛盾是既要保证每次播放被系统计为“有效播放”又要避免操作频率像机器。快手极速版的收益逻辑对播放时长、播放完整性有判断滑太快不但可能不计入还可能触发风控。这不是玄学任何内容平台都有反作弊策略固定间隔、匀速滑动这种特征是最容易被识别的。我自己在3.0里把每次视频的停留时间设置为14到35秒之间的随机数并且不是简单随机还会参考视频是否已加载完成如果检测到“加载中”的标识就多等两三秒再开始计时。这个细节看似简单却是刷视频脚本能不能长期稳定跑的分水岭。有的脚本追求“分钟级刷量”跑半小时就被限制然后反过来骂Auto.js不行其实脚本本身的策略就有问题。3. 最新3.0版脚本的核心实现拆解3.1 整体流程把“刷视频”拆成一个状态机写脚本之前我习惯先把整个流程画成状态序列。快手极速版自动刷视频这个任务无非是这几个状态启动App、等待首页加载、确认当前不是开屏广告、播放视频并计时、滑动到下一个视频、检测是否卡住并自恢复。每个状态之间用条件判断来转移而不是靠sleep硬等这是3.0版和早期版本最大的区别。状态机的设计逻辑如下启动状态拉起快手极速版等待主界面出现。判断依据是用textContains(关注)或descContains(发现)这类稳定文案而不是等固定秒数。开屏处理状态如果检测到“跳过”按钮立即点击。如果没有就等它自动倒计时结束。播放状态检测到视频区域控件后记录当前时间进入随机等待。等待期间每隔几秒检查一次界面是否还在如果界面被弹窗打断触发关闭逻辑。翻页状态执行滑动等待下一帧界面稳定再次进入播放状态。异常状态如果某个环节超过60秒没有动作进入恢复流程——先按返回键回到主界面再重新进入播放流程。用状态机的好处是每一段逻辑都可以独立测试。出问题时看日志直接知道是卡在哪个状态、当时界面长什么样。3.2 核心代码逐段讲从入口到滑动循环下面这版代码是3.0脚本去掉个人配置项之后的精简版。完整脚本我放在了自己的Git仓库里这里把最关键的部分拿出来逐段说。ui; auto.waitFor(); const APP_PACKAGE com.kuaishou.nebula; const MAIN_ACTIVITY com.yxcorp.gifshow.HomeActivity; const MIN_PLAY_TIME 14; const MAX_PLAY_TIME 35; // 打开快手极速版并等待主界面 function launchApp() { app.launch(APP_PACKAGE); waitForActivity(MAIN_ACTIVITY, 15000); sleep(3000); } // 判断当前是否在主界面的视频流 function isVideoPage() { let hasFind textContains(发现).findOnce(); let hasFollow textContains(关注).findOnce(); let hasRecommend textContains(推荐).findOnce(); return hasFind || hasFollow || hasRecommend; } // 随机延迟 function randomDelay(min, max) { let delay Math.floor(Math.random() * (max - min)) min; sleep(delay * 1000); } // 点击开屏广告的跳过按钮 function skipAdIfNeeded() { let skipBtn textContains(跳过).findOnce(); if (skipBtn) { skipBtn.click(); sleep(1500); } } // 滑到下一个视频 function swipeToNext() { let w device.width; let h device.height; let startX w / 2; let startY h * 0.68; let endY h * 0.25; swipe(startX, startY, startX, endY, 500); sleep(2000); } function mainLoop() { while (true) { if (!isVideoPage()) { launchApp(); } skipAdIfNeeded(); randomDelay(MIN_PLAY_TIME, MAX_PLAY_TIME); swipeToNext(); } } launchApp(); mainLoop();这里有几个点值得展开说。auto.waitFor()是启动时请求无障碍服务如果没开启脚本会卡在这一行并弹提示比后续到处报错好处理得多。waitForActivity的作用是等MainActivity真正出现在前台防止App还在启动页就开始找控件。isVideoPage判断的是主界面是否就绪我用的三个文案发现、关注、推荐在极速版首页基本固定比找视频卡片ID稳。只要这个条件不成立就说明界面停留在了不该停留的地方此时重新走启动流程是一种自愈手段。swipeToNext里的起点坐标我特意把起点设在屏幕68%的位置而不是正中间因为短视频App的手势操作区集中在中下区域从下往上滑更符合真实操作也能减少误触底部导航栏的可能。终点设在25%是为了保证RecyclerView能识别出是一次有效的向上翻页动作滑得太短有时候只会轻微移动列表不会切视频。3.3 “最新3.0”到底更新了什么版本迭代记录很多教程喜欢把脚本名字加上“最新”其实里面内容跟一年前没区别。我这里实打实列出3.0和之前版本的变化原来的固定等待8秒变成了播放持续时间随机化范围14到35秒。原来用id()定位视频区域3.0改为textContains组合判断 坐标滑动不再依赖会变的控件ID。增加了看门狗自恢复逻辑单次循环最长不超过60秒超过就回到首页重新来。增加了开屏广告跳过逻辑不再因为开屏页停留过久导致循环中断。日志输出增加了当前状态标记方便排查卡在哪个环节。这些变化不是为了变化而变化每一个都对应一次线上翻车记录。id定位失效、固定间隔被识别、开屏广告阻断流程这三类问题占了脚本反馈量的大半。如果你手上的脚本还在用以前那套写法建议至少把随机延迟和状态判断这两块补上。4. 防误触、防卡死与随机化处理的硬经验4.1 为什么固定间隔的脚本活不过三天刚开始写脚本的人最爱用固定sleep比如每一轮刷25秒循环500次。这种写法在实验室环境里很漂亮一上真机就开始暴露问题网络慢一点25秒还没播放完就滑走了平台判定无效网络快一点27秒才加载完你又多等了8秒效率低。但这还是小事真正致命的是固定节奏容易被风控识别。写自动化脚本这么多年我总结出的经验是所有周期性操作里变量越少越可疑随机性不一定要大但一定要存在。我现在的策略是对三个维度做随机播放时长随机、滑动间隔随机、滑动耗时随机。时长在14到35秒之间浮动滑动间隔在2到5秒之间浮动滑动耗时在400到700毫秒之间浮动。这三个参数叠加起来理论上几天之内不会出现两次完全相同的操作序列。说实话我不认为有人能完全摸清平台的风控规则但让操作序列接近真人行为是成本最低、效果相对可靠的做法。4.2 卡死自恢复看门狗式检测与重启逻辑长时间运行的脚本最大的敌人不是平台风控而是自己的网络环境和系统状态。Wi-Fi波动、App偶发崩溃、系统弹窗都会让脚本停在一个空界面上干等。没有看门狗的话你早上醒来看到的是脚本运行了6小时实际只刷了20分钟剩下的时间全在空转。我的做法是维护一个lastActionTime时间戳每个主循环动作结束时更新它。另起一个定时器每15秒检查一次如果时间戳超过60秒没有更新就认为脚本卡住了此时执行恢复流程先按返回键尝试回到主界面如果连续3次返回都没检测到首页控件就强制杀掉App进程重新启动。这套逻辑在3.0脚本里是默认开启的代码如下let lastActionTime Date.now(); setInterval(() { let idleTime (Date.now() - lastActionTime) / 1000; if (idleTime 60) { log(检测到卡顿尝试恢复...); backToHome(); } }, 15000); function backToHome() { for (let i 0; i 3; i) { back(); sleep(2000); if (isVideoPage()) { lastActionTime Date.now(); return; } } app.kill(APP_PACKAGE); launchApp(); }注意主循环里每次关键动作之后都要及时更新lastActionTime否则看门狗会误判。还有一个细节是这套看门狗也负责处理无网络时的长时间加载因为这种情况下界面虽然还在但视频始终不加载如果不做超时控制脚本就会一直停在这一条视频上。4.3 被系统“优化”掉之后的处理方案国产手机的后台管理策略非常激进Auto.js运行过程中随时可能被系统杀掉。表现就是脚本跑着跑着突然没了悬浮窗日志消失了。这个问题在3.0脚本里没有银弹只能尽量降低被杀概率。除了前面说的电池白名单和自启动白名单还可以把Auto.js的通知权限打开部分系统对“有前台通知的应用”杀得更轻。另一个备用方案是把Auto.js做成前台服务。Auto.js 4.x支持thread和前台通知但配置起来相对麻烦而且每个机型表现不一致。我的经验是如果脚本每天要跑两小时以上优先考虑在系统设置里把Auto.js锁定在最近任务列表多任务卡片下拉加锁这个动作在很多机型上比白名单设置更管用。如果还是被杀可以把脚本改成定时重启式通过MacroDroid这类工具每小时拉起一次Auto.js脚本反正脚本自己有断点续跑能力从首页状态重新开始并不损失什么。5. 高频翻车点排查链路实录从现象到根因5.1 现象一脚本一直卡在“正在加载”日志里没有任何报错排查链路先看界面是不是停在开屏广告页。快手极速版冷启动时开屏广告有时长达5秒以上如果脚本在启动后3秒内就开始找视频控件必然扑空。切到Auto.js悬浮窗日志看是否有“isVideoPage false重新启动”的输出。如果循环一直在重启App说明主页判断条件不成立界面没进到主界面。手动打开快手极速版确认当前版本里是否有“发现”“关注”“推荐”这几个文案。如果新版改成了“精选”“热榜”isVideoPage就会失效需要同步更新。检查网络。Wi-Fi信号弱或DNS异常时快手极速版会一直loading这种情况脚本本身没问题是运行环境问题。我遇到最离奇的一次是某台手机时间不准导致App的请求全部异常连首页都加载不出来。调了系统时间之后脚本立刻恢复正常。这类环境问题比脚本问题更难察觉排查时要想到。5.2 现象二脚本跑了几屏之后不再滑动但进程还活着排查链路看此刻是不是弹出了“青少年模式”弹窗或“隐私协议”弹窗。这类弹窗会阻断后续所有控件操作如果跳过弹窗的逻辑没写好脚本就卡在这一屏。在代码里给“跳过按钮”的处理增加优先级。弹窗上的“我知道了”“同意”“跳过”这些按钮不一定用标准的text属性注意用desc或className去匹配。检查是否触发了“活动页”或“直播预览页”。快手极速版偶尔会在滑动过程中跳转进直播页面或活动H5页这种页面没有视频流特征控件脚本会认为当前不是视频页而走去重启流程。但重启流程如果写得不对也会陷入“重启—闪回—再重启”的死循环。解决方案是在主循环中增加页面类型识别如果检测到当前Activity不是MAIN_ACTIVITY先执行一次返回而不是直接杀进程。5.3 现象三控件明明在屏幕上Auto.js却find不到这个坑很多人第一次遇到都很崩溃。用“布局分析”看屏幕明明有一个TextView文本清清楚楚find却返回null。导致这种情况的原因有几个控件外层使用了自定义绘制或者文本不是通过Android标准的TextView展示的而是VideoSubtitle这类自绘组件。无障碍服务缓存未刷新。整个界面已经切换了内容但无障碍事件还没来得及生成马上find就会失败。解决办法是在find之前先sleep(500)或者执行一次轻量滑动触发节点刷新。App有反自动化检测故意把重要控件设置为importantForAccessibility false这种情况下find永远找不到。应对办法是不再依赖控件树改用坐标滑动这条纯手势路径。5.4 一个排查速查表现象大概率根因优先尝试的解法启动后没反应无障碍服务被系统关闭检查辅助功能里Auto.js是否开启跑一会就停弹窗/活动页/直播页拦截增加返回和弹窗关闭逻辑一直在加载网络或开屏广告未处理增加状态判断等主界面出现找不到控件控件importantForAccessibilityfalse改为坐标滑动方案杀后台之后消失系统回收Auto.js进程多任务卡片加锁电池白名单金币/收益不涨滑太快或固定间隔随机化播放时长和滑动节奏6. 脚本之外边界意识与这套技术的正经用法写到这里必须要说一句。Auto.js自动化脚本的本质是辅助你完成重复操作它的价值在于节省时间而不在于“薅”。任何平台都有自己的规则拿脚本去做大规模批量注册、恶意刷量、破坏正常生态的事情不仅账号保不住理论上还可能涉及法律风险。我自己用这套脚本主要用途是测试信号、验证无障碍自动化流程、研究Android界面交互逻辑顺带在可控范围内跑一跑短视频任务。把心态放在“技术研究”上你会发现即便刷视频收益归零这套脚本里那套控件查找、状态机、看门狗的思路迁移到其他自动化场景里也一样好用。比如你用Auto.js可以做微信定时提醒、淘宝每日签到、钉钉自动打卡、游戏日常任务甚至是APP UI自动化回归测试。这些用途比单纯刷视频更有长期价值也不会让你整天担心账号被封。我之前踩过最惨的一次坑是在脚本里加了非常激进的多线程并发同时开了五个Auto.js实例跑不同任务结果手机直接卡死重启所有无障碍授权全部丢失还得重新配一遍。后来我给自己定了一条规矩一个脚本进程只干一件事脚本之间用文件锁或时间窗错峰运行。这个习惯一直保持到现在跑长任务再也没有出现过手机无响应的情况。最后再分享一个小技巧不管是3.0脚本还是你自己改的版本一定在开始和结束时各写一条带时间戳的日志。脚本跑了多久、卡在哪里、重启过几次这些数据是优化下一版的最重要依据。没有日志的长时间运行脚本跟闭着眼睛开车没区别。