1. 为什么我最终选择了 Alas 来做碧蓝航线日常
碧蓝航线这游戏，玩过的都懂——日常、周常、大世界、科研、委托、演习、活动图，一天不落全清完，没两个小时下不来。我算是比较早一批开始琢磨自动化的玩家，从最早的按键精灵脚本，到后来各种模拟器自带的操作录制，再到 Auto.js 和 Airtest 这类通用自动化框架，基本都折腾过一轮。最后稳定在 Alas 上，不是因为它功能最全，而是因为它在“碧蓝航线”这个垂直场景里，把该做的脏活累活全做完了，而且部署门槛比想象中低得多。
Alas 本质上是一个针对碧蓝航线的自动化调度框架，底层跑在模拟器上，通过图像识别和预设逻辑来驱动游戏完成一系列重复操作。它解决的核心问题就一个：把玩家从每天重复的机械点击里解放出来，同时保证稳定性和可配置性。适合谁来参考？如果你有一台能跑模拟器的电脑，愿意花五分钟做一次部署，之后基本就是点一下启动的事。哪怕你之前没碰过任何自动化工具，只要照着步骤走，也能跑起来。
我见过太多人卡在“部署”这一步就放弃了，网上教程要么太老，要么跳步严重，要么默认你已经懂 Python 环境和 ADB 调试。这篇东西就是把我自己反复部署、迁移、重装过程中踩过的坑和验证过的流程整理出来，让你少走弯路。
2. 部署前的环境准备与核心思路拆解
2.1 为什么是模拟器 + Alas 这套组合
Alas 本身不直接跑在手机上，它需要一个 Android 运行环境作为载体。市面上主流方案有三种：物理手机、云手机、本地模拟器。物理手机需要一直插着电、开着开发者调试，长期跑对电池和屏幕都不友好；云手机延迟高、画面压缩严重，图像识别容易翻车；本地模拟器是综合成本最低的选择，画面稳定、ADB 连接可靠、性能可控。
模拟器选型上，我实测下来比较稳的是 MuMu 模拟器 12 和雷电模拟器 9。这两个对碧蓝航线的兼容性都不错，ADB 调试端口开放明确，而且支持多开。BlueStacks 也不是不能用，但它的 ADB 端口经常变，Alas 配置起来会多一步排查。夜神模拟器老版本还行，新版本广告太多，后台进程干扰大，不太推荐。
注意：模拟器版本尽量选稳定版，不要追最新 beta 版。我吃过一次亏，雷电更新到某个内测版之后 ADB 端口从 5555 变成了随机端口，Alas 死活连不上，回退版本才解决。
2.2 硬件与系统的最低要求
Alas 对硬件的要求其实不高，但“能跑”和“跑得稳”是两回事。我整理了一个对照表，你可以根据自己的机器情况判断：
| 配置项 | 最低能跑 | 推荐稳定运行 | 说明 |
|---|---|---|---|
| CPU | 4 核 | 6 核以上 | 模拟器吃单核性能，主频比核心数重要 |
| 内存 | 8GB | 16GB | 模拟器分配 4GB，Alas 本体占用不大 |
| 硬盘 | 机械硬盘 | SSD | 模拟器镜像加载速度差距明显 |
| 显卡 | 核显 | 独显 | 影响模拟器渲染流畅度，间接影响识别率 |
| 系统 | Win10 | Win10/11 64位 | 部分老版本 Win7 缺依赖 |
我自己的主力机是 R7 5800H + 32GB 内存 + SSD，模拟器分配 4 核 4GB，Alas 跑起来 CPU 占用大概在 15% 到 25% 之间波动，内存占用 1GB 出头。如果你用的是老笔记本，建议把模拟器分辨率调到 1280x720，帧率限制 30 帧，能明显降低负载。
2.3 部署 Alas 的三种方式对比
Alas 的获取方式主要有三种，我分别说一下适用场景：
- 整合包：网上有人打包好的免安装版本，解压即用。优点是省事，缺点是版本可能滞后，而且来源不明的整合包有安全风险，我不太推荐。
- 源码部署：从代码仓库拉取最新代码，自己装依赖。优点是版本最新、可控性强，缺点是需要一点 Python 基础。
- Docker 部署：用容器跑 Alas，环境隔离干净。优点是迁移方便、不污染宿主机，缺点是对 Windows 用户来说 Docker 本身也要配置，反而多了一层。
我最终选的是源码部署，因为 Alas 更新频率不低，整合包经常落后好几个版本，而 Docker 在 Windows 上跑模拟器 ADB 连接会有网络模式的问题，排查起来麻烦。源码部署一次配好之后，后续更新就是拉一下代码的事。
3. 核心细节解析与实操要点
3.1 Python 环境与依赖安装的坑
Alas 是基于 Python 的，所以第一步是把 Python 环境弄好。这里有个关键点：Python 版本不要选太新的。我试过 Python 3.12，部分依赖包编译报错，回退到 3.10 就一切正常。官方推荐也是 3.10 或 3.11。
安装 Python 的时候，记得勾选“Add Python to PATH”，这个选项不勾后面命令行调用会找不到。装完之后打开命令行，输入python --version确认版本。
接下来是依赖安装。Alas 的依赖列表在requirements.txt里，直接：
pip install -r requirements.txt但实际操作中，国内网络环境下直接装大概率会卡在某个包上。我的做法是换国内镜像源：
pip install -r requirements.txt -i https://pypi.tuna.tsinghua.edu.cn/simple如果还是有个别包报错，通常是编译工具链的问题。Windows 上需要装 Visual C++ Build Tools，这个在微软官网能下到，装的时候勾选“C++ 生成工具”就行。
实操心得：依赖装完之后，建议跑一下
pip check，看看有没有版本冲突。我有一次因为某个包版本不兼容，Alas 启动时报了一堆 import 错误，排查了半天才发现是依赖冲突。
3.2 模拟器 ADB 连接的配置细节
模拟器装好之后，第一件事是开启 ADB 调试。以 MuMu 12 为例，在设置里找到“其他”或“开发者选项”，把 ADB 调试打开。雷电的话在设置-高级设置里。
然后确认 ADB 端口。MuMu 12 默认是127.0.0.1:16384，雷电默认是127.0.0.1:5555。你可以在模拟器安装目录下找到adb.exe，或者用 Alas 自带的 ADB 工具，执行：
adb connect 127.0.0.1:16384连接成功后，adb devices应该能看到设备列表。如果显示offline或者unauthorized，通常是模拟器还没完全启动，等几秒再试。
这里有个容易忽略的点：模拟器分辨率必须设置成 1280x720。Alas 的图像识别模板是基于这个分辨率做的，其他分辨率会导致识别偏移。在模拟器设置里把分辨率固定住，不要用“自适应”。
3.3 Alas 配置文件的填写逻辑
Alas 的配置文件是config.yaml或者通过 WebUI 界面配置。我建议用 WebUI，直观且不容易写错格式。启动 Alas 后，浏览器打开http://127.0.0.1:8080就能看到配置界面。
配置项里最关键的是这几块：
- 模拟器连接：填 ADB 地址和端口，跟前面
adb connect的一致。 - 游戏账号：选择服务器和登录方式。如果是渠道服，需要额外配置。
- 任务调度：勾选你要自动完成的任务，比如每日、委托、科研、大世界等。
- 资源限制：设置石油、金币的保留阈值，避免自动化把资源花光。
注意：第一次配置的时候，建议只勾选“每日任务”和“委托”，跑一轮看看稳定性。全部任务一起开，万一某个环节卡住，排查起来会很乱。
4. 实操过程与核心环节实现
4.1 从零开始的完整部署流程
我把整个部署过程拆成可复现的步骤，你照着做就行：
- 安装模拟器：下载 MuMu 12 或雷电 9，安装完成后创建一台 Android 7 或 Android 9 的实例。不要用 Android 12，兼容性反而差。
- 设置模拟器：分辨率 1280x720，帧率 30，开启 ADB 调试，记下 ADB 端口。
- 安装 Python 3.10：勾选 Add to PATH，装完后命令行验证。
- 获取 Alas 源码：从代码仓库克隆或下载压缩包，解压到英文路径下，路径不要有中文和空格。
- 安装依赖：用国内镜像源执行
pip install -r requirements.txt。 - 启动 Alas：命令行进入 Alas 目录，执行
python alas.py或对应的启动脚本。 - WebUI 配置：浏览器打开配置页面，填写 ADB 地址、账号信息、任务选项。
- 首次运行测试：先跑一个简单任务，观察模拟器画面和 Alas 日志，确认识别正常。
整个过程如果顺利，五分钟确实够。但第一次做的时候，光是模拟器设置和依赖安装就可能花掉二十分钟。所以“5分钟”是建立在环境已经就绪的前提下的。
4.2 关键参数的计算与选择
Alas 里有一些参数需要根据自己情况调整，我挑几个重要的说：
石油保留阈值：这个决定了 Alas 在石油低于多少时停止消耗石油的任务。我的建议是设置在 500 到 1000 之间。设太低，遇到活动图可能不够用；设太高，日常任务又跑不满。我自己的习惯是留 800，活动期间临时调到 1500。
委托刷新间隔：Alas 会定期检查委托列表，间隔太短浪费性能，太长又可能错过紧急委托。默认是 10 分钟，我实测下来 8 到 12 分钟都合理。如果你机器性能好，可以调到 6 分钟。
大世界探索深度：这个参数控制 Alas 在大世界里跑多远。设太高，一轮下来可能半小时；设太低，又拿不到多少奖励。我一般设“中等”，兼顾效率和收益。
战斗超时时间：默认 120 秒。如果你的模拟器比较卡，战斗加载慢，可以调到 180 秒，避免误判为卡死。
4.3 实际运行中的监控与调整
Alas 跑起来之后，不是完全不用管。我一般会在旁边开一个日志窗口，观察有没有报错。常见的日志信息有几类：
INFO：正常流程，不用管。WARNING：通常是识别置信度偏低，但还能继续。如果频繁出现，说明模拟器画面有问题。ERROR：任务失败，需要排查。比如“找不到委托按钮”，可能是界面变了或者分辨率不对。
我自己的习惯是每天睡前启动 Alas，让它跑日常和委托，第二天早上看日志。如果一切正常，日志里应该只有 INFO 和少量 WARNING。如果 ERROR 超过三条，我就会去检查模拟器状态。
实操心得：Alas 跑久了，模拟器可能会内存泄漏，表现为越来越卡。我的做法是设置一个定时重启，每 12 小时重启一次模拟器。Alas 本身有“重启模拟器”的选项，勾上就行。
5. 常见问题与排查技巧实录
5.1 连接类问题速查
| 现象 | 可能原因 | 解决方法 |
|---|---|---|
| adb devices 无设备 | ADB 未开启或端口不对 | 检查模拟器设置，确认端口 |
| 设备显示 offline | 模拟器未完全启动 | 等待 10 秒后重试 |
| Alas 提示连接失败 | 防火墙拦截 | 关闭防火墙或添加例外 |
| 连接成功但无法操作 | ADB 版本不匹配 | 用模拟器自带的 adb.exe |
连接问题是最常见的，我遇到最多的是端口冲突。比如你同时开了 MuMu 和雷电，两个都占用了 ADB 端口，就会互相干扰。解决办法是只开一个模拟器，或者手动指定不同端口。
5.2 识别类问题与画面优化
Alas 依赖图像识别来定位按钮和界面元素。如果识别率低，通常是这几个原因：
- 分辨率不对：必须 1280x720，其他分辨率一律不行。
- 画面缩放：模拟器设置里的“画面缩放”要关掉，保持 100%。
- 渲染模式：MuMu 12 建议用“兼容模式”或“极速模式”，不同模式画面渲染有差异。
- 游戏内设置：碧蓝航线里的“UI 缩放”要调到默认，不要自定义。
我有一次因为模拟器开了“智能分辨率”，画面在 720p 和 1080p 之间跳，Alas 识别率直接掉到 50% 以下。关掉之后恢复正常。
5.3 任务卡死与异常处理
任务卡死是另一个高频问题。表现是 Alas 日志停在某一步不动，模拟器画面也没反应。常见原因和应对：
- 网络波动：游戏加载卡住。Alas 有超时重试机制，一般等 2 分钟会自动恢复。
- 弹窗干扰：游戏内活动弹窗、公告弹窗挡住了按钮。Alas 有“关闭弹窗”逻辑，但偶尔会漏。手动点掉即可。
- 模拟器崩溃：直接重启模拟器，Alas 会重新连接。
- 游戏更新：版本更新后界面变化，Alas 模板失效。需要等 Alas 更新或手动调整。
注意：如果 Alas 频繁卡在同一个地方，不要反复重启，先去看日志里的具体报错。我遇到过卡在“进入委托”这一步，日志显示“找不到委托按钮”，后来发现是游戏更新后按钮位置变了，等 Alas 发布新版本才解决。
5.4 性能优化与长期运行建议
如果你打算长期挂 Alas，有几个优化点值得做：
- 模拟器独立分配资源：不要让模拟器和 Alas 抢 CPU，在任务管理器里把模拟器优先级设为“低于正常”。
- 关闭模拟器音效：音效渲染也会消耗资源，关掉能省一点。
- 定期清理模拟器缓存：模拟器用久了缓存会膨胀，每周清理一次。
- Alas 日志轮转：日志文件会越来越大，设置一个自动清理规则，保留最近 7 天。
我自己的机器上，Alas 连续跑一周基本没问题，但模拟器建议每天重启一次。我设置的是凌晨 4 点重启，那个时间点没有任务在跑，影响最小。
6. 关于 Alas 后续使用的一些个人体会
Alas 这个工具，部署只是第一步，真正花时间的是调参和适应游戏更新。我用了大半年，最大的感受是：不要追求“全自动什么都不管”，而是把它当成一个帮你完成重复劳动的助手。该检查的时候还是要检查，该手动的时候还是要手动。
另外，Alas 的社区更新挺活跃的，遇到问题先去翻 issue 列表，大概率有人已经遇到过了。我自己遇到过一个“演习任务无限循环”的 bug，就是在社区里找到的临时解决方案。
最后分享一个小技巧：如果你有多台机器，可以把 Alas 的配置目录整个复制过去，改一下 ADB 地址就能用。我换电脑的时候就是这么迁移的，省了重新配置的麻烦。配置文件在config目录下，记得连同db文件一起复制，不然任务进度会丢。
