以编码策略为例，解码的策略一样。
1.编码硬件加速全局开关
首先WebRTC的接口可以设置是否支持硬件加速，如果App设置为支持的话，将使用基于MediaCodec的编码器工厂以及对应的硬件编码器，否则将使用内置的软件编码器(编码需要编译OpenH264，解码则需要编译FFMpeg)。
2.硬件编码黑白名单
编码器工厂初始化时会调用Java层的MediaCodec编码器封装类方法分别检查VP8、VP9、H264等编码是否支持硬件编码，如果支持的话会加入支持的编码列表中，在这里App可以设置黑白名单。
3.回退(Fallback)软解机制
- WebRTC创建某个编码的硬件编码器时从上述支持的编码列表中搜索该编码，如果找到则创建基于MediaCodec的硬件编解器；
- 实际上WebRTC会同时创建硬件、软件编码器，如果硬件编码器创建失败(例如加入了黑名单)，则会使用软件编码器；
- 如果硬件、软件编码器都创建成功，则将两者封装到一起，将软件编码器作为硬件编码器的回退编码器，在任何时候硬件编码失败时会自动切换到软件编码器。
实践分析
这样的设计比较灵活，App可以设置全局的硬件加速开关，也可以针对某种机型、某种编码单独设置硬件编解码，同时底层还会在硬件编解码失败时回退到软件编解码。不过这样的设计也是不得已而为之，因为Android平台的机型和定制化太过灵活，谷歌只好把机型的适配工作甩给开发者。
从目前的实践来看，主流机型的的硬编硬解都没有太大问题，个别机型的硬解有点问题，最稳妥的方案是硬编软解，就是会牺牲一些CPU来解码。