先说个真实场景我手机上装了某短视频极速版每天要做签到和刷视频任务手得一遍遍地左滑滑到拇指发酸。后来我寻思这滑动动作完全可以用脚本代替。于是就有了标题里这个功能——“循环3秒左滑-支持屏幕上下分屏”。也就是每隔3秒自动做一次左滑手势而且能适配安卓分屏模式你在上屏刷任务下屏跟人聊天互不干扰。这个功能听起来不大真正动手做完才发现里面全是细节坐标怎么取、分屏边界怎么动态识别、循环定时怎么不漂移、滑动幅度怎么才不会被系统判定成异常操作。这篇文章就把我实际跑通的方案完整拆开给有同样需求的朋友做个参考。1. 这个需求是从什么场景冒出来的3秒左滑到底在刷什么先说清楚我为什么要做这个玩意儿免得你看完觉得是个花架子玩具。短视频、购物返利、资讯阅读这类App都有通过浏览内容换取权益的机制操作基本都是左右滑动切换下一条。人工刷一会儿就烦尤其夜里躺着刷手指累不说还容易刷着刷着睡过去。自动化滑动就有了刚需挂机让它自己滑设备放一边充电等回来一看权益已经攒了不少。那为什么偏偏是“3秒”和“左滑”这两个参数3秒是我试出来的一个比较合理的间隔。太快了比如1秒一滑系统端很容易识别出这是机器操作轻则警告重则封权或者限制任务收益太慢了挂机效率又低刷不了几条。3秒比较接近一个正常人刷视频的节奏看一会儿觉得没意思滑走。我用过2秒和5秒分别试过最后固定到3秒。左滑就更直观了绝大多数信息流App里左滑的语义是“下一个”右滑通常是“上一个”或者呼出菜单。用LSBLeast Significant Bit最低有效位这种类比不太贴切但你可以理解为我们做的是“单向翻页”脚本只为“下一个”设计不需要“返回”。分屏需求则来自我另一个习惯一边刷内容攒权益一边和同事聊天、看文档。安卓的上下分屏模式正好可以一屏两用。但问题来了普通滑动脚本通常把屏幕视作一个整体从中间划过去分屏模式下这一划可能连下方窗口一起误触。你要么全屏挂脚本要么就得给脚本加一个“分屏感知”能力让它只在上屏或者只在下屏的区域内滑动。这个能力说白了就是要获取到分屏后每个窗口的边界坐标然后在我们计算的滑动路径里把坐标限制在目标窗口内。所以标题里的功能本质是一个带“区域识别”的定时滑动器。不是那种无脑从右往左划的简单脚本而是会看屏幕布局、按区域执行的脚本。2. 前置定义分屏模式下屏幕坐标系到底怎么算在写任何代码之前先得把安卓的坐标系搞清楚。手机屏幕的坐标系原点在左上角x轴向右增大y轴向下增大。大部分设备的逻辑分辨率是1080x2400有的设备是1440x3200还有折叠屏这种特殊规格但坐标系规则都一样。全屏模式下一个从左边缘滑到右边缘的手势起点差不多在(90, y)终点在(990, y)其中y是随便一个手指高度。这个坐标用绝对像素写当然可以但换一台手机就废了。因为每台手机分辨率不同甚至同一台手机在分屏状态下每个窗口的宽度也不等于全屏宽度。更稳妥的做法是使用百分比坐标也就是相对坐标。比如“横向90%处”、“竖向50%处”这些百分比再乘以屏幕宽高就得到了绝对像素。脚本跑起来的时候先获取设备实际宽高再动态换算这样换设备基本不用改代码。分屏模式下屏幕被上下分成两个区域上屏和下屏。中间是拖动条。上屏底部到下屏顶部之间的那一段通常是系统的分屏把手区域高度大约几十像素到一百像素不等。如果你直接用“屏幕一半”作为分界线滑动路径可能正好压在当前窗口的边缘上或者因为分割线位置不同而跑到另一个窗口里去。以最常见的上下分屏为例假设屏幕总高度是2400分屏分割线在屏幕40%处即上屏占比较高。上屏区域的y范围大概是0到960下屏区域的y范围大概是从1000到2400。中间的40像素是被系统占用的分屏把手。如果你要滑动上屏手指的y坐标就应该取在500附近而不是屏幕正中1200。同样滑动下屏时y坐标应该取在1700附近。实际开发中我们不能假设分割线一定在某个固定百分比。用户拖动分屏分割线是随意的可能上屏高一些也可能下屏高一些。这就需要脚本实时解析窗口布局信息。方案有二一是使用无障碍服务读取当前各窗口的bounds边界二是通过ADB的dumpsys window命令查看窗口帧。这两种方式拿到的是系统当前真实窗口区域动态跟随分割线变化。3. 主方案用Auto.js写一个分屏友好的左滑脚本手机端我最常用的自动化环境是Auto.js它把安卓无障碍服务和JavaScript封装成了一套脚本接口写滑动、点击、读取界面都非常方便而且不需要root。如果你手头还没有环境先去官方渠道下载一个Auto.js应用再在系统设置里开启它的无障碍服务权限这个权限是所有自动化操作的基础。3.1 环境准备与要开的权限除了无障碍服务我建议把悬浮窗权限顺手开了。悬浮窗可以用来显示脚本运行状态或者停止按钮挂机的时候很有用。存储权限也要给因为脚本文件本身存在/SD卡/脚本目录下。权限清单如下权限用途不开会怎样无障碍服务模拟点击、滑动、读取界面控件脚本无法操作屏幕悬浮窗显示运行状态悬浮按钮只能在Auto.js内部停止挂机时不方便存储权限读写脚本文件、日志脚本无法保存文件这里面无障碍服务是核心。有的系统对无障碍服务有管控长时间运行会把它回收掉脚本就假死了。我后面会专门讲这个问题怎么处理。3.2 拿分屏窗口边界的关键代码Auto.js里有一个非常实用的方法bounds()它返回控件在屏幕上的矩形区域left, top, right, bottom。要拿到当前界面上各窗口的边界可以遍历应用窗口的根节点或者直接读取当前激活窗口的信息。不过在Auto.js的JavaScript环境下直接用控件遍历拿分屏边界有时候拿不到很干净的窗口节点因为不同的App对无障碍暴露的程度不一样。更通用可靠的办法是借助安卓的系统接口Auto.js里面可以通过context调用WindowManager来获取窗口信息。实测下来有一种简单粗暴但有效的方法读取dumpsys window windows的输出再解析其中mFrame的值。Auto.js内置了shell()方法可以直接执行系统命令并拿到返回结果。下面这个函数是我脚本里实际在用的作用是返回当前屏幕可用的全屏宽高function getScreenSize() { importClass(android.view.WindowManager); importClass(android.util.DisplayMetrics); let dm new DisplayMetrics(); let wm context.getSystemService(context.WINDOW_SERVICE); wm.getDefaultDisplay().getRealMetrics(dm); return { width: dm.widthPixels, height: dm.heightPixels }; }然后用shell命令去解析窗口区域。执行下面的命令dumpsys window windows | grep -E mFrame|mCurrentFocus返回的文本里会有类似这样的内容Window #4 Window{...} mFrame[0,0][1080,2400] Window #5 Window{...} mFrame[0,0][1080,1010] Window #6 Window{...} mFrame[0,1050][1080,2400]其中mFrame[左,上][右,下]表示窗口的矩形边界。当你处于分屏状态时你会看到至少有两个应用窗口一个上屏窗口的bottom大概在分割线上方另一个下屏窗口的top在分割线下方几十像素处。我们只要取到目标App对应的窗口边界就可以算出滑动区域。Auto.js脚本里解析这段文本也不难正则搞定function getWindowFrames() { let result shell(dumpsys window windows | grep -E \mFrame|mCurrentFocus\, true); let lines result.result.split(\n); let frames []; for (let line of lines) { let match line.match(/mFrame\[(-?\d),(-?\d)\]\[(-?\d),(-?\d)\]/); if (match) { frames.push({ left: parseInt(match[1]), top: parseInt(match[2]), right: parseInt(match[3]), bottom: parseInt(match[4]) }); } } return frames; }3.3 只在上屏或下屏滑动的核心逻辑拿到分屏窗口边界后滑动路径就好控制了。假设你现在要在“上屏”执行左滑// 目标窗口取所有window frames里 top最小 且 bottom小于屏幕高度一半加偏差 的那个 function findUpperScreenFrame(frames, screenHeight) { let candidates frames.filter(f f.top 0 f.bottom screenHeight * 0.6); candidates.sort((a, b) a.top - b.top); return candidates[0]; // 最靠上的窗口 }找到上屏窗口后计算滑动起止点。左滑的意思是从窗口右侧滑向左侧手指y坐标取窗口垂直方向的中点偏上一点比如三分之一处function swipeUpperScreenLeft() { let size getScreenSize(); let frame findUpperScreenFrame(getWindowFrames(), size.height); if (!frame) return false; // 起点窗口右侧内侧90%位置 let startX frame.left (frame.right - frame.left) * 0.9; // 终点窗口左侧内侧10%位置 let endX frame.left (frame.right - frame.left) * 0.1; let y frame.top (frame.bottom - frame.top) * 0.3; swipe(startX, y, endX, y, 300); // 300ms滑动手势 return true; }这里有个细节为什么起点和终点不直接取窗口最左最右边缘。因为太贴边会被系统识别成边缘手势某些系统会触发返回手势或者侧边栏误触率特别高。我测试下来起点取右边界内侧10%终点取左边界内侧10%滑动距离已经足够触发App内部的页面切换又不会撞到系统边缘手势的判定区域。3.4 3秒循环怎么写得既稳定又可控循环本身不复杂复杂的是不能死循环卡死脚本。Auto.js里面最直白的方式是while (true) { let success swipeUpperScreenLeft(); if (!success) { toast(没有找到上屏窗口可能没有分屏); break; } sleep(3000); }但这样写有个问题sleep(3000)期间脚本什么都干不了如果中途你想改间隔、想停止按键都不响应。更好的做法是用时间戳控制周期let interval 3000; let lastTime 0; let running true; setInterval(() { if (!running) return; let now Date.now(); if (now - lastTime interval) { lastTime now; swipeUpperScreenLeft(); } }, 500);用一个500ms的定时器轮询实际滑动间隔还是3秒但主线程没有被sleep卡住按键监听和悬浮窗更新都还活着。这里把running变量暴露出来就可以做成一个开关。4. 备选方案在电脑上用ADBPython驱动手机完成同样效果Auto.js不是所有人都能用有些设备安装环境麻烦或者你只是想快速验证一下效果不想在手机上常驻一个自动化App。这时候ADB方案更适合。ADBAndroid Debug Bridge是安卓官方调试工具只要手机开了USB调试连接电脑后就能直接模拟触摸屏操作完全不需要手机端装任何东西。4.1 最基础的左滑命令ADB模拟滑动的核心命令是input swipeadb shell input swipe 900 500 100 500 300参数含义依次是起点x、起点y、终点x、终点y、滑动耗时毫秒。现在要给这个命令加上“分屏判断”和“3秒循环”用Python写起来非常顺手。先检测设备是否连接adb devices然后写一个最简单的循环左滑import subprocess import time while True: subprocess.run([adb, shell, input, swipe, 900, 400, 100, 400, 300]) time.sleep(3)这个脚本已经能用了但它没区分全屏和分屏滑动y坐标是写死的400。如果分屏分割线不在屏幕中间这个400可能落在非目标窗口上。所以核心还是要动态判断分屏边界。4.2 用Python动态解析分屏边界Windows、macOS、Linux电脑上都可以执行adb shell dumpsys window windows命令然后解析mFrame字段。Python里直接用正则import re import subprocess def get_window_frames(): output subprocess.check_output( [adb, shell, dumpsys, window, windows], textTrue ) frames [] for match in re.finditer(rmFrame\[(-?\d),(-?\d)\]\[(-?\d),(-?\d)\], output): left, top, right, bottom map(int, match.groups()) frames.append((left, top, right, bottom)) return frames判断当前是否分屏就用一个简单规则如果存在一个窗口的bottom明显小于屏幕高度并且另一个窗口的top在同一个位置附近说明是上下分屏。再进一步要判断上屏还是下屏看你想操作的App在前台还是后台可以配合dumpsys window windows | grep mCurrentFocus找到当前焦点窗口。不过更省事的方法是直接指定上屏操作。实际操作中ADB方案最大的优势是稳定。它不依赖无障碍服务不会被系统回收挂机一整天都不会假死。劣势就是必须连着电脑用无线ADB的话对网络环境还是有要求。如果你有旧手机专门用来挂机插在电脑旁边跑Python脚本这个方案非常省心。5. 实测中的翻车现场与排查链路再好的脚本跑起来都会遇到各种预想不到的问题。这部分是我最想分享的因为每一个坑背后都对应一个真实的排查过程。直接给答案没意思我把排查链路写出来方便你以后自己遇到同类问题时能顺着思路找到症结。5.1 分屏状态下滑动路径“穿屏”了第一次跑分屏脚本的时候我遇到的现象是明明滑动的是上屏区域结果下屏的列表也跟着翻页了。当时我第一反应是坐标算错了但反复打印日志坐标值是对的没有超出上屏边界。后来我把滑动速度放慢到1000ms仔细观察才能看到原因手指按下之后滑动的轨迹并不是完全水平的。Auto.js的swipe方法是模拟从A点滑到B点的运动轨迹但在某些设备上触摸事件的插值路径会比较“漂”尤其当滑动距离较长时中间某个时刻的y坐标可能偏离起始点。如果起始点的y坐标选得太靠近分屏分割线那么漂移过程中就会滑进下屏区域触发下屏的触摸事件。排查到这一步修复方案就明确了把滑动的y坐标尽量往目标窗口中心靠拢。比如上屏窗口高度只有1000之前取y400改成y300滑动的垂直分量波动区间控制在window中间区域穿屏概率大大降低。另外滑动耗时也不要太短300到500ms之间比较合适太短的话系统对触摸轨迹的采样点不够更容易产生跳跃。5.2 循环计时出现漂移越划越慢另一个问题出现在长时间挂机时。我最初用while sleep(3000)跑了两个小时之后发现实际滑动间隔变成了4秒多越到后面越慢。原因倒不是手机变卡而是sleep和界面响应互相影响脚本执行滑动时如果当前界面有卡顿滑动本身要花更长时间叠加在sleep(3000)上周期就被拉长了。这就是我在前面采用setInterval 时间戳方案的原因。时间戳方案不管滑动本身耗时多少每次触发前都检查一下距上次执行是否已满3秒用绝对时间校准不会累计漂移。我实测跑了一天一夜间隔误差控制在几十毫秒以内肉眼完全感知不到。5.3 无障碍服务被系统回收脚本假死这是Auto.js方案最烦人的问题。手机厂商会对无障碍服务做省电限制长时间后台运行容易被系统杀掉或者停止服务。表现就是脚本还在记录日志但屏幕没有任何动作。排查时我先看日志发现输出停在某个时间点就不动了再检查无障碍服务设置发现服务已经被强制关闭。处理办法有几种一是把Auto.js加入电池优化白名单这是最直接有效的。二是开启悬浮窗服务用前台服务保活。三是脚本内部加一个看门狗定时器如果3秒内没有成功执行滑动就尝试重新绑定无障碍服务。实际测试下来加白名单和前台服务组合后假死频率大幅下降从每天好几次降到几天一次。5.4 某些系统分屏分割线拖动后窗口区域识别错误还有一次翻车是分屏识别逻辑太死。我的初始代码只取了“最靠上的窗口”作为上屏但系统界面、输入法窗口也可能出现在窗口列表里。有一次我刚好切换了输入法输入法窗口的mFrame挤到了屏幕下部我的脚本把输入法窗口当成下屏把上屏App窗口当成普通窗口滑动就失误了。这个问题的排查路径是把dumpsys window windows的完整输出打出来看发现系统关键字的窗口类型和App窗口不同。修正方案是过滤掉系统UI窗口只保留应用窗口。在解析mFrame时增加一个条件排除mCurrentFocus状态异常的窗口或者直接通过mWindowType字段判断是否是Aplication类型窗口。这样不管打开什么输入法、控制面板都不会干扰分屏窗口的取点。6. 顺手做的小优化与可以继续扩展的方向脚本跑通只是第一步真正“好用”还需要做几个小优化。这些优化不是我一开始就想出来的都是挂机过程中一点点观察、调整出来的。第一是滑动参数随机化。纯固定的3秒一滑间隔和轨迹都一模一样系统端很容易通过行为特征识别自动化。我给滑动间隔加了一个随机偏移比如在2800到3300毫秒之间随机取一个值滑动起点y坐标也在窗口区域内上下浮动几十像素。这样模拟出来的人手行为更像真实操作挂机被限制的概率明显降低。第二是分屏识别的手动切换功能。有的时候我只想全屏自动刷不想开分屏脚本应该能自动判断如果当前没有分屏窗口就在全屏范围内滑动如果检测到两个窗口就默认操作上屏。加一个配置项支持“上屏/下屏/全屏”三种模式切换灵活很多。第三是异常自动恢复。挂机脚本最怕运行到一半静默挂掉。我加了一层心跳检测脚本每执行一次滑动就往日志里写一条记录外部再开一个定时任务检查日志时间戳如果发现超过5分钟没有新的记录就推送通知提醒。这样人不在场的时候也能及时发现异常。顺着这个方向还能扩展不少玩法。比如把滑动方向从固定左滑改成随机左滑/右滑把目标App的包名写进配置运行时先检查前台App是否是目标防止误操作其他页面再比如结合无障碍控件读取先识别当前页面是否有“跳过”按钮再决定是否滑动这些都能提高挂机脚本的智能程度。安卓的窗口机制决定了分屏自动化必须动态获取边界单纯写死坐标永远只适合一台设备。理解了“先拿边界再算坐标”的思路你就能把“循环左滑”这个简单的动作扩展到任何需要分区操作的场景。不管是双开挂机、分屏看直播签到还是以后遇到更复杂的交互需求这套方法论都通用。