Autox.js 脚本运行中被系统杀掉——后台保活全方案

"我啥也没干，脚本自己就停了"

这不是你的脚本坏了。大概率是 Android 系统（尤其是国产 ROM）在后台把 Autox.js 的进程杀掉了。

为什么系统会杀 Autox.js

Android 的后台管理优先级大致是：

脚本跑完、Autox.js 退到后台 → 它变成"缓存进程" → 系统随时可以杀。

全套保活方案（按推荐顺序）

1. 系统级配置（必做）

这个在「首次启用 / 后台保活」页详细讲过，这里只列清单：

• [ ] 电池优化设为无限制
• [ ] 自启动管理里设为允许自启动
• [ ] 后台弹出界面设为允许
• [ ] 安全中心省电策略里不限制 Autox.js
• [ ] 小米用户额外检查：锁屏清理白名单、后台弹出界面、通知权限

2. 脚本自身保活

v7.2.3 新增：脚本后台运行时会自动维持一个 5 秒的前台服务通知。这比普通后台进程优先级高不少。

但如果你想更激进：

// 方案 A：用 keepAlive（部分版本支持）
auto.keepAlive(true);

// 方案 B：前台服务常驻通知
auto.serviceForeground("脚本运行中");

// 方案 C：周期性唤醒
auto.setInterval(() => {
    // 每个周期做一件轻量的事
    // 比如发个空的无障碍事件，告诉系统"我还活着"
}, 60000);  // 每 60 秒

3. 避免长 sleep

// 危险：长 sleep 期间什么都不做，最容易被杀
sleep(3600000);

// 安全：短 sleep + 循环 + 轻量操作
for (let i = 0; i < 3600; i++) {
    sleep(1000);
    // 每个循环周期做一件小事
    // 比如检查一下无障碍服务是否还在
    if (!auto.service) {
        console.warn("无障碍被关了，尝试重启");
        // ... 恢复逻辑
    }
}

4. 脚本状态检测 + 自动恢复

// 检查脚本是否还活着
if (!auto.service) {
    // 无障碍没了
    toast("无障碍服务丢失，正在恢复...");
    auto.rootFolder = "/sdcard/脚本/";
    // 引导重新开启（见上一页的应急脚本）
}

5. Tasker 守护

用 Tasker 设置一个周期性检查：

Tasker 配置文件：Time → 每隔 5 分钟
  → 任务：检查 Autox.js 是否在运行
    → 如果不在 → 重新启动 Autox.js + 恢复最后一个脚本

这相当于给 Autox.js 加了一个看门狗——它自己死了，Tasker 帮它拉起来。

6. 锁屏时的特殊处理

锁屏是脚本最容易被杀的时刻。解决方案：

// 方案 A：脚本里保持屏幕常亮
auto.setInterval(() => {}, 5000);  // 保持主线程活跃

// 方案 B：允许脚本在锁屏状态下继续运行
// v7 可能需要在设置里开"锁屏继续运行"

更彻底的方式：用 Tasker 监听锁屏事件 → 锁屏时自动亮屏（或保持 Autox.js 前台）。

实战：签到脚本 7x24 运行的完整配置

系统层

1. Autox.js 加电池白名单、自启动、后台弹出界面
2. Tasker 加电池白名单、自启动

Tasker 层

1. 每日 09:00 触发签到脚本
2. 每 10 分钟检查 Autox.js 进程 → 死了就重启
3. 每 30 分钟检查签到是否完成 → 没完成就补跑

脚本层

1. 脚本开头先检查无障碍 → 没开就引导开启
2. 签到后上报结果到服务器
3. 用短 sleep + 循环，不用长 sleep

结果

1. 手机重启 → Autox.js 自启动 → Tasker 自动恢复触发器
2. 某天 09:00 → Tasker 触发签到脚本 → 执行 → 上报 → 完成
3. 中途如果被杀 → Tasker 10 分钟内拉起 → 检查是否完成 → 补跑

总结

四层叠加起来，脚本的生存率从"可能半小时就死"提升到"7x24 稳定运行"。