
Alas 自动化脚本低配机性能优化三步砍半 CPU 占用【免费下载链接】AzurLaneAutoScriptAzur Lane bot (CN/EN/JP/TW) 碧蓝航线脚本 | 无缝委托科研全自动大世界项目地址: https://gitcode.com/gh_mirrors/az/AzurLaneAutoScript凌晨三点被笔记本风扇声吵醒你摸黑看了一眼屏幕AzurLaneAutoScript 还挂在委托和日常上模拟器却把 CPU 干到了 90%任务列表一片灰整台机器像一台正在煮开水的热水壶。这套碧蓝航线自动化脚本的活其实不重——截图、比对、点击循环往复——但如果你用的是老机器默认的保守配置会把每一点算力都浪费在过度谨慎上。在动手改配置之前先判断你的设备属于哪一档 ️档位典型配置典型症状本文策略低配档i3 / 核显 / 8GB 内存挂机时整机卡顿浏览器都打不开截图换快通道 拉长截图间隔中配档i5 / 8GB 内存跑大世界时风扇狂转但日常流畅关闭多余图像处理调调度节奏高配档i7 / 16GB 以上基本无感只关掉没用到的选项即可读完这篇文章你能拿到三个结果找到你这套模拟器的最优截图通道把每帧图像处理的负担降到最低让任务队列在空闲时真正歇下来。第一步给模拟器选一条更快的截图通道脚本每秒都在干同一件事截图 → 找按钮 → 点击。截图方式Alas.Emulator.ScreenshotMethod决定了这条流水线里最贵的一环有多贵。它默认是auto会自动挑一个能用最久的稳妥通道但未必是最快的。各通道的取舍大致如下可在配置文件的Alas.Emulator节点下显式指定各通道的实现都在 module/device/method/ 目录里文件名即通道名ScreenshotMethod适用场景速度稳定性备注auto拿不准时中高默认值优先兼容性ADB_nc大部分模拟器快高比裸 ADB 少一层压缩通用首选aScreenCap_nc雷电 / 夜神等较快中模拟器自带截屏接口nemu_ipcMuMu 12最快中MuMu 私有通道版本要够新ldopengl雷电 9 及以上快中雷电专属 OpenGL 直出怎么改在配置文件里把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创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考