webview模式调用摄像头，式调坑比你想的用摄多

上周接了个需求，要在App的式调webview里做个扫码功能。本来以为调起摄像头是用摄分分钟的事，结果折腾了两天。式调Android端还好，用摄iOS端直接白屏，式调连权限弹窗都没弹出来。用摄

先说结论：webview调用摄像头，式调核心就卡在权限和协议上。用摄你写的式调网页在PC浏览器里能跑，不代表塞进webview就能跑。用摄这里有个最容易被忽略的式调点——webview默认不认getUserMedia，除非你在原生层显式配置。用摄

Android端：配置清单别漏项

Android的式调webview要调摄像头，光在网页里写navigator.mediaDevices.getUserMedia是不够的。你得在原生代码里给WebChromeClient重写onPermissionRequest方法，手动授予权限。我见过很多新手直接new WebView()就开干，结果摄像头永远黑屏，还以为是JS写错了。

webView.setWebChromeClient(new WebChromeClient() {  @Override public void onPermissionRequest(PermissionRequest request) {  // 必须在这里grant，否则网页拿不到摄像头 request.grant(request.getResources()); } });

但这还没完。Android 6.0以上运行时权限得动态申请，Manifest里也得写上CAMERA权限。最恶心的是，部分国产ROM还会拦截webview的摄像头调用，比如MIUI默认禁止“后台弹出界面”，得让用户手动去设置里开。这活儿没法自动化，只能写个引导页让用户点两下。

iOS端：WKWebView的坑更隐蔽

iOS的WKWebView默认连getUserMedia都不支持，直到iOS 14.3才加了个开关。你得在Info.plist里加NSCameraUsageDescription，这大家都知道。但真正坑的是——WKWebView必须用HTTPS协议才能调摄像头。你拿个http的测试地址，直接静默失败，连报错都不给你。

还有个无语的细节：iOS模拟器永远调不起摄像头，只有真机才行。我同事调试时以为代码有问题，重装了三次App，最后发现是模拟器限制。真机跑通后，还得注意页面滚动时摄像头画面会闪烁——这是WKWebView的渲染bug，目前没官方修复，只能靠原生层做layer融合勉强压下去。

网页侧代码没那么简单

别以为原生配置好了就完事。网页里的JS也要处理兼容。比如Safari 14以下的版本不支持enumerateDevices，你得写fallback。还有，用户点了“允许”后，摄像头启动是异步的，你得监听loadedmetadata事件，否则直接play视频流会报AbortError。

navigator.mediaDevices.getUserMedia({  video: {  facingMode: 'environment' } }) .then(stream => {  video.srcObject = stream; video.onloadedmetadata = () => {  video.play(); }; }) .catch(err => {  // 注意：用户拒绝时错误名是NotAllowedError，别和权限配置混淆 console.warn('摄像头错误:', err.name); });

调试建议：别信浏览器模拟器

我最后悔的是花了俩小时在Chrome DevTools里模拟设备调试，以为一切正常。结果真机一跑，白屏。webview和浏览器内核版本差异太大，尤其是Android碎片化，同是WebView，小米和三星的Chromium版本能差三个大版本。

建议直接拿真机连USB调试，用chrome://inspect看console日志。iOS就用Safari开发者工具。另外，把webview的setDomStorageEnabled(true)打开，有些扫码库依赖localStorage存临时token，不开直接报错。

这活儿说白了就是三层配合：原生授权、webview配置、网页JS。任何一层漏了，摄像头就罢工。最后提醒一句，别用iframe嵌摄像头页面，iOS上iframe里的getUserMedia会被拦截，血泪教训。