这个问题在红米K60上反复出现，深度分析下来，核心原因在于脚本执行流程中出现了不可中断的阻塞操作，导致脚本引擎无法响应停止指令，同时伴随无障碍服务状态异常，最终表现为“停止不了，也无法继续开始”。结合你提到的OCR技术使用，把原因拆解为以下几点：

1. OCR 调用导致脚本线程阻塞，无法处理停止信号

Hamibot 的脚本停止机制依赖于在脚本执行间隙检查停止标志。如果你的脚本在循环中调用 OCR（如 images.ocr() 或插件提供的 OCR 接口），而 OCR 是同步阻塞操作，在识别过程中：

• 脚本卡在 OCR 调用上，没有机会执行“检查是否停止”的代码。
• 你点击停止按钮时，Hamibot 只是向脚本线程发送中断信号，但线程正在等待 OCR 返回结果，无法响应。
• 结果就是“停止不了”，UI 上显示停止但脚本实际仍在运行（或僵死）。

解决方法：

• 在每次 OCR 调用前加入超时控制，避免无限等待。例如：

  // 文档地址 https://docs.hamibot.com/
  var img = images.captureScreen();
  var result = ocr.recognize(img, { timeout: 3000 }); // 设定超时
  

• 在循环中主动加入停止检查，避免在阻塞函数中长时间停留（但 OCR 调用本身阻塞时无法检查，所以需要依赖超时）。
• 降低 OCR 调用频率，例如用 sleep(1000) 在循环中给系统喘息时间，也让停止信号有机会被处理。

2. 无障碍服务（AccessibilityService）崩溃或卡死

高频的 OCR 识别往往伴随着大量截图和界面分析，这会持续消耗无障碍服务的资源。红米K60系统对后台服务有严格限制，当无障碍服务被频繁调用或内存吃紧时，系统可能：

• 杀死无障碍服务，但 Hamibot 检测到服务断开后重新拉起，反复重启导致状态混乱。
• 服务进程假死，虽然系统显示已开启，但无法响应操作，造成脚本无法继续执行，也无法正常停止。

表现为：停止按钮无效，重启脚本后无障碍服务重新绑定，一切恢复正常。

解决方法：

• 在脚本中加入无障碍服务状态检测，若发现服务异常则主动退出并提示重启。
• 降低自动化操作密度，避免连续大量截图和 OCR，给无障碍服务恢复时间。
• 在红米手机设置中，将 Hamibot 的“省电策略”设为无限制，并锁定后台，防止被系统清理。

3. 内存泄漏与资源耗尽

OCR 引擎在反复调用时可能产生内存泄漏，尤其是每次截图后未及时释放图片资源。当脚本运行一段时间后，可用内存不足，系统开始频繁回收，导致脚本进程卡死，停止命令自然无法送达。

解决方法：

• 在每次 OCR 或截图后，手动回收图片资源：

  // 文档地址 https://docs.hamibot.com/
  var img = images.captureScreen();
  var result = ocr.recognize(img);
  img.recycle(); // 释放内存
  

• 避免在循环中创建大量临时变量，使用全局变量复用。
• 监控脚本运行时的内存，如果发现持续增长，就是泄漏信号。

4. 脚本本身逻辑缺陷：循环无退出条件或死循环

“来回停止开始几次就卡死”说明脚本可能在某个循环中无法退出，比如：

• 等待某个界面元素出现，但该元素永远未出现，且没有超时跳出。
• 异常处理不当，导致流程进入不可控分支。
• 停止信号被忽略，脚本继续执行新操作，与前端状态冲突，造成无法再次开始。

解决方法：

• 所有循环和等待操作必须加上最大超时时间，超时后抛出异常或跳回主流程。
• 在关键位置增加 if (isStopped()) return; 检查，但注意如果代码卡在阻塞调用中，这个检查无效，所以优先解决阻塞问题。

总结：为什么必须重启脚本才能恢复？

因为脚本进程已经陷入不可恢复的阻塞或僵死状态，Hamibot 的停止动作只是修改了一个标志位，无法强制终止阻塞的线程。重启脚本会重新创建执行环境，清空所有状态，所以能恢复。

根治方案：

1. OCR 调用加超时，并确保每次调用都处于可中断的循环中。
2. 释放图片资源，避免内存泄漏。
3. 降低操作频率，给系统和服务恢复时间。
4. 在红米K60上关闭神隐模式，允许 Hamibot 后台无限制运行。
5. 重构脚本逻辑，所有等待必须带超时，所有循环必须响应停止信号。

按这个思路调整，卡死问题会得到本质解决。