一、为什么选择 ADB 方案做自动化Android 自动化脚本的实现路径有很多 ——Accessibility 服务、Instrumentation、Root 权限注入、ADB 命令等。不同方案在权限门槛、稳定性、兼容性上各有取舍。 ADB 自动化能力本质上走的是Shizuku ADB 权限的技术路线这使得它既不需要 Root也不需要将辅助服务挂在前台在很多场景下比传统 Accessibility 方案更 安静、更稳定。对于自动化脚本开发者而言理解这条技术链路的底层逻辑比死记 API 更重要。ADBAndroid Debug Bridge原本是 Android SDK 提供的调试桥接工具开发者通过 PC 端的adb命令向设备发送指令。Shizuku 的作用是把这套原本需要 PC 端发起的 ADB 权限搬运 到了设备本地让普通应用也能以 ADB 身份调用系统 API。冰狐智能辅助的adb模块就是在 Shizuku 提供的权限基础上封装出了一套面向脚本开发者的 JavaScript API。这条路线的优势很明显权限级别高于普通应用、低于 Root既能完成点击、滑动、按键模拟等核心自动化操作又不会像 Root 方案那样破坏系统安全。对于大多数日常自动化场景 —— 签到、批量操作、UI 回归测试 ——ADB 方案是一个性价比很高的选择。二、环境准备Shizuku 配置是前提在写任何脚本之前必须先把 Shizuku 环境搭好。官方文档明确指出adb 功能是使用 shizuku 来实现自动化操作的所以请按 shizuku 文档先安装和配置好 shizuku。这一步是硬门槛绕不过去。Shizuku 的启动方式主要有两种通过 ADB 启动需要一台电脑用 USB 连接设备后执行adb shell sh /sdcard/Android/data/moe.shizuku.privileged.api/start.sh。这种方式的缺点是设备重启后需要重新连接电脑启动。通过 Root 启动如果设备已 Root可以直接在 Shizuku 应用内以 Root 身份启动重启后也能自启。对于普通用户ADB 启动是最常见的路径。建议在配置完成后在 Shizuku 应用内确认服务状态为 已启动并确保冰狐智能辅助已经被授权使用 Shizuku。否则脚本运行时会在adb.connect()这一步直接失败。三、核心 API 详解冰狐智能辅助的adb模块提供了 11 个核心方法覆盖了从连接管理到输入模拟的完整链路。下面逐一拆解。3.1 生命周期管理init /connect/close这三个方法构成了 ADB 服务的完整生命周期。function main() { adb.init(); // 初始化 if (adb.connect()) { // 建立连接 // 执行自动化操作 } adb.close(); // 关闭连接 }adb.init()初始化 ADB 模块返回布尔值。这一步做的是模块内部的资源准备工作比如加载底层库、初始化 Shizuku 客户端。adb.connect()真正与 ADB 服务建立连接返回布尔值。这是判断自动化能力是否可用的关键节点 —— 如果 Shizuku 没启动、或者冰狐没有权限这里就会返回false。adb.close()关闭 ADB 服务释放资源。官方文档特别强调 当不在使用时调用 close关闭服务。这是一个良好的工程习惯长时间不释放连接可能导致 Shizuku 服务异常、或者占用不必要的系统资源。一个常见的错误是只调用init()不调用connect()然后直接执行click结果当然是没有任何反应。正确的顺序永远是init → connect → 操作 → close四步缺一不可。3.2 坐标操作click 与 swipe点击和滑动是最基础的 UI 交互也是自动化脚本中使用频率最高的两个方法。点击adb.click(750, 650); // x坐标, y坐标click接收两个整数参数x和y分别代表目标点的横纵坐标。这里的坐标系以屏幕左上角为原点单位是像素。需要注意的是不同分辨率的设备坐标值不同如果脚本需要跨设备运行最好结合屏幕分辨率做动态换算。滑动adb.swipe(100, 500, 100, 1000, 500); // startX, startY, endX, endY, duration(可选)swipe方法接收五个参数起始坐标startX/startY、终点坐标endX/endY以及可选的滑动时长duration单位毫秒默认 800ms。滑动时长是一个容易被忽略但很重要的参数。默认 800ms 的滑动速度偏慢在某些需要快速滑动的场景比如快速翻页、模拟快速划动下可以把 duration 调小到 200-300ms。反过来在一些对滑动精度要求高的场景比如游戏里的精准拖动适当延长 duration 可以让滑动轨迹更平滑。3.3 系统按键home /back/recentApps /enter/key这一组方法模拟的是 Android 系统的物理按键或导航键操作。adb.home(); // 按下 Home 键回到桌面 adb.back(); // 按下返回键 adb.recentApps(); // 打开最近任务列表 adb.enter(); // 按下回车键 adb.key(4); // 按下指定 keyCode 的按键4 对应返回键前四个方法是常用按键的快捷封装而key()方法则是通用的按键接口接收一个keyCode整数参数。Android 的 keyCode 定义在KeyEvent类中常用的有3HOME 键4BACK 键19方向上20方向下21方向左22方向右66回车24音量加25音量减掌握key()方法的意义在于它能覆盖home/back/recentApps/enter这四个快捷方法之外的所有按键场景比如媒体控制、数字键盘输入等。3.4 终极武器execCmd如果说前面的方法都是 封装好的工具箱那么execCmd就是 万能扳手。var result adb.execCmd(ls /sdcard/); console.log(result);execCmd接收一个字符串参数cmd直接执行 ADB 命令并以字符串形式返回命令执行结果。这意味着你可以在脚本中执行任意adb shell下能跑的命令 —— 文件操作、进程管理、系统属性读取、应用安装卸载等等。举几个实用的例子// 截图并保存到设备 adb.execCmd(screencap -p /sdcard/screenshot.png); // 查看当前前台 Activity adb.execCmd(dumpsys activity top | grep ACTIVITY); // 模拟文本输入需要焦点在输入框 adb.execCmd(input text hello world); // 查看已安装应用列表 adb.execCmd(pm list packages);execCmd的存在让冰狐智能辅助的 ADB 模块跳出了 只能做点按 的局限具备了接近 PC 端 ADB 工具的完整能力。对于高级脚本开发者来说这才是真正的核心玩法。四、实战案例自动化签到脚本下面用一个完整的实战案例把上面的 API 串起来。场景是每天打开某个 App自动完成签到操作。function main() { // 1. 初始化并连接 ADB 服务 adb.init(); if (!adb.connect()) { console.log(ADB 连接失败请检查 Shizuku 状态); return; } try { // 2. 回到桌面确保从干净的状态开始 adb.home(); sleep(1000); // 等待桌面加载完成 // 3. 启动目标应用通过 execCmd 调用 am start adb.execCmd(am start -n com.example.app/.MainActivity); sleep(2000); // 等待应用启动 // 4. 点击我的页面入口坐标根据实际设备调整 adb.click(900, 1800); sleep(1500); // 5. 点击签到按钮 adb.click(500, 800); sleep(1000); // 6. 签到完成后截图留证 adb.execCmd(screencap -p /sdcard/checkin_result.png); console.log(签到完成截图已保存); // 7. 返回桌面 adb.home(); } catch (e) { console.log(执行出错 e.message); } finally { // 8. 无论成功失败都要关闭连接 adb.close(); } console.log(脚本执行结束); }这个脚本体现了几个重要的工程实践第一错误处理。connect()的返回值一定要判断不能假设连接永远成功。try...finally结构确保即使中间步骤出错adb.close()也一定会被执行不会留下悬挂的连接。第二延时控制。每一步操作之间都加了sleep()这是因为 UI 加载、页面跳转都需要时间。如果操作速度快于页面响应后续的点击就会落在错误的位置上。延时的具体时长需要根据实际设备性能和应用响应速度调整没有万能值。第三状态复位。脚本开始时先按 Home 键回到桌面结束时也回到桌面。这种 干净进入、干净退出 的写法可以避免脚本连续运行时上一次的状态影响下一次的执行。五、坐标定位的挑战与应对方案纯坐标操作有一个天然的缺陷强依赖屏幕分辨率和 UI 布局。换一台设备、或者 App 更新后按钮位置变了脚本就失效了。这是所有基于坐标的自动化方案共同面临的问题。在冰狐智能辅助的生态里有几种应对思路1. 相对坐标换算不写死像素值而是根据屏幕宽高按比例计算。比如按钮在屏幕水平居中、垂直 30% 的位置就用screenWidth * 0.5和screenHeight * 0.3来计算。execCmd可以通过wm size命令获取屏幕分辨率再做动态计算。2. 结合图像识别冰狐智能辅助本身提供了 OCR 和图像找图的能力可以先用找图功能定位目标元素的位置再把坐标传给adb.click()。这比纯坐标方案鲁棒性强得多。3. 结合控件查找如果 App 的 UI 结构稳定可以通过uiautomator相关的命令获取控件树找到目标控件的 bounds 后再点击。这同样需要借助execCmd来执行底层命令。说白了adb模块提供的是 执行层 的能力 —— 给我坐标我就能点。至于 坐标从哪来需要开发者结合平台的其他能力自己解决。一个成熟的自动化脚本往往是图像识别 / OCR 做定位 ADB 做执行的组合打法。六、最佳实践与注意事项6.1 资源管理adb.close()不是可有可无的。虽然不调用也不一定立刻出问题但在循环执行、长时间运行的脚本里忘记关闭连接可能导致 Shizuku 服务内存泄漏、响应变慢。养成 有 init 必有 close 的习惯是专业开发者的基本素养。6.2 操作节奏Android 的 UI 渲染是单线程的系统处理输入事件也有自己的节奏。如果脚本点击速度太快可能会出现 点了但没反应 的情况 —— 不是命令没发出去而是系统还没处理完上一个事件。一般建议两次点击之间至少间隔 200-300ms复杂页面跳转后等待 1-2 秒。6.3 权限边界ADB 权限虽然高于普通应用但不是万能的。比如涉及到安全输入框密码框、系统级弹窗的确认ADB 可能无法操作。另外Android 的每个大版本都会收紧一些权限某些命令在高版本系统上可能失效。遇到execCmd执行无效果的情况先确认一下这条命令在当前 Android 版本上是否还被允许。6.4 调试技巧写脚本不可能一次就跑通。调试 ADB 脚本的一个实用技巧是在每一步操作前后都打日志比如console.log(准备点击签到按钮)这样一旦脚本卡住可以快速定位到是哪一步出了问题。另外配合screencap截图可以直观地看到执行时屏幕上的实际状态。七、进阶方向掌握了基础 API 之后有几个进阶方向可以探索多设备协同通过execCmd执行 ADB 相关命令可以在脚本中控制多台设备的协同操作适用于批量测试场景。性能监控利用execCmd执行dumpsys、top等命令可以在自动化操作的同时采集应用的 CPU、内存占用数据做性能测试。事件注入的高级用法input命令不仅能模拟点击和滑动还能模拟轨迹球、摇杆等更复杂的输入对于游戏自动化有特殊价值。Shell 脚本组合execCmd可以执行复杂的 shell 命令甚至多行脚本把一些纯文件操作放到 shell 层执行比在 JS 里逐行调用效率高得多。八、结语冰狐智能辅助的 ADB 模块是一个 接口不多但能量不小 的工具集。11 个方法看起来简单但execCmd的存在相当于给脚本开了一扇直通 Android 系统底层的门。对于有一定 Android 开发基础的脚本作者来说这里的发挥空间几乎是无限的。自动化脚本的核心竞争力从来不是 会调用多少个 API而是对系统运行机制的理解深度。知道每一步操作背后发生了什么、知道为什么有时候会失效、知道在不同设备上怎么适配 —— 这些才是区分 能用的脚本 和 好用的脚本 的关键。ADB 方案的价值就在于它让你离系统更近了一步让你有机会用更底层的视角去理解和操控 Android 设备。
使用adb实现自动化脚本
一、为什么选择 ADB 方案做自动化Android 自动化脚本的实现路径有很多 ——Accessibility 服务、Instrumentation、Root 权限注入、ADB 命令等。不同方案在权限门槛、稳定性、兼容性上各有取舍。 ADB 自动化能力本质上走的是Shizuku ADB 权限的技术路线这使得它既不需要 Root也不需要将辅助服务挂在前台在很多场景下比传统 Accessibility 方案更 安静、更稳定。对于自动化脚本开发者而言理解这条技术链路的底层逻辑比死记 API 更重要。ADBAndroid Debug Bridge原本是 Android SDK 提供的调试桥接工具开发者通过 PC 端的adb命令向设备发送指令。Shizuku 的作用是把这套原本需要 PC 端发起的 ADB 权限搬运 到了设备本地让普通应用也能以 ADB 身份调用系统 API。冰狐智能辅助的adb模块就是在 Shizuku 提供的权限基础上封装出了一套面向脚本开发者的 JavaScript API。这条路线的优势很明显权限级别高于普通应用、低于 Root既能完成点击、滑动、按键模拟等核心自动化操作又不会像 Root 方案那样破坏系统安全。对于大多数日常自动化场景 —— 签到、批量操作、UI 回归测试 ——ADB 方案是一个性价比很高的选择。二、环境准备Shizuku 配置是前提在写任何脚本之前必须先把 Shizuku 环境搭好。官方文档明确指出adb 功能是使用 shizuku 来实现自动化操作的所以请按 shizuku 文档先安装和配置好 shizuku。这一步是硬门槛绕不过去。Shizuku 的启动方式主要有两种通过 ADB 启动需要一台电脑用 USB 连接设备后执行adb shell sh /sdcard/Android/data/moe.shizuku.privileged.api/start.sh。这种方式的缺点是设备重启后需要重新连接电脑启动。通过 Root 启动如果设备已 Root可以直接在 Shizuku 应用内以 Root 身份启动重启后也能自启。对于普通用户ADB 启动是最常见的路径。建议在配置完成后在 Shizuku 应用内确认服务状态为 已启动并确保冰狐智能辅助已经被授权使用 Shizuku。否则脚本运行时会在adb.connect()这一步直接失败。三、核心 API 详解冰狐智能辅助的adb模块提供了 11 个核心方法覆盖了从连接管理到输入模拟的完整链路。下面逐一拆解。3.1 生命周期管理init /connect/close这三个方法构成了 ADB 服务的完整生命周期。function main() { adb.init(); // 初始化 if (adb.connect()) { // 建立连接 // 执行自动化操作 } adb.close(); // 关闭连接 }adb.init()初始化 ADB 模块返回布尔值。这一步做的是模块内部的资源准备工作比如加载底层库、初始化 Shizuku 客户端。adb.connect()真正与 ADB 服务建立连接返回布尔值。这是判断自动化能力是否可用的关键节点 —— 如果 Shizuku 没启动、或者冰狐没有权限这里就会返回false。adb.close()关闭 ADB 服务释放资源。官方文档特别强调 当不在使用时调用 close关闭服务。这是一个良好的工程习惯长时间不释放连接可能导致 Shizuku 服务异常、或者占用不必要的系统资源。一个常见的错误是只调用init()不调用connect()然后直接执行click结果当然是没有任何反应。正确的顺序永远是init → connect → 操作 → close四步缺一不可。3.2 坐标操作click 与 swipe点击和滑动是最基础的 UI 交互也是自动化脚本中使用频率最高的两个方法。点击adb.click(750, 650); // x坐标, y坐标click接收两个整数参数x和y分别代表目标点的横纵坐标。这里的坐标系以屏幕左上角为原点单位是像素。需要注意的是不同分辨率的设备坐标值不同如果脚本需要跨设备运行最好结合屏幕分辨率做动态换算。滑动adb.swipe(100, 500, 100, 1000, 500); // startX, startY, endX, endY, duration(可选)swipe方法接收五个参数起始坐标startX/startY、终点坐标endX/endY以及可选的滑动时长duration单位毫秒默认 800ms。滑动时长是一个容易被忽略但很重要的参数。默认 800ms 的滑动速度偏慢在某些需要快速滑动的场景比如快速翻页、模拟快速划动下可以把 duration 调小到 200-300ms。反过来在一些对滑动精度要求高的场景比如游戏里的精准拖动适当延长 duration 可以让滑动轨迹更平滑。3.3 系统按键home /back/recentApps /enter/key这一组方法模拟的是 Android 系统的物理按键或导航键操作。adb.home(); // 按下 Home 键回到桌面 adb.back(); // 按下返回键 adb.recentApps(); // 打开最近任务列表 adb.enter(); // 按下回车键 adb.key(4); // 按下指定 keyCode 的按键4 对应返回键前四个方法是常用按键的快捷封装而key()方法则是通用的按键接口接收一个keyCode整数参数。Android 的 keyCode 定义在KeyEvent类中常用的有3HOME 键4BACK 键19方向上20方向下21方向左22方向右66回车24音量加25音量减掌握key()方法的意义在于它能覆盖home/back/recentApps/enter这四个快捷方法之外的所有按键场景比如媒体控制、数字键盘输入等。3.4 终极武器execCmd如果说前面的方法都是 封装好的工具箱那么execCmd就是 万能扳手。var result adb.execCmd(ls /sdcard/); console.log(result);execCmd接收一个字符串参数cmd直接执行 ADB 命令并以字符串形式返回命令执行结果。这意味着你可以在脚本中执行任意adb shell下能跑的命令 —— 文件操作、进程管理、系统属性读取、应用安装卸载等等。举几个实用的例子// 截图并保存到设备 adb.execCmd(screencap -p /sdcard/screenshot.png); // 查看当前前台 Activity adb.execCmd(dumpsys activity top | grep ACTIVITY); // 模拟文本输入需要焦点在输入框 adb.execCmd(input text hello world); // 查看已安装应用列表 adb.execCmd(pm list packages);execCmd的存在让冰狐智能辅助的 ADB 模块跳出了 只能做点按 的局限具备了接近 PC 端 ADB 工具的完整能力。对于高级脚本开发者来说这才是真正的核心玩法。四、实战案例自动化签到脚本下面用一个完整的实战案例把上面的 API 串起来。场景是每天打开某个 App自动完成签到操作。function main() { // 1. 初始化并连接 ADB 服务 adb.init(); if (!adb.connect()) { console.log(ADB 连接失败请检查 Shizuku 状态); return; } try { // 2. 回到桌面确保从干净的状态开始 adb.home(); sleep(1000); // 等待桌面加载完成 // 3. 启动目标应用通过 execCmd 调用 am start adb.execCmd(am start -n com.example.app/.MainActivity); sleep(2000); // 等待应用启动 // 4. 点击我的页面入口坐标根据实际设备调整 adb.click(900, 1800); sleep(1500); // 5. 点击签到按钮 adb.click(500, 800); sleep(1000); // 6. 签到完成后截图留证 adb.execCmd(screencap -p /sdcard/checkin_result.png); console.log(签到完成截图已保存); // 7. 返回桌面 adb.home(); } catch (e) { console.log(执行出错 e.message); } finally { // 8. 无论成功失败都要关闭连接 adb.close(); } console.log(脚本执行结束); }这个脚本体现了几个重要的工程实践第一错误处理。connect()的返回值一定要判断不能假设连接永远成功。try...finally结构确保即使中间步骤出错adb.close()也一定会被执行不会留下悬挂的连接。第二延时控制。每一步操作之间都加了sleep()这是因为 UI 加载、页面跳转都需要时间。如果操作速度快于页面响应后续的点击就会落在错误的位置上。延时的具体时长需要根据实际设备性能和应用响应速度调整没有万能值。第三状态复位。脚本开始时先按 Home 键回到桌面结束时也回到桌面。这种 干净进入、干净退出 的写法可以避免脚本连续运行时上一次的状态影响下一次的执行。五、坐标定位的挑战与应对方案纯坐标操作有一个天然的缺陷强依赖屏幕分辨率和 UI 布局。换一台设备、或者 App 更新后按钮位置变了脚本就失效了。这是所有基于坐标的自动化方案共同面临的问题。在冰狐智能辅助的生态里有几种应对思路1. 相对坐标换算不写死像素值而是根据屏幕宽高按比例计算。比如按钮在屏幕水平居中、垂直 30% 的位置就用screenWidth * 0.5和screenHeight * 0.3来计算。execCmd可以通过wm size命令获取屏幕分辨率再做动态计算。2. 结合图像识别冰狐智能辅助本身提供了 OCR 和图像找图的能力可以先用找图功能定位目标元素的位置再把坐标传给adb.click()。这比纯坐标方案鲁棒性强得多。3. 结合控件查找如果 App 的 UI 结构稳定可以通过uiautomator相关的命令获取控件树找到目标控件的 bounds 后再点击。这同样需要借助execCmd来执行底层命令。说白了adb模块提供的是 执行层 的能力 —— 给我坐标我就能点。至于 坐标从哪来需要开发者结合平台的其他能力自己解决。一个成熟的自动化脚本往往是图像识别 / OCR 做定位 ADB 做执行的组合打法。六、最佳实践与注意事项6.1 资源管理adb.close()不是可有可无的。虽然不调用也不一定立刻出问题但在循环执行、长时间运行的脚本里忘记关闭连接可能导致 Shizuku 服务内存泄漏、响应变慢。养成 有 init 必有 close 的习惯是专业开发者的基本素养。6.2 操作节奏Android 的 UI 渲染是单线程的系统处理输入事件也有自己的节奏。如果脚本点击速度太快可能会出现 点了但没反应 的情况 —— 不是命令没发出去而是系统还没处理完上一个事件。一般建议两次点击之间至少间隔 200-300ms复杂页面跳转后等待 1-2 秒。6.3 权限边界ADB 权限虽然高于普通应用但不是万能的。比如涉及到安全输入框密码框、系统级弹窗的确认ADB 可能无法操作。另外Android 的每个大版本都会收紧一些权限某些命令在高版本系统上可能失效。遇到execCmd执行无效果的情况先确认一下这条命令在当前 Android 版本上是否还被允许。6.4 调试技巧写脚本不可能一次就跑通。调试 ADB 脚本的一个实用技巧是在每一步操作前后都打日志比如console.log(准备点击签到按钮)这样一旦脚本卡住可以快速定位到是哪一步出了问题。另外配合screencap截图可以直观地看到执行时屏幕上的实际状态。七、进阶方向掌握了基础 API 之后有几个进阶方向可以探索多设备协同通过execCmd执行 ADB 相关命令可以在脚本中控制多台设备的协同操作适用于批量测试场景。性能监控利用execCmd执行dumpsys、top等命令可以在自动化操作的同时采集应用的 CPU、内存占用数据做性能测试。事件注入的高级用法input命令不仅能模拟点击和滑动还能模拟轨迹球、摇杆等更复杂的输入对于游戏自动化有特殊价值。Shell 脚本组合execCmd可以执行复杂的 shell 命令甚至多行脚本把一些纯文件操作放到 shell 层执行比在 JS 里逐行调用效率高得多。八、结语冰狐智能辅助的 ADB 模块是一个 接口不多但能量不小 的工具集。11 个方法看起来简单但execCmd的存在相当于给脚本开了一扇直通 Android 系统底层的门。对于有一定 Android 开发基础的脚本作者来说这里的发挥空间几乎是无限的。自动化脚本的核心竞争力从来不是 会调用多少个 API而是对系统运行机制的理解深度。知道每一步操作背后发生了什么、知道为什么有时候会失效、知道在不同设备上怎么适配 —— 这些才是区分 能用的脚本 和 好用的脚本 的关键。ADB 方案的价值就在于它让你离系统更近了一步让你有机会用更底层的视角去理解和操控 Android 设备。
