背景
如今大家平时使用的主流的设备，并不是所有的浏览器以及 WebView 环境都支持 WebRTC 所有功能的正常使用。
做 ToB 在平时是会遇到一些不熟悉相关技术栈的开发者，在一些支持度不够好的环境下使用了 TRTC，发现不能正常进行音视频通话。如果在不合适的环境使用，并不清楚究竟是什么原因导致的，因此在提工单的时候描述也不够清楚，在排查问题的时候就会花费很久来进行沟通。
因此希望检测工具可以对一些小白开发者提问的比较低级的客诉问题进行前期指引，以此来降低低质量工单，同时为排查问题提升沟通效率。
思考
为了优化这些问题，我们需要解决下面这些问题：
- 需要帮助开发者快速获取使用者环境状态。
- 帮助开发者完善应用启动流程。
- 处理开发者问题的时候，节约时间，快速区分问题根本原因。
- 检测的数据需要全面且准确。
- 汇总数据来定期回顾共性问题，以优化 SDK 的接入体验。
目标
完成 rtc-detect.js 检测模块，发布至 npm
- 调用方法可以获得当前设备各种兼容性、接口、设备等基础信息
- 可以知道常见的，比如是否支持推拉流基础功能，以及其他高级能力的支持度
完成 TRTC 检测页面的开发
- 一些技术支持的同学在帮助开发者排查问题时，开发者或者应用使用者在相同环境使用出问题设备访问页面，然后将环境报告生成图片，可以方便排查问题
- 进行问题页面的数据统计，确定出问题场景的原因和设备
检测内容
1. HTTPS
出于对用户安全、隐私等问题的考虑，浏览器限制网页在 https 协议下才能正常使用 WebRTC 的全部功能。为确保生产环境用户顺畅接入和体验 TRTC Web SDK 的全部功能，应使用 https 协议部署音视频应用。本地开发可以通过 http://localhost 或者 file:/// 协议进行访问。
2. 浏览器对 API 的支持
一些浏览器对 WebRTC 相关的 API 支持的不够完善，会导致音视频通话不能成功。
3. 浏览器支持的视频编码格式
目前主流设备大多都支持 H264 和 VP8 的编码格式，但是还是有一部分设备不支持 H264 ，因此如果使用 H264 进行音视频通话，就会导致无法正常使用应用。
4. 媒体设备相关信息
在用户未授权摄像头或麦克风访问权限前，是不允许从设备获取媒体流的。当只有用户给浏览器授权后，才可以正常采集到视频流。
5. 设备支持的视频最大分辨率
用户在调用 getUserMedia 并且指定视频的分辨率的时候，如果媒体设备不能满足的话，会获得摄像头最大的支持度。浏览器会试着满足这个请求参数，但是如果无法准确满足此请求中参数要求或者用户选择覆盖了请求中的参数时，有可能返回其它的分辨率。
因此在设置获取视频流的分辨率时，要尽量满足实际使用情况。
6. 输入输出设备的列表
如果有一个或多个 MediaStream 处于活动状态或者获得了持久授权，才可以在 mediaDevice 里面拿到所有的设备数目。当用户没有授权媒体设备的权限时，虽然此时获得的设备列表不为空，但是此时的列表中是没有 label 的。
7. 获取设备的音量
通话过程中，如果用户希望获取当前通话过程中的通话音量，我们需要使用 WebAudioAPI 来检测 AudioTrack 的音量，因此需要检测 WebAudioAPI 相关的支持度。
8. 媒体方法的支持
我们知道浏览器获取视频流的方法由很多，你可以通过 HTMLCanvasElement 或者 HTMLVideoElement ，使用他们的原生 CaptureStream 方法来获取 MediaStream 。开发者有时希望可以对音视频流进行一些高级处理，因此也需要提前检测好当前环境是否满足需求。
相关结果
项目发布后，首先是给到技术支持同学讲解使用，在下一次出现开发者提出使用 SDK 出现 XXX 不符合预期的行为，如果需要排查问题同学实际去复现场景时，可以让问题设备环境访问一下这个页面，拿到相关信息，可以生成一份图片报告来直接准确表示环境。减少沟通成本，快速在过往经验里发现解决办法。
1. 排查 case 的例子
- 帮助开发者确认视频流的分辨率为什么没有按照指定分辨率推流的问题
- XX功能是否支持
2. 使用情况
除了我们自己的访问，现在有许多开发者也把我们的检测页面部署到他们自己的服务上面。
3. 数据搜集
可以收集到最容易出现问题的设备以及问题。
5. 开发者反馈
后续
在后续的开发工作中，我也会将继续调研开发者的需求，努力在初期自动解决开发者在开发和使用中遇到的问题。我们将积极发现开发者的潜在需求，帮助他们更快地、更顺畅地使用我们的服务，更好地实现“开发者友好”。