以編碼策略爲例，解碼的策略一樣。
1.編碼硬件加速全局開關
首先WebRTC的接口可以設置是否支持硬件加速，如果App設置爲支持的話，將使用基於MediaCodec的編碼器工廠以及對應的硬件編碼器，否則將使用內置的軟件編碼器(編碼需要編譯OpenH264，解碼則需要編譯FFMpeg)。
2.硬件編碼黑白名單
編碼器工廠初始化時會調用Java層的MediaCodec編碼器封裝類方法分別檢查VP8、VP9、H264等編碼是否支持硬件編碼，如果支持的話會加入支持的編碼列表中，在這裏App可以設置黑白名單。
3.回退(Fallback)軟解機制
- WebRTC創建某個編碼的硬件編碼器時從上述支持的編碼列表中搜索該編碼，如果找到則創建基於MediaCodec的硬件編解器；
- 實際上WebRTC會同時創建硬件、軟件編碼器，如果硬件編碼器創建失敗(例如加入了黑名單)，則會使用軟件編碼器；
- 如果硬件、軟件編碼器都創建成功，則將兩者封裝到一起，將軟件編碼器作爲硬件編碼器的回退編碼器，在任何時候硬件編碼失敗時會自動切換到軟件編碼器。
實踐分析
這樣的設計比較靈活，App可以設置全局的硬件加速開關，也可以針對某種機型、某種編碼單獨設置硬件編解碼，同時底層還會在硬件編解碼失敗時回退到軟件編解碼。不過這樣的設計也是不得已而爲之，因爲Android平臺的機型和定製化太過靈活，谷歌只好把機型的適配工作甩給開發者。
從目前的實踐來看，主流機型的的硬編硬解都沒有太大問題，個別機型的硬解有點問題，最穩妥的方案是硬編軟解，就是會犧牲一些CPU來解碼。