多實例與配置管理

一個實例 = 一份配置 + 一個排程器處理程序 + 一臺被控制的模擬器。想同時掛兩個帳號，就是兩套實例和兩臺模擬器，沒有別的捷徑。

目錄與隔離

text

AzurPilot/
├── config/
│   ├── ap.json              # 实例 ap 的配置
│   ├── ap-2.json            # 实例 ap-2 的配置
│   ├── deploy.yaml          # 后端级设置（所有实例共享）
│   └── remote-access.json   # 远程访问身份（共享）
├── AzurPilot_Data_Backup/   # 每日备份，按日期分目录
├── log/
│   ├── 2026-10-20_ap.txt
│   └── 2026-10-20_ap-2.txt
└── cache/

各實例共享同一份程式碼、同一套資源、同一個 WebUI 後端，但：

有獨立的 config/<实例>.json；
有獨立的 worker 處理程序；
有獨立的日誌檔案；
在 SQLite 總庫裡以實例名區分數據。

實例名就是主鍵

重命名實例不要在檔案系統裡改檔案名稱。用 WebUI 的匯出/匯入，或複製配置後刪除舊實例。直接改名會讓統計與排程記錄對不上。

建立第二個實例

準備第二臺模擬器

複製模擬器實例（MuMu、雷電都支援多開），確保每臺都有獨立的 ADB 連接埠。不要兩臺共用同一個 Serial。

新建配置

WebUI → 已安裝配置 → 新建，名稱填 ap-2。可以從 ap 複製，任務開關會一起帶過來。

改設備字段

至少改 Emulator.Serial。如果兩臺模擬器跑不同伺服器，PackageName 也要改。

錯開排程時間

給時間敏感的任務設定不同的 NextRun，或使用「每日重新啟動隨機延後」錯開登入。兩個實例同時搶同一臺機器的 CPU 時，截圖會變慢。

逐個啟動

先啟動一個確認穩定，再啟動第二個。同時啟動會放大冷啟動時的資源爭搶。

資源開銷

資源	單實例大致佔用	說明
記憶體	Python 處理程序數百 MB + 模擬器 2–4 GB	模擬器是大頭
CPU	識別時單核較高	截圖與模板匹配是主要開銷
硬碟	日誌每天數 MB，錯誤現場更大	用 `Error.SaveErrorRetentionDays` 控制
網路	更新與統計上報	不影響遊戲延遲

一臺 16 GB 記憶體的機器通常能跑 2 個模擬器實例；再多需要看 CPU 單核性能與硬碟 IO。Android 宿主上的實例受手機記憶體限制，通常只建議一個。

帳號保險庫

「設定 → 賬戶」提供憑據管理：

操作	說明
建立	新建一個加密的帳號檔案
解鎖 / 鎖定	手動控制保險庫狀態
綁定 TPM	使用設備 TPM 保護密鑰（可用時）
綁定本機	使用系統級密鑰（Windows DPAPI 等）
切換	把某檔案應用到實例
刪除	解除安裝檔案

保險庫綁定設備：換機器或重裝系統後，舊密鑰無法解密，需要重新錄入。這是設計目標，不是缺陷。

匯入與匯出

場景	做法
備份單個實例	任務配置頁匯出 JSON
遷移全部實例	複製 `config/*.json`
分享配置模板	匯出後刪除設備 Serial、SSH 私鑰、路徑等本機資訊
恢復誤刪	從 `AzurPilot_Data_Backup/<日期>/` 複製回來

匯入時會做字段校驗與遷移。版本差異過大時，缺少的字段會取預設值，多餘字段會被忽略——所以跨大版本匯入後要逐頁檢查關鍵開關。

多開時的常見坑

現象	原因
兩個實例互相點擊	兩臺模擬器用了同一個 Serial
只有一個實例能截圖	截圖方案與模擬器實例不匹配（如 nemu_ipc 只認預設實例）
ADB 頻繁掉線	多個 adb server 搶佔 5037 連接埠
CPU 打滿、識別超時	同時跑大世界與主線，且機器核數不足
日誌串臺	用同一個實例名啟動了兩個處理程序

一個實例只能有一個處理程序

alas.py <实例名> 沒有單例鎖。手動在命令行再啟動一次同名實例，會得到兩個 worker 同時操作一臺模擬器。啟動前先在 WebUI 確認狀態。

多實例與配置管理

目錄與隔離 ​

建立第二個實例 ​

資源開銷 ​

帳號保險庫 ​

匯入與匯出 ​

多開時的常見坑 ​