webrtc 媒体流采集权限申请指南
做音视频开发的朋友应该都清楚，webrtc 想要顺利采集麦克风和摄像头的数据，第一道关卡就是浏览器权限申请。这事儿说简单也简单——就一个 API 调用的事儿，但说复杂也复杂，因为里面涉及到用户体验、安全策略、跨平台兼容等一系列问题。
我自己在实际项目中遇到过不少坑，有时候权限请求弹窗出来了，用户点了拒绝，后续再想恢复就特别麻烦；有时候在某些移动端浏览器上，权限管理的入口藏得特别深，用户根本找不到。本文就来详细聊聊 WebRTC 媒体流采集权限申请的那些事儿，帮助你在产品设计上少走弯路。
为什么权限申请这么重要
在深入技术细节之前，我们先聊聊为什么权限申请是 WebRTC 应用的关键环节。
从技术层面来说，现代浏览器出于用户隐私保护的考虑，将摄像头、麦克风等敏感硬件设备列为需要用户明确授权的资源。这意味着你的代码不能悄无声息地访问这些设备，必须经过用户主动同意才可以。这一机制虽然增加了开发复杂度，但其实是件好事——它建立了用户对应用的信任基础。
从业务角度来说，权限申请的体验直接影响用户转化率。想象一下，用户第一次打开你的应用，想要体验视频通话功能，结果弹出一个权限申请框，用户不知道这个应用到底要干什么，担心隐私泄露，于是下意识点了"拒绝"。这时候你再去引导用户重新授权，难度就大得多了。
作为全球领先的实时音视频云服务商，声网在服务超过 60% 泛娱乐 APP 的过程中，积累了大量的权限申请最佳实践。接下来我会把这些经验分享给大家。
权限申请的基本流程
WebRTC 提供了 navigator.mediaDevices.getUserMedia 这个 API 来获取用户的媒体流权限。这个 API 的调用方式看似简单，但里面的门道不少。
核心 API 调用方式
最基础的调用代码是这样的：
navigator.mediaDevices.getUserMedia({ audio: true, video: true })
这个调用会返回一个 Promise，成功的话会得到一个 MediaStream 对象，里面包含了音频和视频轨道。你可以把这两个轨道分别添加到 RTCPeerConnection 或者 HTML 元素上进行展示和处理。
当然，你也可以单独只请求音频或视频。比如纯语音通话场景下，只传 { audio: true } 就可以了；如果是直播间观众只需要上传推流，不需要下行的视频流，那也可以只请求 { video: true }。根据实际业务需求来，能少请求一个权限就少请求一个，用户体验会更好。
权限请求的触发时机
这里有个关键点需要注意：浏览器对 getUserMedia 的调用有严格的用户手势要求。
什么意思呢？就是说你不能在页面加载完成后自动调用这个 API，也不能在 setTimeout 或者异步回调里偷偷调用。必须是用户主动触发的动作，比如点击按钮、触摸屏幕等。那些想要一进页面就开始采集视频的想法，在现代浏览器里是行不通的。
所以在设计产品流程时，通常的做法是：首次使用时展示一个"开始视频通话"或者"开启摄像头"的按钮，用户点击后才触发权限请求。这样既符合浏览器安全策略，也给用户一个心理准备。
请求参数的精细化配置
getUserMedia 不仅可以开关音视频开关，还可以对采集参数进行更精细的控制。比如：
| 参数 | 说明 |
| width / height | 视频分辨率，比如 1280x720 表示 720p |
| frameRate | 帧率，比如 30 表示每秒 30 帧 |
| facingMode | 移动端特有，控制使用前置还是后置摄像头 |
| echoCancellation | 回声消除开关，语音通话场景建议开启 |
| autoGainControl | 自动增益控制，语音场景建议开启 |
| noiseSuppression | 降噪处理，同样建议语音场景开启 |
一个更完整的请求可能是这样的：
navigator.mediaDevices.getUserMedia({ audio: { echoCancellation: true, autoGainControl: true, noiseSuppression: true }, video: { width: { ideal: 1280 }, height: { ideal: 720 }, frameRate: { ideal: 30 } } })
注意这里用的是 ideal 关键字，表示这是理想值。浏览器会尽可能满足这个需求，但如果设备不支持，会自动降级到兼容的分辨率。这比直接指定固定值要灵活得多。
处理权限申请的各种结果
调用 getUserMedia 后，可能面临三种情况：用户同意、用户拒绝、设备不可用。每种情况都需要妥善处理。
用户同意的情况
这是最理想的情况。Promise 会 resolve，返回 MediaStream 对象。接下来你需要把视频轨道绑定到 video 或者 canvas 元素上，让用户能够看到自己的画面。
一个常见的写法是：
const stream = await navigator.mediaDevices.getUserMedia({ video: true, audio: true });
const videoElement = document.querySelector('video');
videoElement.srcObject = stream;
这样做的好处是代码简洁直观。需要注意及时关闭不再使用的流，避免资源浪费和隐私风险。
用户拒绝的情况
当用户点击"拒绝"按钮时，Promise 会 reject，抛出 NotAllowedError 错误。这时候你不能直接展示一个冷冰冰的错误提示，而是要：
- 用友好的语言告诉用户为什么需要这个权限
- 提供重新申请的按钮或入口
- 引导用户如何在浏览器设置中手动开启权限
很多用户其实不是不愿意授权，而是不知道授权后会发生什么，或者不小心点错了。所以引导文案要写得清晰、有同理心。比如可以说"为了体验视频通话功能，需要获取摄像头和麦克风权限，我们承诺保护您的隐私"。
设备不可用的情况
有时候用户确实没有摄像头，或者摄像头被其他程序占用了，这时候会抛出 NotFoundError 或者 DeviceInUseError。
这种情况也需要给用户明确的提示，告诉他设备检测不到或者被占用，并建议检查硬件连接或者关闭其他使用摄像头的应用。
提升权限申请成功率的实用技巧
基于声网服务众多音视频 APP 的经验，这里分享几个提升权限申请成功率的技巧。
提前检测设备能力
在发起权限申请之前，可以先用 mediaDevices.enumerateDevices 枚举一下可用的媒体设备。这有两个好处：一是可以判断设备是否存在，避免无意义的权限请求；二是可以给用户选择的权利，比如让用户自己选择要用哪个麦克风。
enumerateDevices 返回的是一个设备列表，每个设备有 label、deviceId、kind 等属性。需要注意的是，为了保护隐私，在获得用户授权之前，label 字段会是空的，你只能看到设备类型而看不到具体名称。
预加载页面元素
很多开发者会遇到这样一个问题：用户点击开始按钮后，摄像头画面要好几秒才能显示出来。这期间用户可能会以为应用没响应，多次点击或者直接离开。
解决这个问题的方法是：提前创建 video 元素并添加到 DOM 中，甚至可以先显示一张静态占位图。这样用户点击按钮后，画面能以最快速度出现，体验流畅很多。
优雅的降级策略
不是所有设备都支持高清视频的。如果用户设备性能较差或者网络状况不好，强制请求高清流反而会导致卡顿。
一个好的做法是先请求较低分辨率，成功后再根据实际情况决定是否切换到更高分辨率。声网的 SDK 在这方面做了大量优化，能够自动根据端侧和网络情况调整码率、帧率等参数，确保通话的流畅性。
处理权限状态变化
浏览器还提供了 mediaDevices.permissionQuery 方法，可以查询当前权限状态。利用这个 API，你可以在界面上实时显示权限状态：已授权显示绿色，未授权显示灰色并提示用户点击开启。
特别是在移动端，权限状态可能会因为各种原因发生变化（比如用户手动在系统设置里关掉了），及时检测到这种变化并给用户反馈，是提升体验的重要细节。
不同平台的权限管理差异
WebRTC 在不同浏览器、不同操作系统上的表现是有差异的，权限管理机制也不例外。
桌面端浏览器
Chrome、Firefox、Safari、Edge 四大浏览器都会在首次调用 getUserMedia 时弹出权限请求框，但弹出的样式和后续的管理入口略有不同。
Chrome 和 Edge（基于 Chromium）的权限管理比较集中，都在地址栏左侧的小锁图标里，点进去可以分别管理每个站点的摄像头、麦克风权限。Firefox 的权限管理则在地址栏右侧的扩展图标里。Safari 比较特殊，除了浏览器级别的权限管理，还有系统级别的设置，需要在系统偏好设置的安全性隐私里修改。
移动端浏览器
移动端的权限管理相对复杂一些。iOS 的 Safari 和 WebView 组件会分别请求权限，但都遵循 iOS 系统的权限框架。Android Chrome 则要看具体版本和厂商定制情况，有些厂商会在系统设置里有单独的摄像头权限管理入口。
特别提醒一下，在 iOS 13 及以上版本，Apple 对 getUserMedia 做了更严格的限制。如果你在混合开发场景（比如 React Native、Cordova）中使用 WebView，需要特别注意权限请求的处理方式，有时候需要借助原生层的支持。
小程序环境
如果你开发的是微信小程序或其他小程序平台，权限申请机制和普通 Web 页面不太一样。小程序通常需要在小程序管理后台预先配置权限类目，运行时调用对应的 API 才能获取授权。
写在最后
回顾一下本文的内容，我们聊了 WebRTC 权限申请的基本流程、结果处理、实用技巧以及跨平台差异。看似一个简单的摄像头权限，其实涉及到用户体验设计、浏览器安全策略、跨平台兼容性等多个层面的考量。
在实际开发中，我建议大家不要把所有精力都放在代码实现上，更要站在用户角度思考：用户为什么愿意授权？用户授权后能得到什么好处？如何让授权过程尽可能自然顺畅？这些问题想清楚了，权限申请的成功率自然就上去了。
音视频技术的世界很大，权限申请只是冰山一角。声网作为全球领先的实时音视频云服务商，在这一领域深耕多年，积累了大量最佳实践。如果你在开发过程中遇到任何问题，或者想要了解更专业的音视频解决方案，欢迎进一步交流探讨。
