文档中心 API 中心 实时音视频 Web 异常处理与问题定位

异常处理与问题定位

最近更新时间:2019-05-09 15:07:48

实际的产品开发过程中,开发者不仅要实现业务需求,还需要有各种异常处理逻辑和与其对应的交互逻辑,我们甚至可以把两者工作量简单的以二八原则进行预估,这是所谓“用户体验”的重要组成部分,是极其重要和必要的。非常建议开发人员阅读和参考这一章节所说的内容。

不可信任原则

不可以完全信任我们总结的任何经验和说明。用户所处的网络环境、终端设备和操作系统的多样及复杂性决定了每一个环节都可能存在不可预测的异常,为此我们为每一个环节都准备了错误捕获和异常的通知。这里您需要特别注意几个关键的异常通知:

1.检测是否支持WebRTC

WebRTCAPI.fn.detectRTC (详见 API)

2.错误通知

onErrorNotify

3.流状态通知

onStreamNotify

异常分类及处理原则

1.网络问题

  • 如何检测用户的网络状况。
  • 产品层面的建议。
  • 什么样的情况可能无法连通。
  • 端口被封,我们需要用到什么端口,怎么确定是否畅通,网络不畅如何告知用户并解决这一问题。

2.客户端问题

  • WebRTCAPI.fn.detectRTC 已完成检测数据,有哪些数据可以告知用户?
    • H264 是必须支持的:
      • Chrome 版本必须在52+。
      • Windows XP 无法支持(因为 Chrome 版本只能到49)。
      • 一些 Android 手机的 Chrome 浏览器可能无法支持,因为不支持 H264 硬编解。
    • 确定是手机 QQ/微信,tbs 检测不通过:存在这种可能,因为存在 tbs 安装失败的情况,可以引导用户跳转至 x5debug.qq.com 安装 tbs 再使用。
  • 建连流程异常。
    • SDP 设置失败:浏览器环境是否完整支持 WebRTC。
    • ICE 连接失败: 当前网络环境是否有防火墙,是否有端口拦截的情况。
    • 摄像头获取失败:当前环境是否有摄像头设备,是否有使用授权的提示。
    • 摄像头黑屏:业务页面需要有足够显著的位置给用户提示,建议他进行检测和重装驱动,这种情况常见于 ThinkPad 的笔记本。
  • 视频通话过程中的异常。
    • 网路问题:首先是业务要进行重连,其次是多次重连以后要提示用户保证网络通畅。

3.异常上报

一个可靠的业务,对业务方而言不仅要有反馈渠道(feedback),还需要做好监控和数据上报。

当需要我们协助定位的时候,我们需要的信息有:

  • sdkappid。
  • 时间点(或者一个跨度较小的时间范围)。
  • userId(用户名)。
  • roomId(房间号)。
  • 异常的说明。

这将极大的提升我们定位问题原因的速度。