木-Star把一台云服务器变成一台跑着完整 Android 系统的“云手机”，这事听起来挺有折腾空间，但实际做起来并不复杂。核心思路就是用 Docker 跑一个叫 redroid 的 Android 容器，直接把整个 Android 系统塞进 Linux 容器里，省掉传统模拟器的虚拟化开销。这个方案我前后折腾过几个版本，从 Android 10 到 Android 14 都跑过，踩过不少坑，也总结出一套相对顺畅的部署流程。如果你手上正好有一台云服务器，或者打算租一台来跑云手机、做自动化测试、挂应用多开，这篇内容应该能帮你少走很多弯路。
redroid 的全称是 Remote Android，本质上是把 Android 系统镜像做成 Docker 镜像，然后用容器方式启动。它和传统模拟器的最大区别在于：模拟器需要完整的 CPU 虚拟化、模拟硬件环境，性能损耗大；而 redroid 直接共享宿主机 Linux 内核，只把 Android 上层框架、系统服务和应用程序跑在容器里，所以启动速度快、资源占用低、单台服务器能开更多实例。当然，代价就是它需要宿主机内核提供 Android 系统依赖的一些特殊内核模块，主要是 binder 和 ashmem/memfd，这是整个部署过程中最容易出问题的环节。
这篇内容适合这几类人看：想低成本跑云手机做业务多开的、做 Android 自动化测试和爬虫采集的、对容器化技术好奇想研究 Android 系统结构的，以及纯粹想把闲置云服务器利用起来折腾着玩的朋友。下面从方案选型、内核配置、实际部署、显示输出到问题排查，把整个流程完整走一遍。
1. 整体方案设计与前期评估
1.1 为什么选 redroid 而不是传统模拟器
先说结论：在云服务器上跑 Android，redroid 基本是当前性价比最高的方案。传统 Android 模拟器（比如 Android Studio 自带的 AVD、Genymotion 这类）依赖完整的 CPU 虚拟化指令集（KVM/HAXM）和图形虚拟化，在本地电脑上跑还行，搬到云服务器上就非常吃力。很多云服务器默认没有开启嵌套虚拟化，或者说即便开了，大量模拟器同时运行时的 CPU 损耗和内存占用也非常感人。
redroid 走的是容器化路线，和 Docker 里跑 Nginx、MySQL 是一个逻辑。Android 系统本身就是一个 Linux 内核加上一层用户空间框架，容器化方案里 Android 的 Linux 内核部分直接复用宿主机的，用户空间框架（zygote、system_server、SurfaceFlinger 这些）跑在容器进程里。打个比方，传统模拟器是你在自己家院子里另盖了一座房子，地基墙屋顶都要单独建；redroid 则是你家楼上多个房间共用同一个地基和承重墙，只做内部隔断装修。
实际测试下来，一台 8 核 16G 内存的云服务器，用模拟器方案可能只能稳定跑 2-3 台，换成 redroid 的话，跑 8-10 台 Android 14 实例都不成问题，而且单实例启动时间能控制在 10 秒以内。这个效率差距，足以让 redroid 成为云手机部署的事实标准。
1.2 云服务器选型建议与配置评估
redroid 部署并不挑服务器品牌，阿里云、腾讯云、华为云、各类 VPS 服务商都可以，关键看几个硬指标：
CPU 架构方面，优先选 x86_64 架构的服务器。redroid 官方镜像默认提供 x86_64 版本，跑起来最省心。ARM 架构的服务器（比如某些 ARM 云主机、树莓派）也能跑 redroid，官方也有 arm64 镜像，但实际可玩性差一些，部分应用的兼容性问题会更明显。
内核版本建议 5.10 以上。redroid 对内核版本有一定要求，新版本 Android（13/14）的 binder 驱动、memfd 支持都依赖较新的内核特性。如果你用的是 CentOS 7 这类老系统，内核才 3.10，大概率是跑不起来的，建议直接换成 Ubuntu 22.04 LTS 或者 Debian 12，这两套系统开箱即用的兼容性最好。
内存和磁盘就看你打算开多少实例。单个 Android 14 实例，内存建议至少分配 2G，磁盘占用 2-3G 起步（系统镜像 + 应用数据 + 日志），多加一个实例就按这个基准往上加。存储尽量选 SSD，机械硬盘跑 Android 的 I/O 压力会很大，启动速度和应用的流畅度都会打折扣。
还有一点容易忽略：买服务器前先确认服务商是否允许运行容器和内核级应用。绝大多数主流云服务商都没问题，但个别虚拟主机、共享主机是不支持 Docker 的，这类服务器的内核权限被限制得很死，root 权限都不完整。判断标准很简单，你 ssh 上去之后先跑一下 sudo docker run hello-world，如果 Docker 都没法正常跑，后面 redroid 就别谈了。
1.3 两种部署路线的选择与对比
我实际接触下来，redroid 部署主要有两条路线：
第一条是纯云服务器部署，也就是 Linux 服务器上直接装 Docker，再跑 redroid 容器。这是正式环境的标准做法，也是本篇文章主要讲解的方向。
第二条是本地电脑用 Docker Desktop + WSL2 跑 redroid，适合开发调试。Windows 上跑 redroid 需要 WSL2 内核提供 binder 支持，而 Docker Desktop 自带的 WSL2 内核默认没有编译 binder 驱动，所以你需要额外做一步：编译或者下载一个支持 binder 的 WSL2 内核，替换掉 Docker Desktop 的默认内核。这一步对小白非常不友好，而且 WSL2 的内核源码编译流程要折腾挺久，我不建议在没有明确需求的情况下走这条路。如果你只是想体验 redroid，直接租一台便宜的 Linux 云服务器或者用本地的 Linux 物理机是最快的。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 核心细节解析：内核模块与系统依赖
2.1 binder 和 memfd 到底起了什么作用
这是整个 redroid 部署里最重要、也最容易出问题的一环。Android 系统内部大量使用一种叫 Binder 的进程间通信机制，举个例子，你在手机上点一个应用图标，Launcher 进程要通过 Binder 通知 ActivityManagerService 来启动应用，应用和应用之间传递数据也走 Binder。在传统 Android 设备上，binder 驱动是内核自带并加载好的；但在容器环境里，Android 系统变成了普通进程，它访问不到宿主机的 /dev/binder 设备节点，所以必须在宿主机层面把 binder 驱动加载起来，并把它挂载进容器。
早期版本还依赖 ashmem（Android Shared Memory），用来做共享内存分配；Android 11 之后系统慢慢迁移到了 memfd 机制，所以新版本的 redroid 只需要 binder 驱动，即使没有 ashmem 也能正常运行。
2.2 检查宿主机环境是否满足条件
在拉取 redroid 镜像之前，先花两分钟检查宿主机环境。ssh 到服务器后，依次执行：
bash复制uname -a
ls /dev/binder* 2>/dev/null || echo "no binder device"
lsmod | grep binder
如果输出能看到 /dev/binder 或者 lsmod 里有 binder_linux，说明你的内核已经准备好了，直接跳到下一节。如果什么都没有，需要先手动加载内核模块：
bash复制sudo modprobe binder_linux
如果没有报错，再创建 binderfs 挂载点：
bash复制sudo mkdir /dev/binderfs
sudo mount -t binder binder /dev/binderfs
sudo ls /dev/binderfs
如果 /dev/binderfs 目录下能看到 binder、hwbinder、vndbinder 这几个设备节点，说明 binder 驱动已经正常工作。
这里要特别提醒一个坑：如果你的内核报 modprobe: FATAL: Module binder_linux not found in directory，说明当前内核没有编译 binder 模块。这种情况下最常见的解决路径是升级内核。Ubuntu 系统可以直接安装 Linux 主线内核或者使用 distribution 自带的硬件使能内核（HWE kernel），比如：
bash复制sudo apt install linux-generic-hwe-22.04
sudo reboot
2.3 使用 binderfs 而不是直接把设备映射进容器
早期版本的 redroid 部署教程通常会让你用 -v /dev/binder:/dev/binder 的方式直接把宿主机的 binder 设备节点映射给容器。这种方式在只有一个容器实例的时候能跑通，但一旦你要多开，多个容器同时争抢同一个 binder 设备节点，就会出现权限错乱、进程时不时崩溃的问题。
新版 redroid 官方推荐的方案是挂载 binderfs。binderfs 是 Linux 4.19 引入的一个专门管理 binder 设备的虚拟文件系统，它允许为每个容器创建独立的 binder 设备子通道，容器 A 的 binder 和容器 B 的 binder 互不干扰。这也是为什么现在启动 redroid 容器时要用 -v /dev/binderfs:/dev/binderfs 而不是 -v /dev/binder:/dev/binder。
为了让重启后配置不丢，建议把挂载写进 /etc/fstab：
bash复制echo "none /dev/binderfs binder defaults 0 0" | sudo tee -a /etc/fstab
这样服务器重启后 binderfs 会自动挂载，不需要手动执行 mount 命令。
2.4 云服务器内核不支持的常见兜底方案
如果你折腾了半天 modprobe 依然报错，大概率是云服务商给的内核太精简或者太老。这里有几个思路可以试：
先去服务商后台看看能不能切换操作系统版本，直接换一个自带新版内核的系统镜像，比如 Ubuntu 24.04 LTS。这是最快的方案。
如果服务商不允许换系统，但允许使用自定义内核，你可以试试用 elrepo（CentOS/RHEL 系）或者 Ubuntu Mainline Kernel Installer 装一个主线内核。装之前一定要快照备份，否则内核崩了服务器起不来就难受了。
如果你用的是轻量应用服务器或者虚拟主机这种受限环境，比如阿里云轻量服务器里有些实例就是不开放某些内核模块的加载权限，这种时候就别硬折腾 redroid 了，换一家云服务商，或者换一个更低门槛的方案，比如直接租一台物理机、或者用带 KVM 的独立服务器。
bash复制# 示例：Ubuntu Mainline Kernel 安装方式
cd /tmp
wget https://kernel.ubuntu.com/mainline/ # 选一个版本目录
wget https://kernel.ubuntu.com/mainline/v6.5.0/... # 对应 deb 包
sudo dpkg -i linux-headers-*.deb linux-image-*.deb
sudo reboot
这里要说明一下，我上面给的是主线内核下载路径的格式，实际执行时要去网页里找到当前可用的 deb 包地址，不同版本链接不一样，别直接复制。
3. 实操过程：从拉取镜像到跑通第一台云手机
3.1 安装 Docker 环境
debian 系的服务器安装 Docker 很直接，用官方脚本也行，用 apt 源安装也行。我习惯用官方脚本，省事：
bash复制curl -fsSL https://get.docker.com | sudo sh
sudo systemctl enable --now docker
装完看一眼 docker 版本：
bash复制docker --version
如果你所在网络环境拉 Docker Hub 镜像很慢，建议先配置镜像加速。Docker 的镜像加速配置文件在 /etc/docker/daemon.json，各家云服务商都有提供加速地址，比如阿里云容器镜像服务的加速器地址。配置方法如下：
bash复制sudo mkdir -p /etc/docker
sudo tee /etc/docker/daemon.json <<-'EOF'
{
"registry-mirrors": ["https://你的加速器地址.mirror.aliyuncs.com"]
}
EOF
sudo systemctl daemon-reload
sudo systemctl restart docker
镜像加速这事要在拉取之前配好，否则 redroid 镜像几个 G 的体积，下载速度慢的话非常折磨人。
3.2 加载内核模块并挂载 binderfs
接着把上一节的内核准备步骤在正式环境里完整执行一遍：
bash复制sudo modprobe binder_linux
sudo mkdir -p /dev/binderfs
sudo mount -t binder binder /dev/binderfs
echo "none /dev/binderfs binder defaults 0 0" | sudo tee -a /etc/fstab
ls /dev/binderfs
这一步做完能看到 /dev/binderfs 目录下有三个文件：
text复制binder hwbinder vndbinder
这三个设备节点分别对应 Android 系统中不同层面的 binder 通信。binder 是应用层进程间通信用，hwbinder 是硬件抽象层通信用，vndbinder 是 vendor 进程通信用。容器启动后 redroid 会在里面自动创建设备节点，我们只需要把整个 binderfs 目录挂载进去即可。
3.3 启动第一个 redroid 容器
当前 redroid 官方镜像最新的稳定版本是 Android 14，具体 tag 是 redroid/redroid:14.0.0-latest。如果你的应用对 Android 版本有兼容性要求，也可以选择 Android 11（redroid/redroid:11.0.0-latest）或 Android 13（redroid/redroid:13.0.0-latest）。
以 Android 14 为例，启动命令如下：
bash复制docker run -d \
--name redroid \
--privileged \
--pull=always \
-v /dev/binderfs:/dev/binderfs \
-p 5555:5555 \
redroid/redroid:14.0.0-latest
--privileged 参数是 redroid 容器必需的，因为它要访问宿主机内核模块、挂载 binderfs、调整部分系统参数，普通容器模式下的权限限制不够用。
-p 5555:5555 是把容器内的 adb 调试端口（Android 系统默认 5555）映射到宿主机，这样稍后可以从外部 adb 连接。
-v /dev/binderfs:/dev/binderfs 把宿主机已经挂载好的 binderfs 目录映射进容器，容器内 Android 系统就能访问到 binder 驱动设备。
启动后先看一眼容器状态：
bash复制docker ps
docker logs redroid
正常启动的日志里会看到类似 [redroid] starting android container、[redroid] binder devices: /dev/binderfs/binder、[redroid] ro.kernel.qemu=0 这样的输出。如果日志里有红色报错，别慌，直接看第 5 章节排查。
3.4 adb 连接并验证系统状态
容器跑起来之后，在一台安装了 Android Platform Tools 的机器上执行 adb connect：
bash复制adb connect 你的服务器公网IP:5555
adb devices
如果输出显示 device 状态，说明已经连上了。然后就可以用 adb shell 进入系统：
bash复制adb shell
getprop ro.build.version.release
如果输出是 "14"，说明 Android 14 系统已经完整启动。
有些云服务器安全组默认不开放 5555 端口，连接超时的话，记得先去云控制台安全组规则里放行 TCP 5555 端口。如果你不想对公网开放 adb 端口，也可以直接用 ssh 隧道连接：
bash复制ssh -L 5555:localhost:5555 root@你的服务器IP
# 另开一个终端
adb connect localhost:5555
这样本地的 5555 端口会转发到服务器上的 5555 端口，云服务器不需要额外开放安全组端口，安全性更高。
3.5 调整容器参数：内存、CPU、分辨率与设备型号
默认启动的 redroid 不会限制容器资源，实践里最好给每个实例设置明确的资源上限，避免多开时互相抢占。
bash复制docker run -d \
--name redroid \
--privileged \
--pull=always \
--memory=2g \
--cpus=2 \
-v /dev/binderfs:/dev/binderfs \
-p 5555:5555 \
-e "ANDROID_DEVICE=Pixel_5" \
-e "ro.product.model=Pixel 5" \
redroid/redroid:14.0.0-latest
--memory 限制容器最大内存，--cpus 限制容器可用的 CPU 核心数。如果部署的是多实例，每个实例建议至少分配 2G 内存和 2 个核，性能上才有基本保障。
-e 环境变量可以覆盖 Android 系统的编译属性，比如修改设备型号。这样的需求来自很多做应用多开的场景，比如某些应用会根据设备型号做风控或者兼容性判断，改一下型号能让应用行为更接近真机。
redroid 还支持通过环境变量调整屏幕分辨率，比如设置属性：
bash复制docker run -d \
--name redroid \
--privileged \
--pull=always \
-v /dev/binderfs:/dev/binderfs \
-p 5555:5555 \
-e "ANDROID_DEVICE=Pixel_5" \
-e "ro.product.model=Pixel 5" \
-e "persist.sys.screencapture.scale=0.5" \
-e "dalvik.vm.heapsize=512m" \
redroid/redroid:14.0.0-latest
这些参数不复杂，但理解后能让你根据具体用途灵活调整，比如跑自动化测试时调大 heap，跑视频播放类应用时关注分辨率适配。
4. 图形输出方案与远程使用体验
4.1 无 GPU 场景下 redroid 如何渲染画面
redroid 容器跑起来之后，Android 系统的图形渲染默认使用 SwiftShader 进行纯软件渲染。SwiftShader 是 Google 开源的一个软件 GPU 实现，它不依赖宿主机 GPU，完全用 CPU 模拟图形处理流程。所以即便你的云服务器是纯 CPU 机器，Android 系统照样能绘制界面、播放视频，只是没有 GPU 加速那么流畅，高分辨率下的滑动和动画会有一定压力。
实际测试中，软件渲染模式下 720p 分辨率的界面操作流畅度尚可，但如果把分辨率调到 1080p 或者 2K，界面帧率会明显下降，尤其打开多个应用时 CPU 占用会非常高。
想在软件渲染模式下获得更好的体验，可以把容器的分辨率调低。redroid 的默认属性是通过 ro.surface_flinger.max_graphics_width 和 ro.surface_flinger.max_graphics_height 来控制，可以在启动时用 -e 设置：
bash复制-e "ro.surface_flinger.max_graphics_width=720"
-e "ro.surface_flinger.max_graphics_height=1280"
-e "persist.sys.screencapture.scale=0.7"
这里要注意，分辨率设置要在系统首次启动时生效，如果容器已经跑过一段时间再改可能不生效，需要删除容器重新创建。
4.2 有 GPU 场景下的硬件加速配置
如果你的服务器有 GPU（比如不少 AI 训练型云主机标配了 NVIDIA GPU），那就没必要纯软件渲染了。redroid 支持通过 Mesa 的 virgl 协议把宿主机的 GPU 能力透传给容器内的 Android 系统。
具体配置分几步：宿主机要装好 GPU 驱动和 Mesa 库，容器启动时挂载 GPU 设备路径并设置相关环境变量。NVIDIA GPU 的挂载路径一般是 /dev/nvidia0、/dev/nvidiactl 和 /dev/nvidia-uvm，Docker 还可以用 --gpus all 让容器直接访问 GPU：
bash复制docker run -d \
--name redroid \
--privileged \
--pull=always \
--gpus all \
-v /dev/binderfs:/dev/binderfs \
-p 5555:5555 \
-e "ro.hardware.gralloc=default" \
-e "ro.hardware.egl=swiftshader_indirect" \
redroid/redroid:14.0.0-latest
配置 GPU 加速这部分比较复杂，如果你只是拿 redroid 来做自动化测试、跑脚本、挂应用，其实没必要折腾 GPU。软件渲染虽然不够华丽，但胜在稳定，部署起来一点都不费心。
4.3 远程查看云手机画面的几种途径
redroid 本身是个无头系统，没有显示器，所以要“看到”它，必须通过外部工具把画面拉出来。我试过几种方式，下面说说实际体验。
最简单的方式是用 scrcpy。scrcpy 本来是个基于 adb 的屏幕镜像工具，手机上插入数据线后用电脑显示手机画面。在 redroid 场景里，只需要先 adb connect 到容器，然后让 scrcpy 连接同样地址：
bash复制adb connect 你的服务器IP:5555
scrcpy -s 你的服务器IP:5555 --max-size 1024
scrcpy 的原理是通过 adb 的 screenrecord 功能把手机屏幕编码成 H.264 视频流，然后本地解码显示。它默认不修改系统状态，画面延迟低，而且支持鼠标键盘操作透传，我日常工作里很多操作都是直接用 scrcpy 完成的。
如果你需要 Web 界面访问，那就要借 ws-scrcpy 这样的开源项目，它是 scrcpy 的网页版，浏览器打开一个 HTML5 页面就能看到手机画面、操作手机。部署 ws-scrcpy 需要一个静态文件服务加一个 WebSocket 转发服务，官方文档里有详细的 Docker 部署方式。
另外还有更轻量的方式：直接用 adb shell 截屏，配上一个定时任务，就能实现“伪实时监控”效果。适合只要验证应用状态、不需要实时操作的场景。
5. 常见问题与排查技巧实录
5.1 容器启动后立刻退出或反复重启
这是 redroid 部署里最典型的问题，原因八九不离十是内核 binder 环境不对。先看容器日志：
bash复制docker logs redroid
日志里出现类似 Unable to open /dev/binder、Failed to open /dev/binderfs/binder 的报错，基本就能锁定 binder 模块没加载或者 binderfs 没挂载。
依次检查：
bash复制ls /dev/binderfs # 确认 binderfs 挂载成功
lsmod | grep binder # 确认 binder_linux 模块已加载
docker inspect redroid | grep -A5 Mounts # 确认容器挂载路径
如果确认环境变量都没问题，还有一个容易忽略的情况，就是云服务商开的内核里 binder 模块加载了，但 /dev/binderfs 目录在容器启动时是空的。这种情况可以尝试在宿主机上手动往容器里挂载一次：
bash复制docker exec redroid ls /dev/binderfs
如果容器里确实看不到 binder 设备，重建一个容器，把挂载参数原文再review一遍。
5.2 adb 连接显示 offline
容器跑起来了，adb devices 也能看到设备，但状态显示 offline，这个情况通常是 adbd 进程异常。
先尝试 adb 重启 adbd：
bash复制adb kill-server
adb connect 你的服务器IP:5555
adb reconnect offline
如果还不行，直接重启容器：
bash复制docker restart redroid
等 30 秒左右再 adb connect，基本都能恢复。
还有个很容易被忽视的问题：如果你在本机已经连接过很多 Android 设备，adb 的密钥列表可能冲突。删掉本地的 adbkey 文件再重新连接：
bash复制rm -f ~/.android/adbkey ~/.android/adbkey.pub
adb kill-server
adb connect 你的服务器IP:5555
5.3 界面黑屏或花屏
容器启动成功、adb 也能连上，但用 scrcpy 看画面全是黑屏或者花屏，这种情况通常是图形渲染出了问题。
软件渲染模式下，先确认分辨率属性有没有设置得过高。如果设了 2K 分辨率，SwiftShader 压力会很大，把 max_graphics_width/height 调回 720/1280 后重建容器。
如果单个容器黑屏，其他容器正常，那大概率是 SurfaceFlinger 进程崩溃。可以尝试修复文件权限：
bash复制adb shell stop
adb shell start
或者直接杀掉 SurfaceFlinger 让它重启：
bash复制adb shell "killall surfaceflinger"
画面花屏多半和网络传输有关，scrcpy 默认参数不适合跨地域网络环境，尝试降低码率和分辨率：
bash复制scrcpy -s 你的服务器IP:5555 --bit-rate 2M --max-size 800
5.4 镜像拉取慢的问题
redroid 镜像体积不小，Android 14 的镜像大约有 1.5G 左右。如果拉取速度只有几 KB 每秒，那就是网络问题了。最佳解决方法是先配好镜像加速器再拉取，这一点在第 3 节已经讲过。
另外还有一个思路：如果服务器上已经有一个镜像，另一个新服务器要部署同样的环境，可以把镜像导出再导入，省去从 Docker Hub 拉取的时间。
bash复制# 在源服务器上
docker save redroid/redroid:14.0.0-latest | gzip > redroid.tar.gz
# 传到目标服务器后
docker load < redroid.tar.gz
5.5 多开实例的端口和资源规划
如果你要跑多个云手机，核心思路就是每个实例一个独立容器名、一个独立 adb 端口、一组独立的资源配额。比如：
bash复制docker run -d --name redroid-01 --privileged --pull=always \
--memory=2g --cpus=2 \
-v /dev/binderfs:/dev/binderfs \
-p 5555:5555 \
redroid/redroid:14.0.0-latest
docker run -d --name redroid-02 --privileged --pull=always \
--memory=2g --cpus=2 \
-v /dev/binderfs:/dev/binderfs \
-p 5556:5555 \
redroid/redroid:14.0.0-latest
第二个实例的宿主机端口改成 5556，容器内的 5555 不用变。连接时 adb connect 服务器IP:5556 就行。
多开之后注意几个问题：磁盘空间暴涨，因为每个实例都是完整镜像层加可写层；CPU 和内存被占满后，容器之间会互相拖累，务必限制每个实例的资源上限。
最后分享几个实操心得
redroid 这套方案我用了挺长时间，踩了一圈坑之后，有几个体会想分享给大家。
第一，部署第一步永远是先确认内核模块，而不是急着拉镜像。很多新手一上来就是 docker run，结果 binder 相关报错刷一屏。先花两分钟跑通 binderfs，后面会顺很多。
第二，云手机跑起来之后别急着上高分辨率。软件渲染模式下 1080p 和 720p 的体验差距天壤之别，但大多数自动化任务、应用挂机、甚至轻度点按操作在 720p 下完全够用。把分辨率调低，你能在同样的服务器资源下多开一倍甚至两倍的实例。
第三，如果你要用 redroid 做生产环境，强烈建议走“黄金镜像”路线。先把系统环境、常用应用、账号状态都配置好，然后 docker commit 保存成自己的镜像，后续部署直接从自定义镜像启动，新实例秒级可用。这一步能省下大量重复性配置的时间。
第四，redroid 和 adb 的配合非常成熟，几乎所有 adb 能够完成的操作都能直接用在云手机上。批量操作多台实例时，可以写一个 for 循环同时执行 adb 命令，效率比手动一台一台点高太多。
最后说一句，redroid 这个项目目前还在持续更新，Android 14 的镜像已经比较稳定了，但如果你有特殊的系统定制需求，还是优先选择 Android 11 或 13 版本，社区资料更多，踩坑记录也更全。容器化 Android 的世界很有意思，玩久了你会发现自己对 Android 系统底层的理解也上了一个台阶。