问题分析报告

问题产生的背景和表现

小程序的多人视频通话，经常出现黑屏现象，导致部分用户无法正常参与到视频通话中。经过初步的分析和定位，发现：当与会过程中有用户关闭了摄像头和音频权限后，参与会议的其他使用者会看到屏幕上该用户所占的视频画面位置被移除。当该用户重新开启了摄像头或者音频权限后，用户的画面却无法出现了。

问题追踪过程概述

综合现象分析，列出一下几点线索，对他们进行验证分析：

1. 小程序的DOM TREE中是否有视频通话的宫格节点存在。
2. 负责显示界面的数据是否能够及时更新。
3. 视频播放组件是否能够正常地渲染。

步骤一

小程序未正常显示画面，手下应该去考虑界面的节点是否存在。使用对开发者工具的探测功能，检查界面结构中的视频画面节点：

经检查发现，视频播放组件正常渲染。

步骤二

本次视频通话所用的组件为微信提供的官方组件live-player。该组件依赖streamList数组的内容在客户端展示。故先判断是否因为streamList未及时更新导致了live-player组件没有渲染。针对以上总结的问题，做出以下的实践分析：
模拟用户的开启和关闭音视频权限的动作，并且在与会者终端的控制台中设置打印streamList的推送日志，观察streamList栈中的记录：

结论：用户主动开启或者关闭视频和音频的动作会被主动推送到streamList中进行更新。

步骤三

从第一步中得出的验证结果后，排除streamList的问题，继续假设live-player的更新机制是否符合预期。查阅了相关文档，发现了在微信的live-player组件的更新机制是需要手动掉用stop和play方法之后才能及时更新的。

经过验证后发现，当live-play组件有被渲染后，需要在监听渲染界面手动对其更新才会显示最新的画面。

步骤四

继续查阅视频通话官方模块的代码，发现live-player在被(hasVideo & hasAudio)推流事件通知之后会重新初始化上下文，而这个初始化上下文之后是需要对组件的播放功能进行手动添加操作才能够重新播放画面的。故造成了虽然组件被通知更新，但是无法继续播放界面。

问题产生原因

经过对问题的逐步分析，发现小程序多人视频通话黑屏的主要原因为：推流事件让live-player组件重新初始化上下文导致了组件未主动更新画面。

问题分析手段

1. 合理地假设数据流的推送机制。streamList是会监听客户端的权限变化的而变化的列表。界面转态未更新首先应该去排除数据实时性的问题。
2. 组件的渲染机制问题。在得到数据准确的情况下，去验证组件的更新机制。虽然live-player是微信官方的组件，但是也可能存在于我们的预期表现不一致的结果。