WebGL 技术选型调研报告

虚拟形象要上 Web 端，先回答三个问题：移动端浏览器对 WebGL 的支持到底什么水平、Unity 构建的 WebGL 包能不能在手机上跑起来、WebGL 2.0 敢不敢当基线。调研结论：Three.js + WebGL 1.0 + 机型分级。

WebGL 1.0 支持率≈90%+

WebGL 2.0 支持率≈60%

iPhone 8 实测15→30fps

背景

虚拟形象要覆盖尽可能多的用户设备，而 B 站用户的入口大量在微信内置浏览器和各类国产浏览器里。选型不能只测 Chrome，必须把真实用户分布里的浏览器都拉进来过一遍。调研围绕三个核心问题展开：

1. 移动端浏览器的 WebGL 兼容性如何？
2. Unity 构建的 WebGL 体积和加载速度能否接受？
3. WebGL 2.0 的覆盖率够不够当基线？

问题

选型阶段的风险不是「技术上能不能做」，而是「做完发现某个大盘入口跑不起来」。三个待验证的假设：

• 假设 A：WebGL 已经是移动端标配 → 需要用真实浏览器矩阵验证，尤其是微信和国产浏览器；
• 假设 B：Unity WebGL 可以复用现有 Unity 工程，省去重写 → 需要实测包体、加载时长、内存；
• 假设 C：WebGL 2.0 可以直接当基线 → 需要看覆盖率数据。

调研结果

移动端浏览器兼容性

浏览器	WebGL 1.0	WebGL 2.0	备注
Chrome Android	✅	✅	完全支持
Safari iOS	✅	⚠️ 有限	内存限制严格
微信内置浏览器	✅	❌	仅 WebGL 1.0
百度浏览器	⚠️	❌	部分低端机不支持
UC 浏览器	✅	❌	WebGL 1.0

结论：WebGL 1.0 支持率约 90%+，WebGL 2.0 仅约 60%。微信内置浏览器这条大盘入口直接卡死 2.0——假设 C 证伪，基线必须是 WebGL 1.0。

Unity WebGL 体积与加载速度

项目类型	WASM 体积	首次加载	内存占用
空项目	~4MB	~3s	~80MB
简单 3D	~10MB	~8s	~150MB
虚拟形象	~20MB+	~15s	~300MB+

空项目就要 4MB / 3s / 80MB 起步，虚拟形象量级直接到 20MB+ / 15s / 300MB+——这个内存水位在移动端浏览器里已经踩到崩溃线。假设 B 证伪：Unity WebGL 只适合高端机，当不了普适方案。

iPhone 8 真机验证

在 iPhone 8（2017 年发布，当主力低端参照机）上跑同一个虚拟形象：

• Three.js 方案：15fps， profiling 后确认可优化到 30fps；
• Unity WebGL：无法加载，内存不足直接崩溃。

方案

flowchart TD
  A["设备进入"] --> B{"WebGL 1.0 可用？"}
  B -->|"否（约 10%）"| C["降级：2D 形象/静态图"]
  B -->|"是"| D{"机型分级"}
  D -->|"高端机"| E["高精度模型<br>完整材质"]
  D -->|"低端机"| F["简化模型<br>压缩纹理"]
  E --> G["Three.js 渲染<br>WebGL 1.0 基线"]
  F --> G

最终建议定型为三句话：Three.js + WebGL 1.0 基线；后台按机型分级，高端机高精度模型、低端机简化模型；资源侧配合 KTX2/Draco 把下载和显存压下来（压缩方案见 KTX2 与 Draco 压缩方案）。

指标

调研项	结论数据
WebGL 1.0 支持率	约 90%+
WebGL 2.0 支持率	约 60%
Unity WebGL 虚拟形象	~20MB+ / ~15s / ~300MB+
Three.js on iPhone 8	15fps，可优化到 30fps

复盘

1. 选型调研要用「真实用户入口矩阵」而不是「工程师的浏览器」——微信内置浏览器一项就推翻了 WebGL 2.0 基线。
2. Unity WebGL 的空项目基线（4MB/80MB）已经说明了它的下限，不要指望靠优化把 runtime 开销压没。
3. 真机验证要挑发布时间久的走量机型（iPhone 8 这类），旗舰机上的「能跑」没有信息量。
4. 调研的价值在于证伪：三个假设证伪了两个，剩下那条路（Three.js + 分级）反而是最踏实的。