AIRI 移动端性能优化调查：从 WebView 到 Unity 渲染引擎的集成路径与基准测试

AIRI 移动端性能优化调查：从 WebView 到 Unity 渲染引擎的集成路径与基准测试

【免费下载链接】airi💖🧸 Self hosted, you-owned Grok Companion, a container of souls of waifu, cyber livings to bring them into our worlds, wishing to achieve Neuro-sama's altitude. Capable of realtime voice chat, Minecraft, Factorio playing. Web / macOS / Windows supported.项目地址: https://gitcode.com/GitHub_Trending/ai/airi

本篇开发日志记录了 AIRI 移动端（stage-pocket）性能优化的初期调查：当 Live2D 与 VRM 模型渲染在 iOS 和低端 Android 的 WebView 中频繁触发内存崩溃时，团队如何系统性地评估"以游戏引擎接管渲染"的可行性。文中完整梳理了问题分析、候选引擎评估、Unity 混合架构设计、三套原型构建过程与 Samsung A34 实测基准数据，并给出后续决策的评估标准与下一步计划。

背景：移动端为什么需要性能优化

AIRI 的移动端应用stage-pocket并非独立开发的客户端，而是把主 Vue.js 应用原样复制后，用 Capacitor 直接打包而成。从 package.json 的依赖清单可以印证这一点：它直接引用了@proj-airi/stage-ui-live2d、@proj-airi/stage-ui-three、three与@tresjs/core等 Web 端渲染栈，也就是说Live2D 与 VRM 的渲染全部跑在移动 WebView 里。

这种"一套代码、Web 与移动通吃"的架构在桌面上没有问题，但在手机上暴露出明显短板：Live2D / VRM 组件会快速耗尽 WebView 分配到的内存，尤其在 iOS 与低端 Android 设备上直接导致进程崩溃。这正是本次调查的出发点——评估引入游戏引擎或其他技术方案来接管渲染的可行性。

问题分析

观察到的现象

• Live2D / VRM 模型渲染时内存占用极高
• iOS 与低端 Android 设备上崩溃频繁
• 长时间运行后性能持续劣化

怀疑的根因

• WebView 内存泄漏
• Three.js 在移动处理器上的渲染性能不足

当前架构概览

移动端构建技术栈

Capacitor 配置见 capacitor.config.ts：appId会根据构建目标自动切换（Android 为ai.moeru.airi_pocket，其余为ai.moeru.airi-pocket），Android 发布构建支持通过环境变量注入 keystore 签名参数，并以APK+apksigner的方式出包。这些细节说明移动端目前完全是标准 Capacitor 工作流，渲染层没有任何原生介入。

当前渲染流程

Vue UI ↓ WebView ↓ Three.js / Live2D / VRM ↓ Capacitor ↓ GPU

原生侧已有的桥接基础

虽然渲染完全在 WebView 内，但原生层并非一片空白。stage-pocket的 README 说明它针对@proj-airi/server-sdk增加了 host 承载的 WebSocket 桥接，设计约束包括：只实现 server-sdk 所需的桥接能力、socket I/O 归原生层、重连/心跳/鉴权/连接状态归 server-sdk、桥接仅转发connect、send、close、open、message、error等事件。Android 侧对应实现为HostWebSocketBridge.kt，iOS 侧为HostWebSocketBridge.swift。这意味着"Vue 与原生层双向通信"的通道在项目里已有先例，后续接入 Unity 原生渲染层时，桥接复杂度可以部分复用这套经验。

移动端的性能约束

WebView 的固有限制

• 相比原生应用，WebView 可分配的内存额度显著更低
• 垃圾回收（GC）行为难以预测，容易出现卡顿尖峰
• GPU 内存压力过大时，进程可能直接被系统终止

设备差异带来的限制

• iOS WebView 存在明确的内存上限，超出即被杀进程
• 低端 Android 设备 RAM 有限，多任务场景下更容易触发回收

这些约束决定了：只要渲染还留在 WebView 内，Live2D / VRM 这类 GPU 密集的模型渲染就始终在"内存悬崖"边缘运行，这也是本次调查把目光投向游戏引擎的根本原因。

游戏引擎集成探索

候选引擎盘点

2D

• PixiJS
• Cocos Creator
• Unity
• Godot
• Bevy
• Unreal Engine

3D

• Three.js
• Babylon.js
• Unity
• Godot
• Unreal Engine
• 自研的定制 3D 引擎

三种集成策略

必须支持的能力

• Live2D
• MMD
• VRM
• Spine2D

值得一提的是，仓库中engines/stage-tamagotchi-godot已经存在一条"引擎接管渲染"的独立探索路径：桌面端stage-tamagotchi用 Godot 作为 sidecar 运行时，通过 WebSocket 接收 Electron 传入的.vrm文件路径，由VrmRuntimeImporter.gd在运行时导入并渲染，UI 仍留在 Electron/Vue 侧。这条"引擎渲染 + Vue UI"的分工模式与本文讨论的混合架构思路一致，可以作为移动端方案的架构参照。

Unity 集成提案

渲染责任分工

Unity 负责：

• VRM 渲染
• Live2D 渲染
• 动画
• 物理（如有需要）

Vue / WebView 负责：

• UI
• 设置
• 网络请求

提议的混合架构

Vue UI ↓ Native Bridge ↓ Unity Runtime ↓ Capacitor ↓ GPU

核心思路是把最吃内存与算力的模型渲染从 WebView 移到 Unity 原生运行时，让 Vue 继续负责交互、设置与网络这类对内存不敏感的 UI 事务。

原型构建

为了验证 Unity 方案的可行性，团队用 Unity 3D 构建了三套原型，并对导出体积做了压缩处理。

Unity WebGL 导出设置

Unity Android 渲染器导出设置

截图

Android 渲染器 — Live2D：

Android 渲染器 — VRM：

为保证变量可控，三套原型全部使用同一个 Vue.js 前端。两种集成方式的具体做法：

• Unity WebGL 导出：借助社区开源的unity-webgl集成方案，把 WebView 里的原有内容直接替换为 Unity WebGL；
• Unity Android 渲染器：完全移除原先承载 Three.js 与 VRM 模块的视图，由 Unity 作为背景层渲染，在其上方叠加 Vue.js UI。

基准测试结果

所有测量都在同一条件下使用Samsung A34完成。为了更明显地暴露性能差异，团队刻意选择了低端设备作为测试基准。

Live2D 渲染

VRM 渲染

关键观察

• VRM 是决定性瓶颈。基线 Three.js VRM 渲染器总 RAM 达 724 MB、图形内存达 566 MB，远超大多数移动 WebView 不崩溃的承受上限；Unity WebGL 将其压到 402 MB / 247 MB，Android 渲染器为 651 MB / 292 MB。
• Unity WebGL 在 VRM 场景下内存画像最优，且对现有架构的改动最小，代价是 CPU 占用率略有上升。
• Unity Android 渲染器的帧率与 CPU 效率最好，但总 RAM 偏高——这是 Unity 运行时自身开销带来的预期结果，GPU 工作已完全移出 WebView。
• Live2D 三套方案表现接近。基线 Three.js 实现在多数 Android 设备上已够用，切换引擎的主要收益在于为未来不断增多的内容留出余量，以及提升低端设备上的稳定性。

参考截图

Three.js — Live2D（基线）：

Unity WebGL — Live2D：

Unity Android 渲染器 — Live2D：

Three.js — VRM（基线）：

Unity WebGL — VRM：

Unity Android 渲染器 — VRM：

风险评估

评估标准

后续所有原型与引擎选型决策，都应持续测量以下指标，保持口径一致：

• 内存占用（RAM 与 GPU）
• 持续负载下的 FPS 稳定性
• 启动 / 冷启动时间
• 构建与安装体积
• 电池消耗
• 开发复杂度
• 长期可维护性

下一步计划

1. 评估桥接复杂度

调研 Unity 官方 "Unity as a Library" 集成示例或类似插件，打通双向通信——典型场景是：聊天触发的表情变化需要从 Vue 侧传给 Unity 渲染层执行。

2. iOS 专属原型

iOS 是 WebView 内存限制最严苛的环境，下一套原型必须在 iPhone 上验证 Unity 原生层能否绕开 "Total Safari Memory" 上限。

3. 构建体积优化

利用 Unity 的资产管理机制，把首次安装体积维持在最小水平。

4. 社区与贡献者招募

为保证项目长期可维护，需要明确未来贡献者应具备的技能要求（Unity / C#、着色器编写）。

结语：一条可供复现的评估路线

从本日志可以看到，移动端渲染优化的核心矛盾在于"功能栈（Live2D/VRM/MMD/Spine2D）与运行时（WebView 内存上限）"之间的张力。AIRI 的做法值得借鉴：不急于选型，而是先建立可复现的基准（统一低端设备 + 统一测量指标），再用多套原型分别验证架构改动最小化（Unity WebGL）与性能最优化（Unity Android 原生渲染器）两个极端，最后用数据驱动决策。对于同样面临 WebView 渲染瓶颈的移动应用团队，这套"问题分析 → 候选引擎盘点 → 混合架构设计 → 多原型实测 → 风险评估"的流程可以直接套用。

【免费下载链接】airi💖🧸 Self hosted, you-owned Grok Companion, a container of souls of waifu, cyber livings to bring them into our worlds, wishing to achieve Neuro-sama's altitude. Capable of realtime voice chat, Minecraft, Factorio playing. Web / macOS / Windows supported.项目地址: https://gitcode.com/GitHub_Trending/ai/airi