在 Linux 上玩安卓游戏

Overview

参考文档：Waydroid Documentation
在 Linux 桌面上跑安卓游戏有三条主要路线，体验与重量级依次递增：
- 投屏路线：手机连数据线，scrcpy 把画面与输入镜像到桌面——最简单，但游戏仍在手机上跑
- 容器路线：Waydroid 在 Linux 上以 LXC 容器运行完整 Android 系统，性能接近原生，是玩大型手游的主流方案
- 虚拟机/模拟器路线：Android Studio 的 AVD(带硬件加速的 x86 镜像)，或 redroid/anbox 等方案，隔离最彻底但性能或维护性各有短板
本文以 Waydroid 为主线，拆解它依赖的每一层：容器、显示(cage)、内核(binder)、网络(NAT)与指令集转译

Waydroid 是一个基于 LXC 的容器化 Android 方案：
- 它不是虚拟机——Android 容器与宿主共享同一个 Linux 内核，没有 CPU 虚拟化开销，图形直通 Wayland，性能接近原生
- 容器内运行的是完整的 Android 系统镜像(基于 LineageOS 构建)，包含 system 与 vendor 两个分区，通过 LXC 的命名空间(pid/mount/net…)与宿主隔离
- Android 的两大前提由宿主内核提供：
  - binder：Android 全部进程间通信的基石，对应内核模块 binder_linux(新内核通过 binderfs 挂载)；这是 Waydroid 对宿主内核最硬性的要求，主线内核 5.18+ 已内置，老内核需自行确认模块可用
  - ashmem：旧版共享内存机制，新版 Android 已迁移到 memfd，但部分老镜像仍需 ashmem_linux 模块
使用形态：
- 多窗口模式：Android 应用作为普通 Wayland 窗口与桌面应用并排使用，体验类似"安卓模拟器的窗口模式"，但对宿主而言只是普通客户端
- 全屏模式：整个 Android 桌面独占一个 Wayland 会话，适合接电视或掌机上当"安卓游戏机"

cage 是基于 wlroots 的kiosk 式合成器(合成器与 wlroots 的背景见 Linux 显示协议与图形栈)——整个会话只显示一个全屏应用，没有窗口管理、没有任务栏，极简到只做"把一个客户端铺满屏幕"
它在安卓游戏场景的价值：
- 嵌套运行：在 GNOME/KDE 等桌面会话内，用 cage 包一层再启动 Waydroid 全屏，Android 画面即独占一个桌面窗口，输入与焦点都交给它，避免多窗口模式下游戏误触返回键、焦点漂移等问题
- 独立会话：也可以从显示管理器直接登录 cage 会话，里面只跑 Waydroid，整个机器变成一台安卓游戏机——层级最少、延迟最低
- 依赖轻(wlroots 一套)，老设备上比完整桌面环境省一大截资源
类似的嵌套合成器还有 gamescope(Valve 出品，带 FSR 缩放与帧率限制)，两者在"给游戏一个干净的画布"这件事上定位重叠，gamescope 偏游戏滤镜与缩放，cage 偏极简 kiosk

Waydroid 的网络与 Docker/LXC 容器同源，理解它对排查"游戏没网"至关重要：
- 虚拟以太网对(veth pair)：宿主创建一对虚拟网线，一端留在宿主网络命名空间，另一端塞进 Android 容器，成为容器内的网卡
- NAT 转发：宿主侧的 waydroid-net.sh 脚本负责配地址、开 IP 转发，并用 iptables 或 nftables 写 NAT 规则，让容器流量伪装成宿主流量出公网——手机游戏看到的网络环境与一台普通 NAT 后的设备无异
- 常见坑：宿主若同时跑 Docker 或 firewalld，两边的防火墙规则可能互相覆盖，导致容器内 DNS 正常但 HTTP 全断；这类问题排查方向就是检查 iptables/nftables 规则表
由于容器与宿主共享内核，WireGuard 等内核级 VPN 的可用性取决于宿主内核是否提供相应模块(5.6+ 主线已内置)，而不是镜像自带与否；想让游戏走代理/加速器，在宿主配好再让容器流量跟随即可

Waydroid 官方镜像不含 Google 服务，但多数国产手游不依赖 GApps，只挂网络与时间同步即可运行
需要谷歌服务的游戏(登录、推送、内购)要额外处理：
- 安装社区维护的 GApps 包(Waydroid 提供 sud 脚本刷入 vendor 分区)
- 刷入后需通过 设备认证：未认证设备登录谷歌账号会受限，每账号每年有少量手动认证名额(把自己的设备 ID 提交给谷歌白名单)
- 这一步是 Waydroid 体验中最繁琐的部分，也是与真机最大的差异点

Waydroid 容器跑的是 x86_64 架构的 Android，但大量手游只发布 ARM 版 so 库：
- libhoudini(Intel 出品)与 libndk(谷歌 NDK 自带的转译层)：把 ARM 指令动态转译为 x86 指令，原理类似 Rosetta 2，性能有损耗但多数游戏可玩
- 两者以闭源组件形式注入镜像(社区脚本把对应 so 塞进 system 分区)，不是 Waydroid 官方功能，版本与 Android 大版本需要匹配
- 判断游戏是否需要转译：安装后启动闪退、日志中提示找不到 ARM 库，基本就是缺转译层
转译层对性能敏感的游戏(高帧率 3D 手游)损耗明显，这类游戏更现实的方案是配帧率限制 + 降画质，或改用真机 + scrcpy

scrcpy：USB/网络连接真机，40ms 级延迟的镜像投屏，键鼠映射，适合"手机就在旁边、只想要大屏"的场景
redroid：Docker 化的远程 Android(remote android)，在服务器上跑、用串流访问，支持多实例，适合挂机类手游的农场/日常，不适合实时操作
AVD(Android Studio 模拟器)：QEMU/KVM 虚拟化 + x86 镜像，开发调试为主，游戏性能与手感不如 Waydroid
anbox：容器化安卓的前辈，已基本停止维护，新用户直接选 Waydroid