WebRTC自从google开源以来，其优秀的特性一直被广大实时音视频开发者借鉴和使用，像软件3A算法模块，带宽评估模块（BWE），平滑发送（paced sender），网络拥塞控制模块（gcc），视频自适应模块（帧率、分辨率、码率自适应），音频播放端的NetEQ等；而且WebRTC的整个代码的设计也充分考虑到了可扩展性，比如音视频codec可扩展（当内置的codec不能满足需求的时候，可以采用定制化的外部codec）；视频渲染模块的可扩展（可以定制所有的视频数据的渲染行为）；当然其他的优秀特性笔者不能一一列举，也是因为工作中没有涉及到。

部分厂商会抽取上面提到的一个或多个模块加到或者替换到他们自己的系统中，个人认为当前大部分的视频会议厂商或者VideoPaaS厂商在终端上面提供的接入SDK是基于完整的WebRTC库开发的，像windows，android，iOS，Mac，linux终端上可以使用WebRTC c/c++的库, 而浏览器上面直接使用webrtc js接口。

下面通过一张模块图来看一下 WebRTC 库在终端上的角色

终端提供的SDK往往做了如下工作：

1. 房间（通道）的管理
2. 用户的管理
3. 音视频设备的管理
4. 基于webtc lib提供的peerconnection接口进行二次开发

通过上面介绍，大家对WebRTC也有了一些程度的理解，既然webRTC c/c++库是核心，那么在Openharmony上面如果移植成功了它，就会为其他的移植工作比如音视频SDK的移植打下基础，移植工作主要包括如下这些：

1. WebRTC c/c++库所依赖的本身大概60个左右子库(依赖库)的移植

这些子库中有些有汇编代码，需要在CMakeLists中添加ENABLE_LANGUAGE(ASM)，打开汇编编译的支持

     2. 摄像头的管理和数据的采集

Openharmony上Camera的管理和采集参考eTS的api， 这里主要的工作是把在eTS层拿到的摄像头数据传到c/c++层，因为webRTC 库是c/c++实现的，这么做是为了配合WebRTC本身的的设计框架思路。

    3. 图像渲染模块

摄像头数据的本地预览和远端视频数据的渲染通过xComponent+OpenGLES实现，xComponnet的用法参考官方文档，OpenGLES编程网上也有参考。

    4. 音频采集、播放

参考笔者的另外一篇文章《Openharmony4.0音频框架的理解和在rtc应用上面的优化》

    5. 视频编解码器的封装

使用了Openharmony自带的OH_AVCodec相关api，这里需要注意的是由于OH_AVCodec不支持动态码率和比特率的调整，而WebRTC中又需要编码器的这个特性，因此这部分逻辑需要做相应的处理（有性能上的损失也会引起主观上的卡顿），编解码以external codec的形式注册到webrtc库中给其使用。

上面的移植工作完成之后，所有的功能都可以跑起来了，到此大家是不是以为移植工作完成？实际不是，我认为只完成了一部分的工作，因为通过在终端上实测 720p 30fps双向音视频通话并且audio3A全开的情况下发现，有些性能比较差的机器根本跑不动或者发热严重，这会很快导致CPU降频，进而导致音视频通话卡顿，主观效果差。所以移植工作还包含最重要的一步之性能的优化，通过分析CPU的消耗发现了几个需要优化的地方：

1. 摄像头的数据在送往视频编码器的时候CPU耗时较多

摄像头数据是大内存，在向编码器输送的一系列步骤中消耗了大量的CPU，大家可以通过下面的图来直观的理解如何优化掉内存拷贝：

上图只是简要说明一下思路，笔者会单独开一篇文章详细说明如何在Openharmony系统上面优化摄像头、编码器、摄像头本地预览三个方面的联动

        2. 音频采集和播放CPU耗时较多

参考笔者的另外一篇文章《Openharmony4.0音频框架的理解和在rtc应用上面的优化》

        3. 音频3A算法CPU耗时较多

   Openharmony4.0 一定要编译成64位的，音频3A算法库的CMakeLists中加上64位的核心算法汇编文件，实测发现64位的算法性能要远好于32位的

自此我们就完成了WebRTC c/c++库在Openharmony4.0上的移植，从实际的工作量来看完成功能的移植和性能的优化时间各占用了一半，而其中功能的移植需要大家对webrtc代码有足够的了解和熟悉（尤其需要对摄像头管理和数据的采集，编解码器，图形渲染，音频的采集和播放这几个模块代码的深入理解），以及对Openharmony系统提供的多媒体api熟练的使用，这部分工作完成了就可以满足大部分的终端设备音视频通话的使用了。

但是现在毕竟啥行业都卷，其中最重要的就是卷价格，这就导致终端的硬件性能不足，这就需要我需要掌握下面的这些知识点，这样才能在性能优化的时候游刃有余：对鸿蒙框架代码的掌握，尤其是audio框架和camera框架，因为有时候需要修改框架代码来做优化的；对Linux下比如V4L2，ALSA，DMA，外设之间的共享内存的理解和掌握，有时候去掉框架直接基于linux开发也是一种优化的方法；充分挖掘硬件能力，比如能不内存拷贝的就不内存拷贝，能用多媒体加速指令的就用多媒体加速指令，能使用硬件编解码的就使用硬件编解码（GPU编解码器）。正是由于对以上知识点的理解和在掌握，笔者才在项目中做了充分的优化：比如摄像头和编码器之间就没有任何内存的拷贝；当实在没有办法的情况下的大内存拷贝就重写了memcpy函数(CPU耗时是系统提供的memcpy的一半)，所有的视频编解码都使用GPU硬件，对Openharmony提供的audio/camera框架或修改或跳过。

最终通过实测：

中高性能的Openharmony4.0终端上面可以支持1080P 30fps,音频3A全开情况下的双向音视频通话，CPU总体剩余50%

低性能的Openharmony4.0终端上面可以支持720P 30fp，音频3A全开情况下的双向音视频通话，CPU总体剩余40%

在多款Openharmony4.0终端上面验证audio 3A的效果，除了double talk case下效果欠佳（应该是webrtc本身3A算法导致）外，单讲下的AEC，ANS，AGC效果都不错