以編碼策略為例，解碼的策略一樣。

1.編碼硬體加速全域性開關

       首先WebRTC的介面可以設定是否支援硬體加速，如果App設定為支援的話，將使用基於MediaCodec的編碼器工廠以及對應的硬體編碼器，否則將使用內建的軟體編碼器(編碼需要編譯OpenH264，解碼則需要編譯FFMpeg)。

2.硬體編碼黑白名單

      編碼器工廠初始化時會呼叫Java層的MediaCodec編碼器封裝類方法分別檢查VP8、VP9、H264等編碼是否支援硬體編碼，如果支援的話會加入支援的編碼列表中，在這裡App可以設定黑白名單。

3.回退(Fallback)軟解機制

• WebRTC建立某個編碼的硬體編碼器時從上述支援的編碼列表中搜索該編碼，如果找到則建立基於MediaCodec的硬體編解器；
• 實際上WebRTC會同時建立硬體、軟體編碼器，如果硬體編碼器建立失敗(例如加入了黑名單)，則會使用軟體編碼器；
• 如果硬體、軟體編碼器都建立成功，則將兩者封裝到一起，將軟體編碼器作為硬體編碼器的回退編碼器，在任何時候硬體編碼失敗時會自動切換到軟體編碼器。

實踐分析

      這樣的設計比較靈活，App可以設定全域性的硬體加速開關，也可以針對某種機型、某種編碼單獨設定硬體編解碼，同時底層還會在硬體編解碼失敗時回退到軟體編解碼。不過這樣的設計也是不得已而為之，因為Android平臺的機型和定製化太過靈活，谷歌只好把機型的適配工作甩給開發者。
      從目前的實踐來看，主流機型的的硬編硬解都沒有太大問題，個別機型的硬解有點問題，最穩妥的方案是硬編軟解，就是會犧牲一些CPU來解碼。