移动端 WebXR 隐藏坑?

我第一次在手机上跑 WebXR 的时候，心里其实挺激动的，想着浏览器一开，AR、VR 体验就都齐活了。结果真上手才发现，移动端这玩意儿根本不是“能跑就行”，而是处处都在考验耐心：屏幕一旋转，画面抖一下；切到沉浸模式，按钮突然没了；一接上手柄，交互又像在跟你捉迷藏。说白了，移动端 WebXR 最可怕的地方，不是“不能用”，而是“看起来能用，实际全是暗坑”。

先别急着怪设备，很多坑其实出在浏览器

我踩过最离谱的一次，是在安卓手机上调试一个 AR 页面，页面明明加载正常，navigator.xr 也在，结果一点进入体验就失败。后来才发现，不是代码写错，而是浏览器版本和权限策略不一致。移动端浏览器很现实：支持 WebXR 的设备不一定支持你想要的 session 类型，inline、immersive-vr、immersive-ar 这三个模式，真不是“有一个就行”。

更烦的是，不同浏览器对摄像头、陀螺仪、传感器权限的提示顺序都不一样。用户点一次没反应，就直接关页面了。我们做移动端 WebXR，很多时候不是在做技术，是在和用户耐心赛跑。

机型一多，性能就开始“现原形”

桌面端能跑 60 帧的场景，到了手机上可能直接掉到 20 多帧，尤其是中端机。别小看一块阴影、几张大图、一个稍微复杂点的模型，手机 GPU 真的会当场罢工。

我后来做项目时学乖了，直接把贴图压成 KTX2，模型拆 LOD，场景里能合并的几何体全合并。效果很明显，原来发热半小时后开始卡顿，优化完以后至少能稳住一段时间。移动端 WebXR 的性能问题很像挤地铁，平时看着还能站下，一旦人一多，整个体验就崩了。

触控交互，真的没有你想得那么顺

很多人会默认：手机屏幕嘛，点一下不就完了？可 WebXR 里的交互远没这么简单。进入沉浸模式后，原来的 DOM 按钮可能不见了，触控事件也未必还按你预期工作。尤其是你既想支持手指点击，又想兼容头显控制器时，逻辑一乱，用户就会觉得自己在和页面抢控制权。

我比较有感触的一点是：移动端一定要给交互留“退路”。比如一个对象不能只靠拖拽，最好还能点一下高亮；一个入口不能只靠 XR 按钮，普通模式也得能看内容。否则用户一旦没进沉浸模式，整个页面就像少了半个脑子。

还有一个隐蔽问题：手机浏览器的界面会“吃掉”你的布局

这个坑特别阴。手机地址栏、底部工具栏、刘海屏安全区、横竖屏切换，每一个都可能把你的画布挤变形。你以为是 100vh，实际浏览器给你的可视区域根本没那么听话。

我现在都会单独做一层适配逻辑，不再迷信单纯的 CSS 视口单位。尤其是进入 XR 之前，先把界面状态收一收，不然按钮重叠、文本跑位、点击区域偏移，这些问题足够让一个本来很酷的 demo 变成“翻车现场”。

我现在最怕的，不是 bug，而是“能演示不能上线”

移动端 WebXR 最隐藏的坑，其实就是它太容易在演示时成功，太容易在真实用户手里翻车。你在实验室里用的是旗舰机、稳定网络、开发者模式；用户那边可能是旧安卓、低电量、浏览器限制、后台一堆应用在抢资源。

所以我现在做这类项目，都会先问一句：这个体验，用户是在什么场景下打开？站着玩、坐着玩，还是在地铁里随手点开？答案不同，设计就完全不同。WebXR 在移动端不是不能做，是真的得把“最差情况”也算进去，不然最后很容易变成——你以为做的是未来，用户体验到的却是卡顿和闪退。