导读：WebRTC 是一个非常优秀的项目， 可以支持 Web、iOS、Android、Mac、Windows、Linux 在内的所有平台的 API，保证了 API 在所有平台的一致性。然而 WebRTC 在移动端的表现跟 PC 相比，显得不是那么令人满意，尤其是在 Android 系统上，Android 系统的自身碎片化已经被诟病已久。每一次的 Android 系统升级，每个芯片厂商、手机厂商都会基于 Android 系统做一些定制化，造成了即使是同样的 Android 系统版本，同样的 Android 标准 API 调用，不同设备表现不一样。所以如果不针对不同机型做适配，很难达到统一的用户体验，功能的稳定性也很难保证。

RTC 场景中要想在 Android 设备上实现高可靠、稳定、低延时、设备通用， 音视频兼容性适配必不可少。Android 设备相关参数精细化配置、智能化配置，就是本文考虑的重心。

如何精细化配置

主流 SOC (System On Chip)方案都是基于 Linux/Android 系统开发，但是各家却各有所长。高通 SOC 主要应用在手机设备上，编解码性能和稳定性都比较强大，视频超编问题控制的比较好；MTK 和 MStar 并购后，除了手机产品，在机顶盒和大屏产品上应用很广，往往可以通过 MTK 自有参数，开启一些功能。此外不同的芯片版本计算性能高低不同，计算性能高低不同会影响音视频功能的开启，比如视频的前后处理。目前主流的芯片方案如下图：

基于上述不同的 SOC 平台， 各类设备厂商会定制化不同的 Android 智能设备， 而每类设备的功能特点也不一样。

比如：

• Android phone：手机的电池耗电量要求相对严格，设备需要满足 360 角度旋转的体验等；
• Android TV 大屏设备：
  • 有些使用的是外接 camera；
• 在声音采集场景中，人跟设备的距离往往比较远，对高音质音频数据采集有挑战；
• Android Watch： 设备屏幕比较小，CPU 性能相对较弱等；

手机设备是最常见的设备，也是用户使用率非常高的设备。大部分手机制造商都针对 Android 系统做了定制化，所以各家有各家的 ROM。手机厂商通常会对 Android 的 Framework、HAL 以及 Linux driver 做定制化修改，导致不同手机即使用同一款 SOC ，也会产生不同的表现。主流 Android 手机品牌及定制 ROM 如下图：

所以根据上述分析，设备兼容性问题这么多，对于以音视频为主要场景的产品，从音频和视频模块都需要做到精细化兼容性适配。主要可以参考的配置参数可以包括（目前没有全部都开启可配置）如下的功能模块：

• 音频：基本功能、音效、音频策略等
• 视频：基本功能、视频前后处理等

详细的参数如下图：

如何智能化配置

对于音视频的兼容性配置，需要满足参数的可更改性、时效性、灵活性、自动化以及可回退。目前的 Android 参数下发配置方案可以分为以下四种：

下面，我们就针对这四点详细展开聊聊，分析其优缺点。

兼容性代码 BuiltIn

兼容性方案是直接在代码逻辑中做处理。这种方案，只能覆盖一部分场景，比如针对不同 Android SDK 版本做兼容性适配以及已经在测试中非常明确的配置。

• 好处：直接写在 SDK 中，不存在从服务端下发的情况，不占用网络带宽，高效。
• 缺点：但是对于线上出现问题的特殊机型，往往设置不够灵活。 当线上的不同用户，出现较多问题的情况时，需要通过更改 SDK 来解决问题，这往往有种远水解不了近渴的感觉。

本地文件配置

本地文件配置的方式是：通过读取本地指定目录下的配置文件来参数生效，往往在 SDK 初始化时即进行这一步操作。

• 好处：不需要重新打包 SDK，可以直接将配置文件放到指定目录即可将参数生效，也不需要到服务器修改下发参数即可生效。比较适合本地调参的场景。
• 缺点：但是没法解决线上客户问题的远距离修改。

服务器参数下发

服务器下发参数设定，可以随时通过下发参数，控制设备相关功能参数。

• 好处：线上用户遇到兼容性问题，直接通过服务端下发参数修改，可以几分钟内解决用户问题。
• 缺点：通过服务器下发，需要占用服务器资源，如果下发参数文件过大，会影响 SDK 初始化时间。

自动化策略选择

参数的自动化策略选择，是通过对不同的系统版本、不同的 CPU 计算能力、芯片平台等因素进行综合考虑，对不同功能模块的参数组合，形成几套参数模版，比如低性能要求参数模版，或者质量优先参数模版。当不合适的参数设置导致问题时，有比较完善的回退机制可以回退到基本的参数配置，以保证基本功能可工作。

兼容性适配的规则

以上两章介绍了精细化配置的常见参数和智能化配置的方案， 那么不同设备型号、不同业务场景、不同系统版本，如何进行区分？

下面，我们详细介绍一下，制定兼容性适配规则的几个维度。

根据单个设备适配

手机制造商基于新的 Android 系统做定制化的时候，很难做到完全一致，这种差异性在音视频领域就更加。每个设备的唯一性，可以根据设备的硬件制造商、主板、设备版本、设备参数来标识唯一性。

根据设备 CPU 适配

根据 CPU 的计算能力进行适配，通常为了适配一些对于计算性能要求比较高的功能，比如视频前后处理等。选择这种方式适配后，只要是同样 CPU 型号的所有设备，都能实现适配。

根据系统版本适配

每一次 Android 系统更新， 会涉及到对应音视频 API 的相关功能改动。需要根据 Android 系统版本号，进行对应的适配。

根据不同应用业务适配

不同的业务，对于音视频的适配侧重点不同。 比如多人会议场景，对于音视频的实时性、弱网下的稳定性要求比较高，并且对于音频降噪，回音消除要求都比较高；云游戏场景下，对视频的分辨率、延迟度要求高；娱乐业务中的音乐播放，比如云音乐的一起听功能，对音质的要求比较高，并且对于音频设备路由策略上，有特殊要求，例如从蓝牙播放音乐，但是从手机 mic 采集音频数据；这些场景都要通过不同参数适配来达到要求。

根据 IOT 设备类型适配

Android 系统被应用在各个 IOT 设备中，从而产生非常多的适配场景。比如电视大屏，因为屏幕比较大，所以要求视频内容是高分辨率、高帧率的，从而对于采集和编解码的能力要求比较高；而且市场中存在一些可以 360 度旋转的电视，需要在显示角度上进行适配；在大屏的音质方面，由于人跟电视往往距离比较远，所以在声音采集和回音消除上的处理跟手机又不太一样。

兼容性适配常见的音视频问题

我们下面来聊聊常见的音视频兼容性适配的出现的问题，其产生的原因以及我们时是如何解决的。

音频兼容性常见问题

音频兼容性经常会出现音质、音量、音频策略的问题，下面我们选取其中几种，简单分析此类问题的解决方法。

• 遇到问题：音频延时过大或者延时不稳定

  • 解决方法：创建 Android 自采集的时候， AudioRecord 中设置的 Buffer 大小影响采集端延迟，从而影响AEC 算法精准度。

• 遇到问题：蓝牙 A2DP 模式下，从蓝牙播放，但是却无法从设备 mic 采集