企业官网建设流程全解析

Alas 自动化脚本低配机性能优化：三步砍半 CPU 占用

【免费下载链接】AzurLaneAutoScriptAzur Lane bot (CN/EN/JP/TW) 碧蓝航线脚本 | 无缝委托科研，全自动大世界项目地址: https://gitcode.com/gh_mirrors/az/AzurLaneAutoScript

凌晨三点被笔记本风扇声吵醒，你摸黑看了一眼屏幕：AzurLaneAutoScript 还挂在委托和日常上，模拟器却把 CPU 干到了 90%，任务列表一片灰，整台机器像一台正在煮开水的热水壶。这套碧蓝航线自动化脚本的活其实不重——截图、比对、点击，循环往复——但如果你用的是老机器，默认的保守配置会把每一点算力都浪费在"过度谨慎"上。

在动手改配置之前，先判断你的设备属于哪一档 🖥️

读完这篇文章，你能拿到三个结果：找到你这套模拟器的最优截图通道；把每帧图像处理的负担降到最低；让任务队列在空闲时真正歇下来。

第一步：给模拟器选一条更快的"截图通道"

脚本每秒都在干同一件事：截图 → 找按钮 → 点击。截图方式（Alas.Emulator.ScreenshotMethod）决定了这条流水线里最贵的一环有多贵。它默认是auto，会自动挑一个能用最久的稳妥通道，但未必是最快的。各通道的取舍大致如下，可在配置文件的Alas.Emulator节点下显式指定，各通道的实现都在 module/device/method/ 目录里，文件名即通道名：

怎么改：在配置文件里把ScreenshotMethod从auto改成你对应的那一行，重启脚本后观察日志里的截图耗时。改完怎么验证：任务管理器里 Alas 进程的 CPU 占用，低配档挂机应稳定在 30% 以下；如果日志频繁出现截图超时或RequestHumanTakeover，说明该通道在你的环境里不通，退回auto或换上一档速度次优的通道。MuMu 用户还有一个隐藏前提：模拟器设置里的"后台挂机时保活运行"和网络桥接都要关掉，脚本启动时检测到开启会直接报错停下，这个提示别忽略。

通道选对了，下一步就是把图像处理本身做薄。

第二步：把每帧截图的处理负担做薄

截图只是原料，脚本拿到图之后还会做降噪、旋转、匹配、OCR。每一帧都有机会被"白干"，下面三个开关都能独立生效。

关掉截图降噪：Alas.Emulator.ScreenshotDedithering默认已经是false。它的作用是抹掉低质量通道的噪点，但代价是每帧多花 40~60ms——如果你的截图通道本身就是干净的（nemu_ipc、ldopengl这类），降噪纯属重复劳动。确认它是false即可，别开。

拉长截图间隔：脚本不是越勤快越好，两次截图之间游戏画面往往没变。Alas.Optimization.ScreenshotInterval默认 0.3 秒，意思是"两次截图至少隔 0.3 秒"。委托、宿舍这类慢节奏任务，把它放到 0.5~1.0 完全安全；战斗中的CombatScreenshotInterval建议保持在 1.0 左右，战斗中状态变化快，别拉太长。

让空队列真正空下来：Alas.Optimization.WhenTaskQueueEmpty控制"没活干时干什么"，可选stay_there（原地待命）、goto_main（回主界面）、close_game（直接关游戏）。低配档挂机过夜推荐goto_main：回到主界面后游戏自身也会降频，脚本这边则进入低频轮询。下面这个片段把第二步的改动集中放在一起，照着改 argument.yaml 里对应项即可：

Alas: Emulator: ScreenshotMethod: ADB_nc ScreenshotDedithering: false Optimization: ScreenshotInterval: 0.5 CombatScreenshotInterval: 1.0 WhenTaskQueueEmpty: goto_main

改完怎么验证：观察日志里截图动作的频率（截图间隔拉长后，日志密度会肉眼可见地变稀），以及模拟器窗口的刷新是否有明显卡顿。委托、日常这类任务跑一轮总时长增加几秒到十几秒是正常的，换来的是 CPU 的持续降温。

模板匹配是脚本的"眼睛"：上面这种带按钮框的模板，脚本只在框内区域找目标，区域越小算得越快——这也是官方模板都裁剪得又小又准的原因。

第三步：控制任务调度的节奏

截图是高频开销，而任务调度决定了高频操作"多久触发一次"。Alas 的调度器像一个电梯楼层面板（状态机）：每个模块（委托、科研、大世界）都是独立楼层，各自有启用开关和等待节奏，互不抢楼层。低配机上最容易踩的坑是全开：所有 Scheduler 都挂着，加上大世界守护（module/daemon/ 目录下的 Opsi 相关模块）常驻，等于让脚本同时盯着五个楼层。

节奏的取舍可以这样想：

具体做法：把暂时不需要的大世界、活动模块的 Scheduler 关掉，只留委托、科研、宿舍这类日常刚需；大世界只在实际开荒或冲分的那几天再开。每个模块的开关都在各自Scheduler.Enable下，默认全是true，这就是"全速巡航"的由来。

战斗模块的自动战斗图标识别是截图间隔最敏感的环节，CombatScreenshotInterval就是为它单独设的旋钮。

改完怎么验证：连续挂机一夜，次日看日志里各模块的执行时间戳，日常模块的完成时间应该和手动操作差不多；任务管理器里 Alas 的 CPU 占用在空闲时段应回落个位数，跑任务时才周期性爬升——这是健康形态。

OCR 读资源数量（如图中的石油读数）只在需要时才触发，本身开销不大；真正吃 CPU 的是"截图太密 + 每帧都处理"，前两节已经解决了。

改了还是卡？快速自检清单

配置都对但体验没改善，大概率是系统层的问题：

• ✅ 模拟器分配的核心数 ≤ 主机物理核心数的一半，内存 ≤ 主机的一半
• ✅ 没有同时跑两个模拟器实例或多开引擎
• ✅ 浏览器、视频类后台程序已关，电源计划切到"高性能"
• ❌ 截图间隔拉到 2.0 以上还卡 → 检查是否卡在 OCR 或网络请求，看日志最后停在哪一步
• ❌ 日志反复出现重试（adb_reconnect之类）→ 通常是 ADB 通道不稳，开Emulator.AdbRestart或重启模拟器再试

长期挂机的维护节奏

维护不用勤，但要固定：每 12~24 小时重启一次脚本，释放截图缓存累积占用的内存（Alas 会在Error_SaveError开启时把最近的截图存进一个环形队列，长度由Error.ScreenshotLength控制，默认只留 1 张，别调大）。日志目录定期清理，保留最近三天的就够；模拟器自身的缓存和"保活运行"开关也值得每周扫一眼。配置改完记得完整重启一次脚本，很多通道和调度选项只在启动时生效。

现在，凌晨三点的风扇终于可以安静转了——你只需要在它偶尔发出蜂鸣时，看一眼日志确认它还在正常跑日常就行。

【免费下载链接】AzurLaneAutoScriptAzur Lane bot (CN/EN/JP/TW) 碧蓝航线脚本 | 无缝委托科研，全自动大世界项目地址: https://gitcode.com/gh_mirrors/az/AzurLaneAutoScript