手上这台 2013 年的老笔记本，内存加到 8G，硬盘换成一块便宜固态，系统一直停在 Win7。它现在跑不动主流开发工具链了，但用来开安卓模拟器、写 AutoX.js 自动化脚本，居然还能用，而且用顺手之后并不觉得多难受。这套 VSCode + AutoX.js + 安卓模拟器的组合，我在它上面反复装过七八次，每次重装都会踩到几乎一模一样的几个坑：编辑器版本装太新直接打不开、插件服务端起来了设备连不上、模拟器一开就卡成幻灯片。下面把这些东西按我实际的安装顺序摊开讲一遍，该锁版本的锁版本，该关的开关关掉，能少走不少弯路。

1. Win7 老机器上这套组合到底能干什么

先说清楚这套环境是干什么用的，避免有人装到一半才发现不符合预期。VSCode 是写代码的地方，负责编辑、管理文件、启动调试服务；AutoX.js 是跑在安卓设备上的自动化框架，它提供无障碍服务、控件查找、坐标点击、文字输入这些能力；安卓模拟器则是那台“设备”，相当于你手边的一台安卓手机，只不过是用电脑的 CPU 和内存模拟出来的。三者通过一个 TCP 端口连起来，编辑器改完文件，设备端立刻能拉到新代码执行，这个循环跑通了，写脚本的效率才谈得上。

1.1 编辑器、框架、运行载体各自的分工

很多人第一次接触会混淆，以为 AutoX.js 是个电脑软件。不是的，它分两半：一半是装在安卓系统里的 APK，负责真正执行脚本、调用无障碍接口；另一半是电脑端的 VSCode 插件，负责提供代码补全、把脚本推送到设备、把设备上的日志回传到编辑器。模拟器只是“安卓系统”的一个载体，你用真手机接 USB 也能干同样的事，只不过老机器上模拟器更方便，不用来回插线，也不用担心真机被脚本点坏。

理解这个分工很重要，因为它决定了你出问题时该往哪边找。连不上设备，问题可能在插件服务端、可能在网络端口、也可能在模拟器内部的 APK 没启动；脚本点了没反应，问题可能在控件查找逻辑、也可能在无障碍服务被系统杀掉。搞清楚哪一层出的问题，排查时间能省一大半。

1.2 真正的性能瓶颈不在 CPU 主频

老机器跑这套环境，直觉上会以为是 CPU 太弱。实际测下来，卡顿的主因往往排序是这样的：内存不足导致的频繁换页 > 机械硬盘的随机读写 > 集显的渲染能力 > CPU 单核性能。模拟器吃内存是大头，一个 720P 的安卓实例，光系统本身就要吃掉 1G 到 1.5G；VSCode 再吃掉 500M 到 800M；Win7 自己还要留一部分。8G 内存是这套组合的舒适线，4G 内存会非常难受，因为一旦开始换页，模拟器和编辑器会互相拖累，表现出来就是“打字延迟半秒、模拟器画面一顿一顿”。

所以如果你的机器还是机械硬盘，先换固态，这一步的收益比任何软件调优都大。这不是玄学，模拟器的磁盘镜像和 VSCode 的扩展缓存都是大量小文件随机读写，机械盘在这种场景下的体验是灾难级的。

1.3 一条硬约束：所有组件都要往回锁版本

这是整篇文章最核心的一句话。Win7 已经不在很多软件的官方支持列表里了，你如果按官网首页的“Download”按钮下载最新版，大概率装完就打不开，或者打开后一堆功能缺失。VSCode、Node、安卓平台工具，每一个都有“最后一个支持 Win7 的版本”这个门槛，跨过去就是各种莫名其妙的报错。下面我把这条线划清楚，剩下的章节都建立在这个基础上。

2. 版本选型：Win7 上能跑的最后一批工具链

这一节是整篇的地基，地基打歪了后面全是返工。我见过最典型的情况是：照着某篇教程装了最新版编辑器，结果双击图标毫无反应，或者弹一个缺少 api-ms-win-crt-xxx.dll 的对话框，然后开始怀疑是不是系统缺补丁。实际上多半就是版本选错了。

2.1 编辑器版本卡在哪一档才不报缺 DLL

VSCode 在 1.7x 系列之后就不再支持 Win7 了，官方公告里明确说过某个 1.7x 的版本是最后一个兼容 Windows 7 / 8 / 8.1 的版本，再往后需要 Windows 10 以上。所以你要做的是去下载页面的历史版本区，找一个 1.7x 系列的安装包，最好是那个“最后一个兼容版本”。装完之后第一件事是在设置里把自动更新关掉，否则它某天偷偷升级，你第二天打开就发现软件没了。

除了编辑器本体，Win7 上还经常缺一个通用 C 运行库补丁。表现是双击图标什么都不发生，或者提示找不到某个系统 DLL。这个补丁在系统更新里能搜到，装上重启即可。判断方法很简单：如果安装程序本身能跑完，但装完的软件起不来，先怀疑运行库，再怀疑版本不兼容。

2.2 Node 和 adb：不是越新越好

Node 在这套环境里其实不是必需品。如果你只用 VSCode 插件推送代码到设备，插件本身运行在编辑器的扩展宿主里，不需要你在系统里另外装一个 Node。什么时候需要？当你要用命令行工具做打包、做本地语法检查、跑一些构建脚本的时候。真要装，12 或 14 的 LTS 分支比较稳，新版本在 Win7 上可能直接报缺少某个系统 API，装完 node -v 都跑不出来。

adb 是另一回事，它是连接电脑和安卓设备的桥梁。这里有个经典冲突：模拟器安装目录里自带一份 adb，你如果又在别处装了一份安卓平台工具，两份不同版本的 adb 同时抢 5037 端口，表现就是“一会儿能连、一会儿连不上”，设备列表里多出一堆 offline 状态的幽灵设备。我的做法是统一用模拟器自带的那份，把它的目录加到系统环境变量里，别的地方装的 adb 全部从 PATH 里挪走。想确认当前用的是哪一份，敲where adb就一目了然。

2.3 模拟器实例的低配化参数

新建实例的时候有几个参数必须手动调，默认值对老机器太奢侈。分辨率选 720x1280、DPI 320 这一档就够了，脚本里做点击和控件查找完全够用，还能省下大量显存。CPU 核心数给 2 核，别贪心给 4 核，因为模拟器的多核调度在老 CPU 上反而会互相抢占，实测 2 核比 4 核更跟手。内存在 8G 物理内存的机器上给 2048M 是上限，给多了宿主机会开始换页。帧率限制在 30 帧，这个对脚本执行没有任何影响，纯粹是给渲染减压。

还有两个容易被忽略的：关闭声音输出，关闭自动旋转和传感器模拟。前者省一点 CPU，后者能避免脚本跑着跑着画面转了 90 度导致坐标全错。这些设置在实例配置里都能找到，新建时就设好，省得后面改完还要重建。

3. 把编辑器和模拟器连起来的那一段

这一节是最容易卡住人的地方，也是各类教程语焉不详的部分。连接的本质很简单：插件在电脑上起一个监听服务，模拟器里的 AutoX.js 主动去连这个服务。听起来一句话的事，实际会因为网络模式、端口占用、服务没启动等原因卡住。

3.1 插件安装与服务端启动的正确姿势

在扩展面板里搜插件，注意要装 AutoX.js 对应维护的那个版本，别装成好几年前停更的旧版。旧版插件的命令前缀、配置项、推送逻辑都可能和新版框架对不上，表现出来就是“连上了但推不过去代码”。装完之后重载窗口，然后按 Ctrl+Shift+P 打开命令面板，输入插件命令的关键字，找到启动服务的那一项执行。服务起来之后，编辑器右下角或者输出面板里一般会有提示，告诉你监听的端口号，默认是 9317。

这时候先去验证服务真的在监听，别急着开模拟器。打开命令行敲netstat -ano | findstr 9317，如果能看到一行 LISTENING，说明服务起成功了；如果什么都没有，说明插件没起来或者被防火墙拦了。这一步花十秒，能省掉后面半小时的瞎猜。

3.2 模拟器里连不上宿主机的三种可能

第一种可能是 IP 填错了。模拟器里的 AutoX.js 要求你填“电脑的地址”，很多人填了 127.0.0.1，以为是指自己。不是，这个 127.0.0.1 在模拟器内部指向的是模拟器自己，你要填的是宿主机的局域网地址，用ipconfig查一下当前网卡的 IPv4 地址填进去。注意别填成虚拟网卡（比如某些虚拟化软件创建的网段）的地址，那种地址模拟器往往访问不到。

第二种可能是防火墙。Win7 的防火墙对入站连接默认是拦的，插件起的服务监听在本地端口上，模拟器从“外部”连进来的时候会被判定为入站流量。临时关掉防火墙测一次，如果能连上就说明是这个问题，然后把那个端口加进例外规则，别长期关防火墙。

第三种可能是模拟器的网络模式。绝大多数模拟器的默认 NAT 模式是能访问宿主机局域网地址的，但个别版本或者开了某些网络优化选项后会隔离。这时候有个更可靠的办法：用 adb 做反向端口转发。在命令行执行adb reverse tcp:9317 tcp:9317，它的作用是把模拟器内部的 9317 端口反向映射到宿主机的 9317 端口，然后你在模拟器里填 127.0.0.1:9317 就能连上了。这个命令要求安卓 5.0 以上，现在基本都满足。连接成功后记得把这个命令记下来，模拟器重启后转发会失效，需要重新执行。

3.3 端口被占用时的排查顺序

9317 被占用是常见情况，尤其是你之前开过别的编辑器窗口、或者上次的服务没退干净。症状是启动服务时插件报错、或者服务起来了但设备连上就断。排查顺序我一般是这样：先netstat -ano | findstr 9317拿到占用进程的 PID，再tasklist | findstr 那个PID看是哪个程序，如果是残留的编辑器进程就杀掉重开。

还有一种隐蔽的情况：服务起来了，端口也在监听，但连上之后推送代码特别慢、甚至超时。这种时候去看看是不是装了别的抓包类、代理类软件在中间插了一手，或者系统的网络栈被某些安全软件挂了一层过滤驱动。临时退出这些软件测一次，能定位得很快。

4. 工程目录和项目骨架怎么搭才不返工

连接跑通之后，接下来的问题是代码怎么组织。我见过不少人所有逻辑全塞在一个入口文件里，写到两三百行就开始崩溃：改一个点击逻辑要上下翻半天，公共函数复制粘贴三份，改一处漏两处。这套环境虽然轻量，但工程结构该有的还是要有的。

4.1 配置文件和入口文件的约定

AutoX.js 的项目一般有一个 json 配置文件放在根目录，描述项目名、版本号、入口文件、启动配置这些信息。入口文件默认叫 main.js，框架启动时会从这里开始执行。配置文件里有个字段控制启动时是否显示日志浮窗，调试阶段建议打开，跑稳定了再关掉。字段名在不同版本之间可能有细微差异，最稳妥的办法是先在设备上用框架自带的“新建项目”功能生成一份模板，把它拉到电脑上照着改，比自己凭空写靠谱。

入口文件我习惯写得很薄，只做三件事：初始化环境、按顺序调用业务模块、最外层套一个异常捕获。这样任何模块里抛错，都能在最外层统一记录下来，而不是整个脚本静默死掉，让你对着黑屏猜发生了什么。

// main.js 只做调度，不写业务 const task = require("./modules/task"); try { auto.waitFor(); // 等待无障碍服务就绪 task.run(); } catch (e) { console.error("主流程异常: " + e); toast("脚本异常退出，请查看日志"); }

4.2 模块拆分与公共工具函数的位置

我一般拆成三层：modules放业务流程，utils放通用工具，config放常量和选择器。通用的东西包括：带超时的等待、带重试的点击、截图存证、日志落盘。这里面最值得先写的是“带重试的点击”，因为脚本失败十次里有八次是元素还没出来就点了。

// utils/ui.js function waitAndClick(selector, timeout) { timeout = timeout || 8000; const el = selector.findOne(timeout); if (!el) { console.warn("未找到元素: " + selector); return false; } return click(el.bounds().centerX(), el.bounds().centerY()); } module.exports = { waitAndClick: waitAndClick };

注意这里用的是控件的中心坐标去做点击，而不是直接调用控件的 click 方法。两种方式各有适用场景：控件自身的 click 依赖它是否可点击，有些容器控件看着能点其实不行；坐标点击更粗暴但更通用。我通常在控件可点击时优先用控件方法，不可点击时退回坐标，两者结合着用。

4.3 保存即生效的调试循环

连接跑通后，插件提供了一条很爽的工作流：编辑器里保存文件，插件把改动推送到设备，设备端重新加载脚本。老机器上这条链路会慢一点，但慢在哪里要搞清楚。如果是推送慢，多半是设备端在重新解析整个项目的所有文件，可以把不参与运行的文件（文档、备份、截图）排除掉；如果是执行慢，那是脚本本身的问题，跟环境无关。

调试阶段我建议打开日志回传，让设备上的 console 输出直接出现在编辑器的输出面板里。这比在模拟器里看浮窗舒服得多，尤其是浮窗挡住界面的时候。等脚本跑稳了再关掉，因为日志回传本身也要占一点资源。

5. 让老电脑跑得动：两边同时瘦身

环境搭好只是能用，要用得顺手还得做一轮减法。老机器上每一份资源都得掰着用，VSCode 和模拟器两边都要减。

5.1 编辑器侧的六个开关

编辑器的资源大头在文件监视、语法高亮的语言服务和扩展宿主上。我的做法是：关掉缩略图，关掉自动更新和扩展自动更新，关掉遥测，关掉启动时的欢迎页，把不用的扩展全部禁用（尤其是那种装了一堆语言包的，每个都常驻一个进程），再把项目目录之外的大文件夹加进监视排除列表。

{ "editor.minimap.enabled": false, "update.mode": "none", "extensions.autoUpdate": false, "telemetry.telemetryLevel": "off", "workbench.startupEditor": "none", "files.watcherExclude": { "**/node_modules/**": true, "**/backup/**": true, "**/*.log": true } }

还有一个针对老显卡的技巧：用命令行参数启动编辑器时加一个禁用硬件加速的开关。集显驱动在老系统上对基于 Chromium 的界面支持经常出问题，表现是窗口拖动有残影、滚动卡顿。禁掉 GPU 加速之后反而更顺，代价是滚动动画没那么丝滑，但对写代码毫无影响。这个参数怎么加，取决于你用快捷方式还是命令行启动，快捷方式就在目标路径后面追加。

5.2 模拟器侧的性能取舍

模拟器的性能设置里有两个参数最值得调：一是渲染模式，如果默认模式画面撕裂或者卡顿，换成另一种（软件渲染和硬件渲染之间切换）试试，老集显上经常是软件渲染反而稳；二是帧率上限，压到 30 甚至 24，肉眼看着还行，脚本执行完全没影响。

另外把“开机自启”“后台保活”这类选项都关掉。老机器上最怕的就是一堆东西常驻后台，等你真正要干活的时候发现可用内存只剩几百兆。用的时候开，不用就关，别图省事常驻着。

5.3 系统层面还能挤出来的一点空间

Win7 上能做的事情不多但有效：把视觉特效里的动画、阴影、透明效果关掉，切到性能优先的模式；关掉系统索引服务对项目目录的扫描；把虚拟内存设成固定大小而不是系统托管，避免运行时动态扩容造成的卡顿。这三件事做完，整体响应会有一个可感知的提升。

还有一条容易被忽略：不要在脚本运行时同时开浏览器。现代浏览器是内存黑洞，一个标签页几十上百兆，开着它跑模拟器，卡顿立刻找上门。

6. 实战中最容易翻车的几个具体点

前面都是准备工作，真正跑起来之后遇到的坑才叫坑。下面几个是我反复踩过、并且确定有解法的。

6.1 无障碍服务被系统悄悄回收

AutoX.js 依赖安卓的无障碍服务，而模拟器为了省内存，会在后台把长时间不活动的服务回收掉。症状是脚本跑到一半突然所有控件查找都返回空，日志里啥也没有，看着像代码逻辑错了。判断方法很简单：脚本卡住的时候手动去系统设置里看一眼无障碍服务开关，如果自己关掉了，那就是被回收了。

解法有两层：一是脚本入口加上等待无障碍就绪的逻辑，并且在外层做一个定时检查，发现服务断了就重新启动脚本；二是把模拟器的省电策略调成不限制，把 AutoX.js 加进白名单。老机器内存紧张的时候这个现象会更频繁，所以内存分配别抠太死。

6.2 文字输入和坐标漂移

用坐标点击输入框然后模拟按键输入，在真机上通常没问题，在模拟器上经常翻车，因为模拟器的输入法弹窗高度和真机不一样，软键盘弹出来之后整个界面被顶上去了，你算好的坐标全部偏移。表现就是“点了输入框，然后点到了键盘上”。

我的做法是彻底放弃坐标输入这条路，改用控件级的设置文本方法。先用选择器定位到输入控件，直接设置文本，绕开软键盘。如果控件本身不支持设置文本（比如某些自绘的输入框），再退回坐标方案，但要在弹键盘之后重新获取一次界面尺寸做补偿。

坐标漂移的另一个来源是分辨率不一致。脚本里千万不要写死 1080 这样的绝对坐标，用设备宽度和高度的比例来算，换设备或者换分辨率才不会全乱。

6.3 时序问题：那种“看起来没问题”的偶发失败

这类问题最折磨人。脚本跑十次成功九次，失败的那一次你盯着日志看半天，逻辑完全正确。本质上是等待时间不够，只是大部分时候刚好够。老机器上模拟器响应慢，这种偶发失败率会明显升高。

对策不是无脑加大等待时间，那样脚本会变得又慢又脆。正确的做法是把“固定等待”换成“条件等待”：等待某个元素出现，出现就继续，超时才报错。再配一个带退避的重试，第一次失败等 500 毫秒重试，第二次等 1 秒，最多重试三次。这样正常情况下的速度不受影响，异常情况也能自愈。

6.4 我自己的一套排查顺序

遇到“脚本不动了”，我现在的排查顺序固定是这样，基本五分钟内能定位：

1. 先看设备上的无障碍服务还在不在，这是最高频的原因。
2. 再看编辑器输出面板有没有日志回传，没有日志说明连接断了，去查端口。
3. 连接正常但没日志，说明卡在某个阻塞调用上，比如 findOne 一直等不到元素。
4. 这时候截个图看看当前界面长什么样，八成是弹了个意料之外的对话框。
5. 界面正常但逻辑不对，就把选择器单独拎出来测一次，看看是不是界面改版导致控件变了。

这个顺序之所以有效，是因为它按“出现问题的概率”从高到低排。别一上来就怀疑代码逻辑，绝大多数时候代码是对的，是环境或者界面变了。

6.5 关于备份这件小事

最后说个不出问题但很重要的习惯：每次跑通一个稳定版本，就把整个项目目录复制一份出来，带上日期。老机器磁盘不稳、模拟器镜像偶尔损坏、编辑器插件升级后配置被覆盖，这些事我都遇到过，有一次辛苦调了两天的选择器逻辑因为模拟器重建全丢了。现在我的习惯是每天收工前备份一次，成本几乎为零，救命的次数不少。

我在实际使用中的体会是，这套环境真正难的不是配置本身，而是所有组件都在一条“勉强还能用”的线上，任何一个环节版本跳出去都会连带崩掉。所以一旦跑通，就别再动了，把自动更新全部关掉，把版本号记在一个文本文件里放在项目根目录，下次重装的时候照着装一遍，二十分钟就能复原。这比每次重新摸索要划算得多。