如何通过调试LOG信息分析建立双向视频对讲连接的各个阶段所耗费的时间

使用P2P直播双向对讲SDK进行二次开发时，可以通过采集端和播放端的调试LOG信息中的时戳信息和各个阶段的关键LOG信息，分析对讲会话建立的各个阶段所耗费的时间。

以下这个LOG样例是一位开发者用户提供的，我们借此LOG信息进行分析。在这位开发者用户的项目中，两端都是 android 设备。一端通过极光推送发送对讲的呼叫请求给对端，对端收到呼叫请求后，显示界面给用户选择接受还是拒绝。当用户选择应答之后，又通过极光推送把应答发送回呼叫的发起端。然后，再通过P2P直播双向对讲SDK的API建立视频对讲会话。

一. 我们先看采集端（被呼叫端）的LOG信息: 

1.采集端的APP接收极光推送的呼叫请求后，开始初始化P2P SDK，登录到P2P服务器。

2.采集端登录P2P服务器成功，耗时500毫秒以下

3.采集端接收到播放端发送来的P2P连接请求。（这时离采集端登录成功已经过去了4.+ 秒了！这是因为用户点击了界面的“接受”按钮后，还要经过极光推送把应答返回给播放端的APP，播放端的APP才发起P2P连接。）

4.P2P连接建立成功，耗时200毫秒

5.视频通道建立成功，距P2P连接建立成功的时间点，过去了2.+秒

6.接收到播放端发送来的视频帧数据并开始解码，距视频通道建立成功的时间点，过去了400毫秒

7. 解码器需要缓存几帧视频，才能加密出图像，从开始解码到图像出现，大约耗时1秒

所以，从P2P初始化到显示出图像，大概10秒。其中，P2P登录成功后，等待用户接受和极光推送返回呼叫应答用了4.+秒，才有播放端连接请求过来。

8.采集端的LOG信息还显示了刚开始解码时，系统比较繁忙，界面运行不流畅。视频解码不及时导致丢失一些已经接收到视频帧数据。（因为这台android设备只有2核的CPU，性能稍弱）。

9.采集端的LOG信息还体现出，因为解码不及时丢弃视频帧之后，导致帧号不连续，不能继续解码，需要等到下一个关键帧收到时，才能重新开始解码。导致开始连接时视频画面有卡顿现象。

 

二. 以下是播放端的LOG信息情况：

1.播放端接收到采集端的呼叫“接受”应答后，初始化P2P SDK开始登录P2P服务器。

2. 播放端登录P2P服务器成功，耗时700毫秒。

3.音频通道建立成功，距登录P2P服务器成功，过去了4.+秒。（由于播放端没有开启P2P底层的LOG打印信息，没有看到P2P连接建立的LOG和时间点。）

4.视频通道建立成功，距登录P2P服务器成功，过去了4.+秒。

5. 接收到视频帧数据并开始解码，距视频通道建立成功，过去了1.+秒

以上，播放端从初始化P2P SDK到，视频解码开始，耗时7.+秒。

 

三.另外，采集端刚开始传输视频时，还有丢包重传发生，这里也会导致视频传的慢了一点。刚开始视频连接的时候，程序要做的事情有点多，都集中在一起了，系统确实比较忙。（采集端设备CPU性能较弱也是原因）