HTML5转APP后不能直接调用手机AR能力，因WebView默认禁用深度传感器、平面检测等关键接口，需通过原生AR模块双屏协同实现，即HTML控制指令、原生渲染AR。
HTML5转APP后能否直接调用手机AR能力
不能原生支持。HTML5本身不提供AR硬件访问接口，WebView（如Android的WebView、iOS的WKWebView）默认禁用摄像头深度数据、IMU传感器、AR会话管理等关键能力。即使使用getUserMedia拿到摄像头画面，也拿不到ARKit/ARCore所需的锚点、平面检测、光照估计等信息。
主流HTML5转APP方案对AR的支持现状
不同打包工具对AR的兼容性差异极大，选错方案会导致功能完全不可用：
-
Cordova / Capacitor：需通过插件桥接原生AR SDK，例如
cordova-plugin-arcore（仅Android）、cordova-plugin-arkit（仅iOS），但维护状态差、API不稳定，且无法在WebView内直接渲染AR内容 -
React Native Web + native modules：可行但需彻底分离逻辑——HTML5部分只做UI层，AR场景用原生View（
ARSCNView或ArFragment）全权接管，通过JSI或事件总线通信 -
Flutter + webview_flutter：同理，
webview_flutter不支持WebXR，必须用flutter_ar等插件启动独立AR页面，HTML5页只能触发跳转 -
PWA + standalone mode：目前所有移动端浏览器均不支持
WebXR AR module（Chrome for Android已实验性支持WebXR，但需手动开启flag且无平面检测）
可行路径：WebView与原生AR模块双屏协同
这是当前最稳定、上线项目验证过的做法，核心是放弃“在HTML里跑AR”，改为“HTML控制AR”：
- APP主容器用原生实现AR视图（Android用
ArFragment，iOS用ARSCNView），隐藏系统UI，保持后台运行 - HTML5页面通过
window.ReactNativeWebView.postMessage（React Native）或cordova.exec（Cordova）发送指令，如{"action":"placeObject","model":"chair.gltf"} - 原生层解析指令，调用AR SDK加载模型、添加锚点；再用回调把位置、旋转等数据传回HTML页用于同步UI（如2D标签跟随）
- 注意
gltf资源必须预置在APP包内或从HTTPS加载（iOS ATS限制），不能依赖HTML本地路径
WebXR不是银弹：兼容性与性能现实
即便目标平台支持navigator.xr，仍面临硬性限制：
立即学习“前端免费学习笔记（深入）”；
- Android Chrome 113+ 仅支持
immersive-ar会话类型，但要求设备预装ARCore Services，旧机型（如Pixel 3a）会静默降级为inline模式 - iOS Safari 完全不支持
WebXR，AR Quick Look（.usdz）仅支持点击触发，无法与HTML交互 - WebGL2在低端Android WebView中常被禁用，导致
three.js+webxr示例白屏，需fallback到Canvas2D简易示意 - AR渲染帧率直接受WebView GPU进程调度影响，实测在Cordova中
requestAnimationFrame可能卡顿至20fps以下
真正落地时，别纠结“能不能在HTML里写AR”，先确认用户设备型号、系统版本、安装渠道（应用商店 or 企业签名），再决定是走双屏桥接，还是直接切原生AR模块主导流程。
