老机器上折腾安卓自动化脚本这件事，我前前后后踩了差不多两个月的坑。手头这台机器还是当年的配置，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 三种方案横向对比与我的取舍

我把当时考虑过的三条路整理成一张表，方便你对照自己的情况做决定。

我选第三条路的核心理由，其实不是"省资源"，而是可回滚。脚本跑飞了、误删了系统目录、把模拟器搞成砖，真机上你得重刷或者恢复出厂，模拟器上直接删掉重建，两分钟搞定。做自动化脚本调试的时候，这种"随便折腾"的底气非常重要，因为你写的东西本来就是在操作界面，很容易把环境搞乱，比如误触到设置里改了输入法、关掉了某个系统服务。模拟器快照就是你的后悔药。

另外还有个隐性好处：模拟器的分辨率和 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（按 Ctrl+Shift+P 搜 "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 didn't ACK或者干脆启动即退出。我的经验是优先试 31.x 和 33.x 这两个大版本，能连上就别乱升级。判断标准很简单：解压后在该目录打开命令行，敲adb version，能正常打印版本号并且不报错，就说明能跑。如果报缺少 DLL，说明这个版本要的系统组件你机器上没有，直接换低一档的版本。

还有一个隐藏问题：多个 adb 版本共存会打架。如果你之前装过某个手机助手类软件，它自带一份 adb，并且把自己的路径写进了环境变量，你新解压的 adb 和它版本不一致时，就会看到那个经典报错：

adb server version (41) doesn't match this client (39); killing...

处理方法有两种，任选其一。省事的做法是把自己的 adb 目录加到环境变量最前面，并且把其他 adb 目录从 PATH 里删掉；彻底的做法是找到旧 adb 进程，taskkill /f /im adb.exe全部干掉，然后只用自己那一份。我建议走彻底路线，因为这个报错会反复出现，每次都要处理很烦。

2.3 系统补丁与运行库补齐清单

Win7 SP1 原版系统直接装这些东西大概率会缺组件，我把必须补的列一下，装之前先打个勾：

最后一条 SDK 1.2 这个问题特别隐蔽。表现是：VSCode 里按 Ctrl+Shift+X 打开扩展面板，输入插件名搜索，转圈转半天最后提示"无法连接"。你会以为是网络问题，其实是系统的加密协议栈太老，对方服务器已经不支持了。补法是导入一个注册表文件：

Windows Registry Editor Version 5.00 [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings\WinHttp] "DefaultSecureProtocols"=dword:00000a00

导入后重启，再去扩展面板搜插件就能正常出结果了。这个坑我在两个不同的老机器上都遇到过，值得单独记一笔。

3. 雷神模拟器的安装与老机器专项调优

3.1 装之前的硬件条件确认

装模拟器之前必须确认一件事：CPU 虚拟化有没有开。这一步不做，模拟器只能靠软件模拟 CPU 指令，性能会掉到令人发指的程度——开机等五分钟，点一下卡三秒，完全没法用。而且这种情况下你会误以为是机器太老，其实是没开虚拟化。

确认方法：打开任务管理器（Ctrl+Shift+Esc），切到"性能"标签，看 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 的老机器：

渲染模式这一项值得单独说。模拟器一般提供 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"只是最常见的约定，雷神模拟器实际用的可能不是这个。别猜，直接查。

先找到模拟器的进程 PID：

tasklist | 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。

按Ctrl+Shift+P打开命令面板，输入Auto.js: Start Server，回车。底部状态栏会显示服务已启动，端口 9317。如果提示端口被占用，说明有别的东西占着，换个端口，同时记得把 adb reverse 的目标端口也改掉，两边必须一致。

然后新建一个文件，写第一个测试脚本：

// test.js toast("链路已打通"); console.log("当前设备分辨率：" + device.width + " x " + device.height);

保存为 UTF-8 编码（右下角状态栏能看到编码，点一下可以改），然后按Ctrl+Shift+P输入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": [] } ] }

按Ctrl+Shift+B就能执行。${workspaceFolder}是 VSCode 的内置变量，指向当前打开的工程根目录，这样换了机器路径也不用改配置。

推送完再执行运行命令。整个流程就是：改代码 → Ctrl+S 保存 → Ctrl+Shift+B 推送 → 命令面板 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 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 的插件数量压到最低，能跑但会比较吃力。