最近看了一小段时间的视频通话相关内容,但是之后又直接不参与这个项目了。对于自己的记忆力我不抱任何自信,因此写文记录一些相关内容。
最开始参与这个项目是作为新人,参与视频通话App的开发过程,主要工作是设置界面和通话记录界面的开发过程,整个任务都比较简单,主要是对于界面的布局和控件的使用。主要用的控件也就是RecyclerView和ListView,然后就是比如SharedPreference之类的一些控件使用,难点在于一个是RecyclerView的复用问题,这个在前面有记录下来,另一个就是多人通话记录的头像的显示,通话记录这一块用的是本地GreenDao数据库记录方式,但是我并未参与GreenDao,可能后续需要学习。头像由于要显示1-4个,因此我选择使用逻辑方式实现,根据传入参数数量不同实现不同布局。这是刚开始对于视频通话的相关参与。
之后主要是对于一些功能的开发做一个测试性实现,比如比较荣耀智慧屏的视频通话延时,帧数等参数,比较CPU占用等。这些功能等各方面的比较和体验大概有四五次,之后就对于功能的细致性进行深入研究了。因为最开始是使用的腾讯云的实时音视频实现的整个视频通话流程,之后的第一个任务就是确认极光推送对于实时的视频通话的辅助作用,包括实时消息提示和端对端消息发送。推送其实在之前就接触过信鸽推送,但是几年过去了,发现信鸽也已经不是以前的信鸽了,仔细研究了下,其原理是基本相近的。目前的推送应该都是自身使用长链接的方式链接到手机本地,然后通过第三方如华为,小米等推送集成的方式实现实时性和后台常驻性质。而发送过程在极光推送和信鸽推送的文档中很明确的通过了控制台的流程,在实际的demo中测试可以正常使用。然后发送消息时需要使用一个其内部的接口,实际上是把消息发送到控制台,再从控制台到长链接的手机本地,这样的流程个人觉得好low啊,但是其不给开放控制台实际代码,所以也没办法了。然后他们的这个接口又是可以集成在android或者web上的,但是其官方说明不建议在Android本地集成,因为会暴露信息,安全性下降。但是,你从Android发到你的服务器,再从你的服务器到极光的控制台,再从极光的控制台到对方的手机,如果集成了比如华为的推送,你就是从极光的控制台到华为的控制台,再从华为控制台到对方手机。你还能再复杂点不。。。
然后是对于通话性能的保证。腾讯云的通话有直播模式和通话模式,其实原理是相同的,都是将视频流通过openGL处理后传输到手机,进行软解码,其官方文档介绍的是实时音视频延迟低,直播的话CPU占用率较低,使用更大带宽传输,但是实际根据测试来看貌似两种方式差别不大,帧率,延时,和CPU占用都没有明显变化。
再然后是对于通话悬浮窗的实现。简单来说能实现一边看电视剧一边视频通话,说起来感觉其实不难。麻烦的是在手机端能适配但是在电视端就不一定了。因此我试了试使用Android的service,在后台开启一个悬浮窗服务,在悬浮窗服务里面加上了腾讯云的视频TRTCVideoLayoutManager,直接把腾讯云的视频数据接入到我的悬浮窗里面,居然真的实现了。多人通话的话我尝试了开启多个service,也同样能两个甚至三个视频流放入到service里面正常运行并且同时播放电视(就是对网速要求有点恐怖,实在是太卡了)。然后有构思在于是否把不同的视频流放在同一个service里面实现,其实理论上应该可以做到的,因为腾讯云也是在一个屏幕里面实现了多人的通话流程。那么我的service里的悬浮窗应该有同样的能力。但是还没有来得及尝试。
再之后就是对于自定义音视频的采集和渲染了。因为要做这一块,我就专门去了解了下Android的openGL ES,也就是阉割版的openGL,毕竟之前只闻其名不见其用。当然,腾讯云的demo里面同样有这一块的示例,其实它的过程不是很复杂,也就是从手机中的一个视频文件里读取视频画面,并通过 接口, * 将这些视频画面送给 SDK 进行编码和发送。传入一个视频文件的文件路径,并启动一个 GLThread 线程,线程启动后开启回调创建了一个画面,每次画面的内容发生变更时,也就是有新的一帧视频渲染上来时,GLThread 就触发回调惊醒openGL的渲染过程。这么想的话可能我就甚至不需要过于了解openGL的内部机制。我的工作是拿到摄像头的视频画面然后进行自己的处理,处理之后把数据上传到视频流。那么我就只需要把这个摄像头画面处理成openGL格式的文件,然后再GLThread里面传入这个文件,输出的自然是我想要的东西了(其实最开始傻傻的想要把摄像头画面转成本地视频文件在读出来,后来想到这个过程不是有点太占用内存了吗,这才算了)。
之后由于业务问题,我这边就不参与视频通话项目的开发了,因此这边学习的内容就到这里,还剩两个大坑:openGL和GreenDao两个部分之后抽空再去学习。