聊聊声网 rtc 设备权限申请这件事
前两天有个刚转做音视频开发的朋友问我，说他在调声网 rtc sdk 的时候，卡在设备权限申请这块了。用户一进来就是黑屏或者没声音，根本不知道是权限没给还是代码写错了。我一想，这确实是个挺容易被忽略但又特别关键的问题。设备权限申请看起来简单，但里面门道还挺多的，不同浏览器处理方式不一样，用户体验怎么做到丝滑，这些都是需要考虑的。
正好今天有空，就把这块内容系统整理一下，从原理到实现再到常见坑点，争取一篇说清楚。
为什么设备权限这么重要
在开始讲代码之前，咱们先搞明白一个基础问题：浏览器为什么要有权限这玩意儿。说白了，这就是一道安全屏障。你想啊，要是一个网页随便就能调用你的摄像头和麦克风，那还了得？随便打开个网站都能偷拍偷录，那还不得乱套了。
所以现代浏览器都做了严格的限制，必须经过用户明确授权，网页才能访问摄像头和麦克风。声网这样的实时音视频云服务商当然也不例外，不管你的 SDK 再怎么好用，底层权限这一步是绕不开的。
这里有个点值得注意，权限不仅关乎功能能不能用，还直接影响用户体验。用户第一次进来如果就遇到弹窗拒绝，后面再想让他重新授权，那可得费一番功夫了。所以权限申请的时机、方式、提示语，这些细节都得精心设计。
浏览器权限机制是怎么运作的
说到浏览器现在的权限机制，得从 HTML5 的 MediaDevices API 说起。这个 API 是浏览器访问音视频设备的标准方式，绝大多数现代浏览器都支持。声网的 SDK 底层也是基于这个 API 实现的，所以咱们前端调用的时候，其实就是在跟这个 API 打交道。
浏览器对权限的管理分三种状态，咱们得心里有数：
- granted（已授权）：用户点了允许，设备可以正常使用
- denied（已拒绝）：用户点了拒绝，或者之前拒绝过多次被浏览器拉黑了
- prompt（需要询问）：第一次或者之前没操作过，会弹窗问用户
这三种状态里，"denied"是最麻烦的。一旦用户点了拒绝，浏览器就不会再自动弹窗了，得用户自己手动去设置里开，这对转化率影响挺大的。所以咱们代码里得做好各种情况的处理。
另外有个趋势得说一下，苹果的 Safari 浏览器这两年对权限管得越来越严，特别是 iOS 端，有时候你代码写得没问题，但它就是不弹窗，得用户主动交互几次才行。这个后面会详细讲解决方案。
声网 RTC 权限申请的前端实现
第一步：检测浏览器支持情况
不是所有浏览器都支持 MediaDevices API 的，虽然现在主流浏览器基本都支持，但保不齐有用户用的是特别老的版本。所以第一步咱们得先检测一下，让代码有个降级处理。
检测方式其实很简单，就是判断 navigator 对象下有没有 mediaDevices 这个属性。如果都没有，那就直接提示用户换个浏览器吧，这锅咱不背。
第二步：检查当前权限状态
直接调授权弹窗有点太莽撞了。更好的做法是先看看当前是什么状态，如果是已经授权过的情况，就没必要再弹一次了。浏览器提供了 query 方法可以查状态。
这里有个小技巧，查询权限不会触发弹窗，所以可以放心用。查完之后根据状态决定下一步动作：已经授权的可以直接初始化 SDK；需要询问的再弹窗；被拒绝的就得引导用户去手动设置了。
第三步：发起授权请求
正式请求权限的时候，核心是 getUserMedia 这个方法。声网的 SDK 内部会帮我们调这个方法，但有时候咱们前端也得自己调一下，特别是在需要预先检查权限或者自定义 UI 场景的时候。
调用的时候可以指定要什么设备，摄像头还是麦克风，还是都要。建议是一起要，不然分开要两次用户会烦死。参数方面，video 和 audio 都设为 true 就行，具体的分辨率什么的可以后续再配置。
第四步：处理授权结果
授权请求是异步的，返回的是一个 Promise。成功的话会拿到媒体流，失败的话会抛出异常。这里重点说说失败的情况，因为失败的原因有很多种，应对方式也不一样。
最常见的是用户点了拒绝，这种情况下错误信息里会带着相应的提示。还有可能是设备被其他程序占用了，比如微信视频通话占着摄像头，这时候浏览器也会失败。另外还有些奇奇怪怪的原因，比如设备驱动问题、浏览器权限设置问题等等。
代码层面一定要做好 catch 处理，别让页面直接崩了。失败了要给用户友好的提示，告诉它可能是什么原因，能怎么解决。
不同浏览器的差异处理
这才是真正的难点。不同浏览器对权限的处理方式存在差异，特别是 Safari 和 Chrome 之间，有时候能让人怀疑人生。
| 浏览器 | 特点说明 |
| Chrome | 最规范的实现，第一次会弹窗询问，允许后后续不再弹窗。需要注意 https 限制。 |
| Safari（Mac） | 对权限管理比较严格，如果用户拒绝过，可能需要用户手动去偏好设置里开。 |
| Safari（iOS） | 最麻烦，必须有用户主动交互才能触发权限弹窗，而且交互次数可能不止一次。 |
| Firefox | 整体和 Chrome 类似，但UI上有差异，功能上没什么大问题。 |
| Edge | 基于 Chromium 内核，和 Chrome 差不多，但有些版本会有自己的小问题。 |
针对 Safari，特别是 iOS 端的 Safari，业界有个通用的做法：让用户先点击一个按钮，用这个点击交互来触发权限请求。如果第一次没成功，可能需要引导用户多点几次或者用其他方式。
另外还有个小提示：Chrome 在某些情况下，比如页面不是通过 https 访问的，会直接拒绝权限请求，连弹窗都不弹。这个一定得注意，部署的时候记得检查证书。
提升用户体验的实用技巧
权限申请这事儿看着小，但做不好的话用户可能就直接流失了。下面分享几个实用的技巧，都是实战中总结出来的。
时机选择
什么时候触发权限请求？这事儿得有讲究。别一进页面就弹，用户还没搞清楚你要干嘛呢。更合理的做法是：先展示一个预览页面或者引导页，告诉用户接下来要使用摄像头和麦克风做什么，然后让用户自己点击按钮触发授权。这样既符合用户预期，又能提高授权通过率。
话术设计
浏览器自带的权限弹窗话术是系统级的，咱们改不了，但弹窗之前的引导页面是可以精心设计的。比如别说"需要获取摄像头权限"，可以说"开启视频通话需要使用您的摄像头"，把用途说清楚，用户更愿意授权。
失败后的引导
用户拒绝之后别傻傻地就不管了。应该给一个明确的提示，告诉它怎么去设置里手动开启。不同浏览器的设置路径不一样，可以根据 User-Agent 判断一下，然后给出对应的指引。
另外，被拒绝之后可以试试换一个摄像头或者麦克风设备再请求，有些用户电脑上有多个摄像头，换一个可能就成功了。当然这个要看具体场景，不是所有应用都适用。
常见问题排查清单
最后整理一下常见的问题和排查思路，万一遇到情况可以对号入座。
- 完全没弹窗：先检查是不是 https，再检查浏览器是否支持 MediaDevices，还要看看是不是已经授权过处于 granted 状态
- 弹窗了但获取失败：看具体错误信息，NotFoundError 是找不到设备，NotAllowedError 是用户拒绝，NotReadableError 是设备被占用
- iOS Safari 总是失败：确认有足够的用户交互，可能需要增加点击次数，或者考虑用 Safari 的专用 API
- Mac Safari 拒绝后无法再弹：这个是系统机制问题，必须用户去系统偏好设置里改
- Android Chrome 兼容问题：部分机型可能存在兼容问题，可以考虑用声网 SDK 的兼容模式
写在最后
设备权限申请这事儿，说大不大说小不小。往简单了说就是个 API 调用，但往深了说涉及到浏览器安全机制、用户体验设计、多平台兼容性方方面面。特别是像声网这种做全球化音视频服务的，面对的用户设备千奇百怪，更得把这些细节打磨到位。
希望这篇内容能对正在做音视频开发的朋友有所帮助。如果你也在这块遇到过什么奇葩问题，欢迎交流讨论。
