MuMu 模拟器 API：把命令行能力变成 HTTP 接口

如果你在用 MuMu 模拟器 做自动化测试、批量运维或脚本编排，大概率会碰到同一个问题：命令行好用，但不好集成。每次操作都要手动执行 MuMuManager.exe，难以被其他系统调用，也不方便做并发控制和统一错误处理。

MuMu模拟器 API（mumu-api）正是为此而生——它是一个基于 FastAPI 的轻量 Web 服务，把 MuMu 官方命令行工具封装成 REST 接口。你只需要发 HTTP 请求，就能远程启动/关闭模拟器、管理应用、查询设备状态。

它能做什么

当前已提供以下能力：

其中 {index} 是模拟器编号，与 MuMu 客户端中显示的序号一致。

项目亮点

1. 开箱即用的 HTTP 集成

不需要在每个脚本里拼接命令行参数，任何支持 HTTP 的语言或工具（Python、Node.js、Postman、CI 流水线等）都可以直接调用。docs/local.http 里附带了常用请求示例，复制即可调试。

2. 为自动化场景做了基础防护

• 限流：同一设备、同一接口在 60 秒内只允许调用一次，避免误操作导致频繁重启等问题。
• 互斥锁：针对 UI 相关操作，同一设备同时只允许一个请求在执行，防止并发冲突。
• 失败重试：命令执行异常时自动重试一次，提高稳定性。

3. 异步架构，不阻塞主线程

底层通过 asyncio 异步调用子进程，适合同时管理多台模拟器的场景。

4. 清晰的分层设计，扩展成本低

HTTP 请求 → API 路由 → 中间件（限流/互斥） → 命令层 → MuMuManager.exe

命令层按 MuMu 子命令分类组织（control、info、adb 等），新增能力通常只需两步：在 src/commands/ 下封装命令，再在 src/apis/ 下暴露路由。

5. 配置灵活

通过 YAML 配置文件管理端口、日志、MuMu 路径等参数，开发环境和生产环境可分别加载不同配置。

快速上手

环境要求

• Windows（MuMu 模拟器运行环境）
• Python 3.14+
• 已安装 MuMu 模拟器命令行工具

配置

编辑 src/config/settings.yaml（或开发环境的 settings.development.yaml）：

mumu:
  path: MuMuManager.exe 的完整路径
  share_base_dir: MuMu 共享文件夹目录

启动服务

开发环境：

uv sync
uv run python -m src.main

生产环境可直接使用项目根目录的 start.bat 一键启动。

服务默认监听 9090 端口。启动后访问 http://localhost:9090/docs 可查看 Swagger 交互文档。

调用示例

# 启动 1 号模拟器
POST http://localhost:9090/launch/1
​
# 查询所有设备状态
GET http://localhost:9090/device/all
​
# 启动指定应用
POST http://localhost:9090/app/launch/1/com.example.app

如何扩展

项目的设计目标之一就是按需扩展，而不是一次性塞满所有功能。

以添加「模拟点击」为例，MuMu 命令行已支持 adb 子命令，项目中 src/commands/adb.py 也已有 tap、input 等方法的基础封装，你只需要：

1. 在 src/apis/ 下新增路由，调用 adb_cmd.tap(index, x, y)；
2. 按需加上 @mutex_by_index 等中间件；
3. 补充测试用例。

同理，截图（control_cmd.screenshot）、进程检测（adb_cmd.process_exists）等能力都可以按同样模式快速暴露为 API。

这种「命令层先行、API 按需开放」的方式，让项目既能保持精简，又能随业务需求灵活生长。

适用场景

• 自动化测试：CI 流水线中自动启动模拟器、安装并运行被测应用
• 批量运维：统一管理多台模拟器的启停和应用部署
• 脚本编排：将模拟器操作纳入更大的自动化流程，与其他 HTTP 服务协同工作
• 二次开发：作为中间层，对接自研的管理平台或调度系统

写在最后

MuMu 模拟器 API 不是对 MuMu 功能的重新实现，而是对官方命令行工具的一层薄封装。它的价值在于降低集成门槛——把已有的命令行能力变成标准 HTTP 接口，并附带限流、互斥、重试等自动化场景常见的基础保障。

项目采用 MIT 协议开源，欢迎 Star、Issue 和 Pull Request。

GitHub：mumu-api