老机器上折腾安卓自动化脚本这件事我前前后后踩了差不多两个月的坑。手头这台机器还是当年的配置4G 内存、机械硬盘、集显系统停留在 Win7 SP1跑个浏览器开五个标签页就开始喘。想在上面写 AutoX.js 脚本一开始我天真地装了 Android Studio结果光 Gradle 同步就把内存吃到爆风扇像要起飞编译一次等十分钟最后只能认怂卸载。后来我换了个思路不碰原生开发工具链用雷神模拟器当运行环境VSCode 当编辑器adb 当传输通道AutoX.js 当脚本运行时整套东西加起来占内存不到 1.5G写脚本、跑脚本、看日志全流程能闭环。这套组合解决的核心问题很明确——在硬件资源极度受限的老机器上把安卓自动化脚本的开发回路跑通不依赖任何重型 IDE。适合谁看手里有闲置老电脑、想学安卓自动化脚本、又不想为了跑个脚本去换硬件的人也适合那些主力机不敢乱装东西、想拿台旧机器专门当脚本调试机的朋友。下面我按实际配置顺序把每一步的选择理由、参数、坑点全摊开讲。1. 先想清楚这套组合为什么能跑起来1.1 重型工具链在 4G 内存机器上的真实表现我先说结论安卓原生开发那套东西在老机器上不是慢是跑不动。Android Studio 本体安装包 1G 出头解压完占 3G 以上启动时 JVM 默认堆就吃掉 750M再加上 Gradle Daemon、Kotlin 编译进程、模拟器8G 内存的机器都能给你干到内存告警。4G 内存的老机器更别提系统本身就要占 1.2G 左右剩下的空间连 IDE 启动都不够。而 AutoX.js 的定位完全是另一个路子它不需要编译不需要打包 APK写完的 js 文件直接丢到设备目录里就能解释执行。这意味着一整条工具链里最重的环节——编译构建——被直接砍掉了。剩下的只有编辑器 传输 运行时三件事每一件都可以挑轻量的方案。VSCode 空载内存约 200M关掉一堆默认功能后能压到 150M 以内雷神模拟器分配 2G 内存跑一个精简的安卓镜像实际驻留大约 1G 出头加上系统本身整机内存占用能压在 2.6G 左右4G 机器还有余量。这里的关键判断是你到底是要开发一个安卓应用还是要写一段能操作安卓界面的脚本。前者需要完整的构建工具链后者只需要一个能执行 js 的运行时和一套查找控件、模拟点击的 API。想清楚这一点工具选型就没什么纠结的了。1.2 三种方案横向对比与我的取舍我把当时考虑过的三条路整理成一张表方便你对照自己的情况做决定。方案内存占用上手门槛调试体验适合场景Android Studio 原生模拟器3G 起步实际 5G高要懂 Gradle、SDK 版本管理断点调试完整但启动慢真正做应用开发真机 USB 连接 VSCode1G 以内中要处理驱动和授权弹窗屏幕小日志靠抓单机调试机器性能好雷神模拟器 VSCode AutoX.js1.5G 左右低主要是环境配置的坑可快照回滚日志可导出老机器、脚本类开发我选第三条路的核心理由其实不是省资源而是可回滚。脚本跑飞了、误删了系统目录、把模拟器搞成砖真机上你得重刷或者恢复出厂模拟器上直接删掉重建两分钟搞定。做自动化脚本调试的时候这种随便折腾的底气非常重要因为你写的东西本来就是在操作界面很容易把环境搞乱比如误触到设置里改了输入法、关掉了某个系统服务。模拟器快照就是你的后悔药。另外还有个隐性好处模拟器的分辨率和 DPI 是固定的你能精确知道某个按钮的坐标。真机换一台设备分辨率一变基于坐标的脚本就废了但脚本在模拟器上调试时至少有一个确定的环境。当然我还是要提醒尽量用控件选择器而不是坐标点击这个后面会展开说。1.3 这套环境的能力边界在哪里得把丑话说前面免得你配置完了发现有些事干不了。AutoX.js 跑在模拟器里能做的事情包括读取屏幕上的控件树、模拟点击滑动、读取和写入文件、发 HTTP 请求、调用部分系统 API、执行定时任务。做不了或者很难做的事情包括需要硬件传感器的功能陀螺仪、真实 GPS模拟器给的是假数据、需要 root 深度权限的系统级操作虽然雷神能开 root但部分操作在模拟器上行为异常、依赖真实摄像头和麦克风的功能。还有一个容易被忽略的点模拟器的安卓版本决定了你能用哪些 API。雷神模拟器一般提供 Android 7 和 Android 9 两种镜像可选我建议选 Android 7.1原因是它对老机器更友好内存占用低一截而且 AutoX.js 在这个版本上的兼容性经过大量验证控件树读取的完整度也更好。Android 9 的镜像在 4G 内存机器上跑起来会明显更吃力冷启动要多等十几秒。2. 软件版本选型这一步选错后面全是白工2.1 VSCode 必须锁死在能跑的版本上这是整套环境里最容易翻车的一步我把它放在最前面讲。当前的 VSCode 安装包默认会装最新版而最新版在 Win7 SP1 上根本起不来——双击图标毫无反应或者闪一下就没了。原因是新版本依赖了系统里不存在的 API。能在这套系统上跑起来的最后一批版本是1.70 系列具体我用的 1.70.3安装包大概 80M装完占 300M 左右。下载的时候注意找System Installer或者User Installer的历史版本包别直接点官网首页那个下载按钮那个给你的是最新版。装完之后有三件事必须立刻做顺序不能反第一件关闭自动更新。打开设置搜索update.mode改成none再搜extensions.autoUpdate关掉。这一步是保命的因为一旦它后台静默更新到新版本下次启动就是黑屏你得卸载重装之前配的所有插件和设置全丢。第二件关闭硬件加速。老机器的集成显卡对新版渲染管线支持不全开着硬件加速会出现界面撕裂、滚动卡顿、输入延迟。在 VSCode 的argv.json按 CtrlShiftP 搜 Configure Runtime Arguments 可以打开里加一行{ disable-hardware-acceleration: true }关掉之后界面渲染交给 CPU虽然理论性能下降但在老集显上反而更跟手因为避免了驱动层的兼容性问题。我实测下来滚动代码的流畅度提升明显。第三件精简默认功能。把这几项写进用户设置{ editor.minimap.enabled: false, breadcrumbs.enabled: false, workbench.startupEditor: none, workbench.editor.enablePreview: true, editor.fontLigatures: false, telemetry.telemetryLevel: off, files.watcherExclude: { **/node_modules/**: true, **/.git/objects/**: true } }小地图和面包屑这两个功能在大屏上很舒服但在 1366x768 的老屏幕上纯属占地方关掉之后编辑区能多出三四行。文件监视排除掉node_modules尤其重要那个目录动辄几万个文件文件监视器会持续吃 CPU。2.2 Node 与 ADB 的版本陷阱VSCode 插件生态里有一部分工具需要 Node 环境虽然这套流程里 Node 不是刚需但装一个备用没坏处。能在 Win7 上跑的比较新的版本是Node 14.21.x再往上16 及以上就要求更高的系统版本了。安装时勾选添加到 PATH装完在命令行敲node -v验证。ADB 这块坑更多。platform-tools 新版对系统 API 的要求在提高某些版本在 Win7 上会出现adb server didnt ACK或者干脆启动即退出。我的经验是优先试 31.x 和 33.x 这两个大版本能连上就别乱升级。判断标准很简单解压后在该目录打开命令行敲adb version能正常打印版本号并且不报错就说明能跑。如果报缺少 DLL说明这个版本要的系统组件你机器上没有直接换低一档的版本。还有一个隐藏问题多个 adb 版本共存会打架。如果你之前装过某个手机助手类软件它自带一份 adb并且把自己的路径写进了环境变量你新解压的 adb 和它版本不一致时就会看到那个经典报错adb server version (41) doesnt match this client (39); killing...处理方法有两种任选其一。省事的做法是把自己的 adb 目录加到环境变量最前面并且把其他 adb 目录从 PATH 里删掉彻底的做法是找到旧 adb 进程taskkill /f /im adb.exe全部干掉然后只用自己那一份。我建议走彻底路线因为这个报错会反复出现每次都要处理很烦。2.3 系统补丁与运行库补齐清单Win7 SP1 原版系统直接装这些东西大概率会缺组件我把必须补的列一下装之前先打个勾组件作用缺了会怎样KB2999226 (UCRT)通用 C 运行库VSCode 启动即报缺少 api-ms-win-crt-*.dllKB2533623提供 SetDefaultDllDirectories部分软件加载 DLL 失败.NET Framework 4.6.2 以上部分后台组件依赖插件面板空白、扩展装不上VC 2015-2022 运行库模拟器与工具链依赖模拟器启动闪退TLS 1.2 注册表项让系统能走新一代加密协议VSCode 扩展市场连不上、插件搜不出结果最后一条 SDK 1.2 这个问题特别隐蔽。表现是VSCode 里按 CtrlShiftX 打开扩展面板输入插件名搜索转圈转半天最后提示无法连接。你会以为是网络问题其实是系统的加密协议栈太老对方服务器已经不支持了。补法是导入一个注册表文件Windows Registry Editor Version 5.00 [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings\WinHttp] DefaultSecureProtocolsdword:00000a00导入后重启再去扩展面板搜插件就能正常出结果了。这个坑我在两个不同的老机器上都遇到过值得单独记一笔。3. 雷神模拟器的安装与老机器专项调优3.1 装之前的硬件条件确认装模拟器之前必须确认一件事CPU 虚拟化有没有开。这一步不做模拟器只能靠软件模拟 CPU 指令性能会掉到令人发指的程度——开机等五分钟点一下卡三秒完全没法用。而且这种情况下你会误以为是机器太老其实是没开虚拟化。确认方法打开任务管理器CtrlShiftEsc切到性能标签看 CPU 那一栏下方有没有虚拟化已启用。如果显示已禁用就得进 BIOS 开。开机按 Del 或 F2 进 BIOS不同主板不一样开机第一屏会有提示找Intel Virtualization Technology、VT-x、SVM Mode、AMD-V这类字样的选项设成 Enabled保存重启。不同品牌的机器位置不一样一般在Advanced→CPU Configuration下面有些笔记本隐藏在Security或者Configuration标签里。找不到就上网搜你的主板型号加开启虚拟化这属于纯操作性问题查一下就有答案。确认虚拟化开了之后再进行安装。安装路径有讲究不要放在中文目录、不要放在带空格的目录、不要放在 C 盘根目录。我一般放在D:\Emu\Leishen这种路径下。原因是很多工具链在处理路径时对中文字符和空格的处理不一致会出现明明文件在那儿却读不到的诡异问题。这个问题在后面的脚本推送环节尤其明显。3.2 性能参数怎么配才不卡模拟器装好之后第一件事是进设置调性能别急着装东西。默认配置是给主流配置机器准备的在老机器上要往下压。我给出的配置建议针对 4G 内存、双核 CPU 的老机器参数建议值理由CPU 核心数2给宿主机留出核心否则系统界面都会卡内存分配2048 MB低于 1536M 安卓会频繁杀后台高于 2048M 宿主机吃紧分辨率720x12801080P 在老集显上渲染压力大且控件位置换算更麻烦DPI240与 720P 匹配界面元素大小适中渲染模式DirectX默认老 Intel 集显上比 OpenGL 兼容性更好帧率上限30 FPS脚本操作不需要高帧率锁帧能明显降 CPU 占用渲染模式这一项值得单独说。模拟器一般提供 DirectX 和 OpenGL 两种。理论上 OpenGL 跨平台性更好但在很多老 Intel 集显上OpenGL 驱动版本陈旧会出现界面花屏、局部黑块、鼠标位置偏移。DirectX 走的是系统自带的图形接口兼容性通常更好。但反过来某些 AMD 老显卡上 OpenGL 表现更佳。判断标准很简单切到某个模式后拖动模拟器窗口看界面是否跟手、有没有残影。哪个顺就用哪个不要迷信网上说的某某模式性能更好。还有一项容易被忽略的关掉模拟器的开机自启和后台服务。这类模拟器为了提升体验会常驻几个后台进程做更新检查和推送。在 4G 内存的机器上这几个进程能吃掉 300M 内存。在模拟器设置的其他或者高级里找自启动相关选项关掉然后在系统服务里services.msc找到对应的服务启动类型改成手动。3.3 打开调试开关与 root 权限模拟器启动之后进设置里找开发者选项。雷神模拟器的设置里一般直接有开发者选项或者ADB 调试的开关勾上。有些版本需要先到关于平板电脑里连续点击版本号七次才能解锁开发者选项跟真机一样。同时把ROOT 权限打开。AutoX.js 的大部分功能不依赖 root但有些操作比如读取某些系统目录、模拟系统级按键需要它。开了 root 之后模拟器重启时会弹授权提示记得点允许并勾选记住选择。不开 root 也完全能用只是少一些能力你要是只写简单的界面操作脚本可以不开能省一点系统开销。接下来是最关键的一步确定 ADB 的端口号。模拟器默认的 adb 端口不一定是什么网上流传的5555只是最常见的约定雷神模拟器实际用的可能不是这个。别猜直接查。先找到模拟器的进程 PIDtasklist | findstr /i leishen会列出几个进程记下主进程的 PID一般名字里带 Emulator 或 Headless 的那个。然后查这个 PID 监听的端口netstat -ano | findstr 刚才的PID输出里找LISTENING状态、本地地址是127.0.0.1:xxxxx的那一行那个端口就是 adb 端口。我这台机器上查到的是 5555但你那台可能是别的一定要自己查。这一步花两分钟能省掉后面半小时的为什么连不上。查到端口后验证一下adb connect 127.0.0.1:5555 adb devices如果adb devices列表里出现了127.0.0.1:5555 device说明链路通了。如果显示offline先adb kill-server再重新 connect如果显示unauthorized去模拟器屏幕上看看有没有弹授权框勾选一律允许。4. 打通 VSCode 与模拟器的完整链路4.1 在模拟器里装好运行环境链路通了之后把 AutoX.js 的设备端装上。从官方渠道拿到 apk 文件用 adb 装adb -s 127.0.0.1:5555 install -r autoxjs.apk-s参数指定设备多设备连接时必加单设备可以省。-r表示覆盖安装方便后续升级。装完先在模拟器里手动启动一次做三件事第一开启无障碍服务。进入系统设置 → 无障碍 → 找到 AutoX.js打开开关。这一步是整个方案的核心没有无障碍权限脚本读不到控件树只能瞎点坐标。开启后系统会弹一个提示说此应用可以查看屏幕内容确认即可。第二关闭电池优化。设置 → 电池 → 电池优化 → 找到 AutoX.js设为不优化。安卓的后台管理会在一段时间无操作后把应用冻结脚本跑到一半就停很隐蔽。第三允许自启动。部分模拟器镜像有自己的权限管理需要在里面单独给 AutoX.js 授权自启动否则模拟器重启后服务不自动起来。这三件事做完回到 AutoX.js 主界面它应该会显示无障碍服务已开启的绿色提示。如果没有去系统设置里确认开关状态有时候开关显示开着但服务实际没起来关掉再开一次。4.2 端口转发让模拟器找到你的电脑现在到了最容易卡住的地方。VSCode 的插件会在电脑上起一个服务默认 9317 端口模拟器里的 AutoX.js 需要连上这个端口才能接收运行脚本的指令。问题在于模拟器是一个虚拟的独立网络环境它里面的127.0.0.1指的是模拟器自己不是你的电脑。有两种解法。解法一用 adb reverse 做端口转发。这是我推荐的方式因为不依赖网络配置也不受防火墙影响adb -s 127.0.0.1:5555 reverse tcp:9317 tcp:9317这条命令的意思是模拟器内部访问127.0.0.1:9317的流量全部转发到电脑的 9317 端口。执行完之后在 AutoX.js 的连接电脑里填127.0.0.1:9317就行。这个转发的缺点是模拟器重启后会失效需要重新执行。所以我把它写进了一个批处理文件每次开工前双击一下echo off adb connect 127.0.0.1:5555 adb -s 127.0.0.1:5555 reverse tcp:9317 tcp:9317 adb devices pause解法二填宿主机的虚拟网卡地址。模拟器的 NAT 网络里宿主机通常映射为10.0.2.2你在 AutoX.js 里填这个地址加端口。但这个地址在不同模拟器上不统一有些是10.0.2.2有些是网关地址的最后一位改成 1。判断方法在模拟器里看 WiFi 详情记下 IP 和网关网关地址通常就是宿主机。我建议先用解法一实在不行再试解法二。解法一的好处是即使你换了网络环境、开了防火墙都不受影响。4.3 在 VSCode 里装插件并跑通第一个脚本回到 VSCode打开扩展面板搜Auto.js或者AutoX.js能找到对应的插件。认准那种提供Start Server、Run、Save命令的装完重启 VSCode。按CtrlShiftP打开命令面板输入Auto.js: Start Server回车。底部状态栏会显示服务已启动端口 9317。如果提示端口被占用说明有别的东西占着换个端口同时记得把 adb reverse 的目标端口也改掉两边必须一致。然后新建一个文件写第一个测试脚本// test.js toast(链路已打通); console.log(当前设备分辨率 device.width x device.height);保存为 UTF-8 编码右下角状态栏能看到编码点一下可以改然后按CtrlShiftP输入Auto.js: Run选择你的设备。如果模拟器上弹出了那个 toast 提示恭喜整条链路跑通了。同时在 VSCode 的输出面板能看到打印的分辨率说明日志回传也正常。这一步跑通之后后面所有的事情都是在这个基础上做加法。如果卡在这里往下看第 7 章的问题排查部分我把遇到过的所有连接问题都列进去了。5. 日常开发工作流写、推、跑、看日志5.1 工程目录怎么组织才不混乱一开始我是直接在模拟器的/sdcard/脚本/目录里建文件用 adb push 一个个推。写了十几个脚本之后彻底乱了改了什么、哪个是当前版本完全记不清。后来我改成在电脑上建工程目录用固定的目录结构管理autox-project/ ├── src/ │ ├── main.js # 入口脚本 │ ├── lib/ │ │ ├── ui.js # 界面操作封装 │ │ └── utils.js # 通用工具函数 │ └── modules/ │ └── task1.js # 具体任务模块 ├── logs/ # 抓下来的日志 ├── .vscode/ │ └── tasks.json # 一键推送任务 └── push.bat # 推送脚本这样做的好处是可以用 git 管理版本改坏了能回滚而且模块化的写法让主脚本保持干净公共逻辑抽到lib里多个脚本复用。AutoX.js 支持require加载本地模块路径写相对路径就行// main.js const ui require(./lib/ui.js); const utils require(./lib/utils.js); ui.clickByText(设置); utils.sleepRandom(800, 1200);这里有个细节要注意require 的路径在设备上执行时是相对于脚本所在目录的所以推送到设备的时候整个目录结构要一起推过去不能只推 main.js。这也是我建议用目录管理而不是单文件的原因之一。5.2 用 tasks.json 做一键推送每次手动敲 adb push 太麻烦我用 VSCode 的任务系统做成一键操作。在.vscode/tasks.json里写{ version: 2.0.0, tasks: [ { label: 推送到模拟器, type: shell, command: adb, args: [ -s, 127.0.0.1:5555, push, ${workspaceFolder}/src, /sdcard/脚本/ ], problemMatcher: [] } ] }按CtrlShiftB就能执行。${workspaceFolder}是 VSCode 的内置变量指向当前打开的工程根目录这样换了机器路径也不用改配置。推送完再执行运行命令。整个流程就是改代码 → CtrlS 保存 → CtrlShiftB 推送 → 命令面板 Run 执行。熟练之后十秒钟一个循环比在模拟器里用触屏改代码快得多。如果你嫌这样还不够快可以在 tasks.json 里再配一个组合任务把推送和执行串起来{ label: 推送并运行, dependsOrder: sequence, dependsOn: [推送到模拟器] }不过说实话我实际用下来还是分两步更顺手因为推送完经常想在模拟器上手动确认一下当前界面状态再运行。5.3 日志抓取与问题定位的思路脚本出问题的时候光看界面现象很难判断原因必须看日志。AutoX.js 有两种日志输出方式我用得最多的是这两种第一种在脚本里用 console.log 打印。配合 VSCode 插件的输出面板日志会实时回传。这种方式适合调试逻辑比如打印当前找到的控件数量判断条件的结果是什么。let btn text(确定).findOne(3000); console.log(找到按钮 (btn ? 是 : 否)); if (btn) { console.log(按钮位置 btn.bounds().centerX() , btn.bounds().centerY()); }第二种用 adb logcat 抓系统层日志。当脚本崩溃、抛异常、或者 AutoX.js 本身出问题时logcat 能看到完整堆栈。命令是adb -s 127.0.0.1:5555 logcat -s AutoJs:D AndroidRuntime:E-s后面跟标签过滤只保留 AutoX.js 相关和安卓运行时异常的日志否则日志刷屏根本看不过来。抓到的内容重定向到文件方便慢慢看adb -s 127.0.0.1:5555 logcat -s AutoJs:D logs\run.log还有一种特殊情况脚本执行了但什么都没发生。这时候先确认无障碍服务还在再确认脚本是不是卡在某个findOne等待上。我遇到过一次脚本卡死是因为弹了个系统权限框控件树里没有目标元素findOne一直等到超时。所以关键位置一定要给超时时间不要写findOne()无参数版本那是无限等待能把脚本挂死。6. 卡顿治理老机器上的性能优化清单6.1 系统层的瘦身动作硬件摆在那儿能做的就是把不必要的开销砍掉。我按收益从大到小排了个序你可以照着做第一步关掉视觉特效。右键计算机 → 属性 → 高级系统设置 → 性能设置选调整为最佳性能。这一步能关掉窗口动画、菜单淡入淡出、阴影等一堆效果在集显机器上体感提升非常明显。如果你实在受不了那种回到 2000 年的界面可以选自定义只保留平滑屏幕字体边缘和显示缩略图而不是图标这两项。第二步关掉 Windows Search 索引服务。这个服务在后台持续扫描硬盘建索引机械硬盘上能吃掉大量 IO。在services.msc里找到Windows Search停止并设为禁用。代价是开始菜单搜索变慢但老机器上本来也不怎么用那个。第三步加大虚拟内存。4G 物理内存跑模拟器加 VSCode 确实紧把虚拟内存设大一点能避免内存不足弹窗。设置位置在性能选项 → 高级 → 虚拟内存建议设在非系统盘上初始大小和最大值都设 4096M 到 8192M 之间。设在非系统盘是因为机械硬盘的分区读写会互相干扰把页面文件放到另一个物理盘如果有的话收益更大。第四步清理启动项。运行msconfig在启动标签里把非必要的项全部取消勾选。输入法、杀毒软件、各类助手、更新程序能关的全关。这一步经常能省出 300-500M 内存。第五步如果条件允许换一块固态硬盘。这是所有优化里收益最大的一项没有之一。老机器上机械硬盘的随机读写是最大的瓶颈模拟器启动要读几千个小文件机械盘上要两分钟固态盘上十几秒。哪怕是一块最便宜的入门固态体验提升也是代际的。这个投入比起换整机便宜太多了值得考虑。6.2 模拟器与编辑器的资源分配平衡系统瘦身之后剩下的就是分配问题。模拟器和 VSCode 抢资源得有个取舍原则模拟器是运行环境分配要够用VSCode 是编辑环境能省则省。模拟器这边2G 内存是底线低于这个数值安卓系统会频繁触发内存回收后台服务被杀AutoX.js 的无障碍服务跟着挂掉表现出来就是脚本跑着跑着就不动了。CPU 给 2 核不要给 1 核单核跑安卓系统会明显卡顿因为系统本身有大量并发任务。模拟器内部也要做减法。装完系统镜像之后把自带的预装应用能卸的全卸了尤其是那些会后台自启的。我用adb shell pm list packages列出所有包然后挑不认识的、看着像推广的卸载adb -s 127.0.0.1:5555 shell pm uninstall --user 0 包名--user 0参数表示对当前用户卸载不需要 root卸载后系统分区里的原文件还在出问题可以恢复。这个方法比直接用 root 删安全得多。VSCode 这边除了前面说的关闭 minimap 和文件监视还有一条不要装一堆用不上的插件。每装一个插件就多一个后台进程或者语言服务。这套工作流真正需要的插件就两三个AutoX.js 相关的、可能加一个中文语言包、再加一个简单的 TODO 高亮就够。其他什么 AI 补全、代码格式化、主题美化在老机器上全是负担。最后给一个监控方法任务管理器开着切到进程标签按内存排序。正常工作时应该是模拟器进程 900-1200M、VSCode 150-250M、系统进程若干。如果模拟器超过 1.5G说明里面装了太多东西去清理如果 VSCode 超过 400M去插件面板看看哪个插件在吃内存。7. 常见问题速查与排查实录7.1 连接类问题排查表现象大概率原因处理办法adb devices列表为空端口不对或模拟器 adb 未开用 netstat 重新确认端口检查模拟器设置里的调试开关设备显示offlineadb 服务状态错乱adb kill-server后重新 connect设备显示unauthorized授权弹窗没点看模拟器屏幕有无弹窗勾选一律允许adb server version doesnt match多版本 adb 冲突杀掉所有 adb 进程只保留一份并置顶 PATH插件连不上 9317端口转发没做或失效重新执行 adb reverse确认 VSCode 服务已启动转发做了还是连不上模拟器里的地址填错改用127.0.0.1:9317不要填电脑的局域网 IPVSCode 扩展面板转圈搜不出结果系统加密协议太老导入 TLS 1.2 注册表项后重启双击 VSCode 无反应被自动更新到了新版本卸载重装 1.70 系列立刻关闭自动更新这张表里我遇到频率最高的是第三条和第五条。第三条的坑在于授权弹窗有时候会被模拟器窗口挡住你以为没弹其实它藏在后面把窗口挪一挪就能看到。第五条的坑在于 adb reverse 在模拟器重启后失效而这个失效没有任何提示表现就是昨天还好好的今天突然连不上了很多人会往复杂的方向排查其实重跑一次转发命令就好了。7.2 运行类问题与我的踩坑记录脚本里的中文全变成乱码。这个问题我卡了半天。原因是文件保存编码不对VSCode 在某些情况下会把文件存成 GBK而 AutoX.js 按 UTF-8 解析。改法是在 VSCode 右下角点编码那一栏选通过编码保存选 UTF-8注意不要选 UTF-8 with BOM带 BOM 的头几个字节会被当成代码解析直接语法错误。同时建议在设置里加一条files.encoding: utf8和files.eol: \n固定下来后者是因为 Windows 默认换行是 CRLF某些脚本解析器对 CRLF 处理有问题。脚本跑几分钟就停。排除了代码逻辑问题之后八成是后台被杀。去模拟器设置里确认 AutoX.js 在电池优化的白名单里并且模拟器的后台进程限制不要设成不允许后台进程。还有一个更隐蔽的原因模拟器自身有个内存不足时自动清理后台的机制2G 内存分配下容易触发把内存加到 2.5G 或者减少模拟器里常驻的应用能缓解。坐标点击总是差一点。这是分辨率换算的问题。device.width拿到的值和你肉眼看到的模拟器窗口大小不一致因为模拟器有缩放。解决思路是彻底放弃坐标点击改用控件选择器// 不推荐坐标写死换分辨率就废 click(360, 640); // 推荐按文本定位自适应 text(确定).findOne(3000).click(); // 备选按 id 定位更精确 id(btn_confirm).findOne(3000).click();实在要用坐标比如操作画布、游戏界面这种没控件树的场景也要基于device.width做比例换算而不是写死绝对值let x Math.floor(device.width * 0.5); let y Math.floor(device.height * 0.8); click(x, y);模拟器启动后界面花屏、有黑块。图形渲染模式不兼容。去模拟器设置里把 DirectX 换成 OpenGL或者反过来重启模拟器看效果。这个问题在我测过的几台老集显机器上DirectX 模式的兼容性普遍更好一些。长时间运行后模拟器越来越卡、内存持续上涨。安卓应用的内存泄漏在模拟器上会被放大。我的处理办法是给脚本加个生命周期管理跑完一轮就主动释放资源并且设置一个定时重启模拟器的计划任务。比如脚本里检测到连续运行超过两小时就自行退出然后在电脑上用计划任务每天早上重启一次模拟器跑一个干净的开始。7.3 几条不太好归类但很值钱的经验先做环境快照再装东西。模拟器装好、调好参数、装完 AutoX.js、开好权限之后立刻打个快照。后面不管搞成什么样一分钟回滚。这个习惯让我少重装了至少十次环境。快照要注意一点别在脚本运行中途打快照容易抓到不一致的状态等脚本停下来再打。adb 命令全部写进批处理。手敲太容易出错尤其是一长串带-s参数的命令。把常用的几条固化下来连接、转发、推送、抓日志、重启 adb 服务。我把它们放在桌面上双击就行省下来的时间比配置它们的时间多得多。别在模拟器里装输入法。老机器上输入法会占不少内存而且在自动化脚本场景里基本用不上——你要输入文字直接用 AutoX.js 的setText()方法写进控件比模拟点击键盘快一百倍还不受输入法候选框干扰。模拟器里保留系统自带输入法就够了别装第三方的。脚本调试初期多做界面截图。AutoX.js 有截图保存的能力遇到点不到元素的问题时先截个图看看当前界面到底长什么样。很多时候问题是你以为的界面和实际界面不一样比如弹了个广告、加载了个引导页控件树里当然找不到目标。截图存到电脑上放大看比盯着模拟器小窗口强得多。给关键操作加随机延时和前置判断。纯固定 sleep 的脚本在不同机器上表现不一样老机器上慢一点就会点空。我的习惯是封装一个等待函数先判断元素是否存在存在再点同时延时加个随机浮动function safeClick(selector, timeout) { let el selector.findOne(timeout || 5000); if (el) { sleep(200 Math.random() * 300); el.click(); return true; } console.log(元素未找到跳过); return false; }这个函数在我所有脚本里都是标配把点空导致后续全乱的问题压到了最低。这套环境我从配好到现在用了小半年中间除了模拟器偶尔需要重启没有出现过大问题。真正花时间的不是配置而是配置过程中那些没有任何提示的静默失败——弹窗被挡住、端口悄悄失效、编码悄悄变成 GBK。这些坑我都写在上面的表格和段落里了你按顺序走一遍两个小时能搞定比我当时摸索两天要省事得多。最后再提一句如果你手头的机器内存只有 2G那这套方案可能撑不住建议至少在模拟器里用 Android 5.1 或者更轻量的镜像同时把 VSCode 的插件数量压到最低能跑但会比较吃力。