音頻視頻播放在現(xiàn)在的應(yīng)用里面很常見(jiàn)思恐，傳統(tǒng)應(yīng)用發(fā)展到一定階段多少會(huì)引入音視頻資源唁桩，特別是現(xiàn)在短視頻被看作下一個(gè)增長(zhǎng)爆發(fā)點(diǎn)巴碗，和之相關(guān)的創(chuàng)業(yè)層出不窮称簿，作為開(kāi)發(fā)者如何進(jìn)行音視頻技術(shù)選型非常關(guān)鍵
MediaPlayer和VideoView給我們提供了非常方便的播放音視頻的能力扣癣，幾乎不需要要寫(xiě)幾行代碼就可以完成。我們也可以使用MediaPlayer結(jié)合SurfaceView或者TextureView來(lái)實(shí)現(xiàn)視頻播放憨降，本質(zhì)和VideoView是一樣的父虑，不過(guò)有更多的靈活性。
正因?yàn)榉庋b性太強(qiáng)授药，意味著定制化變?nèi)跏亢俊ediaPlayer提供的setDataSource方法支持http,file,content等協(xié)議，但仍然無(wú)法應(yīng)對(duì)復(fù)雜的需求悔叽。所以更靈活的AudioTrack的出現(xiàn)莱衩，可以讓我們直接傳送解碼后的byte[]給他，帶來(lái)的問(wèn)題就是自己要做解碼娇澎。解碼不是件簡(jiǎn)單的事情笨蚁，往往我們利用MediaCodec（Android4.1增加）或者外部解碼庫(kù)（比如ffmpeg）來(lái)實(shí)現(xiàn)。自己來(lái)實(shí)現(xiàn)解碼要特別注意不要丟失了硬件加速，音頻軟解碼還好括细，視頻解碼軟解碼對(duì)CPU壓力會(huì)大很多伪很。
在做音視頻業(yè)務(wù)的時(shí)候，經(jīng)常會(huì)遇到這樣幾個(gè)問(wèn)題需要設(shè)置代理奋单，或者邊播邊緩存锉试，緩存加密，失敗重試览濒，網(wǎng)絡(luò)優(yōu)化等等
因?yàn)槲覀儫o(wú)法干涉MediaPlayer的網(wǎng)絡(luò)請(qǐng)求部分呆盖，所以一般會(huì)將原始的播放地址http://xxx.com/playurl轉(zhuǎn)換成本機(jī)代理地址http://127.0.0.1:port?url=htt...，這樣MediaPlayer就會(huì)來(lái)請(qǐng)求本機(jī)port端口上面起的一個(gè)代理服務(wù)匾七，在這個(gè)代理端可以做很多優(yōu)化邏輯絮短，比如給真正發(fā)往服務(wù)端的請(qǐng)求加上代理；將請(qǐng)求到的數(shù)據(jù)寫(xiě)入磁盤(pán)緩存昨忆，這個(gè)代理端可以根據(jù)磁盤(pán)緩存來(lái)按需請(qǐng)求服務(wù)端（使用http的Range參數(shù)）；還有一些失敗重試等網(wǎng)絡(luò)優(yōu)化手段杉允。這個(gè)代理層還有個(gè)特別的意義甚至可以接管webview里面的audio和video標(biāo)簽請(qǐng)求邑贴。
這種實(shí)現(xiàn)方式在實(shí)際運(yùn)行中偶爾會(huì)出現(xiàn)本機(jī)代理無(wú)法啟動(dòng)的情況，原因是Socket無(wú)法bind到指定端口叔磷，往往我們會(huì)在bind的時(shí)候指定讓系統(tǒng)來(lái)分配一個(gè)可用端口拢驾，所以這種失敗情況很有可能是root手機(jī)或者一些安全管理軟件禁用了權(quán)限。
特別再說(shuō)下邊播邊緩存的實(shí)現(xiàn)改基，緩存文件允許空洞繁疤，每個(gè)緩存文件配備另外一個(gè)內(nèi)容索引文件，MediaPlayer本身會(huì)根據(jù)解碼情況發(fā)出多個(gè)帶Range的請(qǐng)求秕狰，根據(jù)內(nèi)容索引文件來(lái)確定當(dāng)前請(qǐng)求從文件哪個(gè)位置讀稠腊，接下去多少字節(jié)從文件讀，多少字節(jié)從網(wǎng)絡(luò)讀鸣哀，網(wǎng)絡(luò)讀的部分同時(shí)寫(xiě)回文件以保證下次請(qǐng)求可以復(fù)用架忌，這樣就實(shí)現(xiàn)了一個(gè)邊播邊緩存的邏輯，甚至我們還可以給本地緩存文件進(jìn)行加密我衬。同時(shí)這個(gè)緩存文件的加載百分比可以用來(lái)做UI界面上面的緩沖進(jìn)度叹放，監(jiān)控下載速度進(jìn)行網(wǎng)絡(luò)請(qǐng)求優(yōu)化。
2.MediaPlayer的Looper挠羔。新手往往可能不關(guān)心MediaPlayer的實(shí)現(xiàn)井仰，打開(kāi)它的構(gòu)造器前面幾行代碼我們就會(huì)看到他默認(rèn)使用的是當(dāng)前線程的Looper，如果當(dāng)前線程不是個(gè)Looper線程則使用MainLooper破加。這一點(diǎn)比較重要俱恶，因?yàn)槲覀冎兰词筂ediaPlayer運(yùn)行在Service里面，實(shí)際上還在跑在主線程，這樣的結(jié)果導(dǎo)致后續(xù)所有的MediaPlayer回調(diào)操作都跑在主線程速那，這可能是隱藏的一個(gè)定時(shí)炸彈俐银。
更優(yōu)雅的設(shè)計(jì)我們建議將MediaPlayer的回調(diào)和主動(dòng)操作（stop，reset等操作）都放入work線程端仰，操作的串行化是種最簡(jiǎn)單的設(shè)計(jì)捶惜，也是最有效的設(shè)計(jì)。大概的代碼形式是這樣的：
MediaPlayer在PlayHandlerThread里面初始化荔烧，就保證了他里面使用的Looper也是這個(gè)PlayHandlerThread的吱七，這樣回調(diào)就都會(huì)在這個(gè)線程觸發(fā)，同時(shí)我們也在這個(gè)線程里面做setDataSource等主動(dòng)操作鹤竭。
3.視頻播放本質(zhì)上也是用MediaPlayer實(shí)現(xiàn)的踊餐，所以讀取數(shù)據(jù)上面沒(méi)有特別差異。現(xiàn)在比較熱的小視頻需要顯示在列表頁(yè)面支持滾動(dòng)播放一個(gè)視頻臀稚，點(diǎn)擊在新頁(yè)面繼續(xù)觀看吝岭，一般采用MediaPlayer+TextureView來(lái)實(shí)現(xiàn)，MediaPlayer可以采用全局定義唯一一個(gè)吧寺，只是不同時(shí)刻把內(nèi)容綁定顯示在不同的TextureView上而已窜管。
4.MediaPlayer最大的問(wèn)題還是在于其兼容性。從我們的經(jīng)驗(yàn)來(lái)看可能會(huì)有這些問(wèn)題：音頻格式支持不全（ape稚机，wma等原生系統(tǒng)不支持）幕帆，未緩沖完不開(kāi)始播放，播放過(guò)程中突然沒(méi)有聲音赖条，播放存在跳幀失乾，mediaserver
died；視頻播放只有聲音沒(méi)有畫(huà)面纬乍，視頻格式兼容性差無(wú)法播放等碱茁。這些問(wèn)題在系統(tǒng)基礎(chǔ)上基本無(wú)法解決。
最頭疼的問(wèn)題是MediaPlayer返回的errorcode很多都是廠家擴(kuò)展出來(lái)的蕾额，文檔上面提供的幾個(gè)值基本也是表意不清到底什么問(wèn)題早芭。這給排查問(wèn)題帶來(lái)很大麻煩。最最頭疼的是MediaPlayer的EventHandler里面處理異常直接導(dǎo)致程序崩潰诅蝶，比如像這樣：
11-0413:43:08.966: E/AndroidRuntime(26482): java.lang.RuntimeException: failurecode: -3211-0413:43:08.966: E/AndroidRuntime(26482):? ? at android.media.MediaPlayer.invoke(MediaPlayer.java:664)11-0413:43:08.966: E/AndroidRuntime(26482):? ? at android.media.MediaPlayer.getInbandTrackInfo(MediaPlayer.java:1692)11-0413:43:08.966: E/AndroidRuntime(26482):? ? at android.media.MediaPlayer.scanInternalSubtitleTracks(MediaPlayer.java:1851)11-0413:43:08.966: E/AndroidRuntime(26482):? ? at android.media.MediaPlayer.access$600(MediaPlayer.java:529)11-0413:43:08.966: E/AndroidRuntime(26482):? ? at android.media.MediaPlayer$EventHandler.handleMessage(MediaPlayer.java:2198)11-0413:43:08.966: E/AndroidRuntime(26482):? ? at android.os.Handler.dispatchMessage(Handler.java:102)11-0413:43:08.966: E/AndroidRuntime(26482):? ? at android.os.Looper.loop(Looper.java:137)11-0413:43:08.966: E/AndroidRuntime(26482):? ? at android.app.ActivityThread.main(ActivityThread.java:4998)11-0413:43:08.966: E/AndroidRuntime(26482):? ? at java.lang.reflect.Method.invokeNative(Native Method)11-0413:43:08.966: E/AndroidRuntime(26482):? ? at java.lang.reflect.Method.invoke(Method.java:515)11-0413:43:08.966: E/AndroidRuntime(26482):? ? at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:777)11-0413:43:08.966: E/AndroidRuntime(26482):? ? at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:593)11-0413:43:08.966: E/AndroidRuntime(26482):? ? at dalvik.system.NativeStart.main(Native Method)
除了反射替換MediaPlayer里面的EventHandler來(lái)抓住異常退个，其他沒(méi)啥特別好的辦法。
遇到這么多問(wèn)題開(kāi)發(fā)者只能另投他路调炬。市面上采用自解碼的方案也很多语盈，比較主流的是使用MediaCodec和ffmpeg，ffmpeg更是因?yàn)镸ediaCodec版本限制原因缰泡，加上本來(lái)就聞名遐邇刀荒，被很多開(kāi)發(fā)者青睞代嗤。主流的音視頻播放器大部分都是在這個(gè)上面進(jìn)行改造的。
ExoPlayer:https://github.com/google/Exo...缠借，作為google在MediaCodec的封裝也是不錯(cuò)的推薦干毅，相比自己要去抽取ffmpeg代碼進(jìn)行android適配編譯來(lái)得容易得多
ffmepg：當(dāng)然也有一些現(xiàn)成的實(shí)現(xiàn)：https://github.com/search?o=d...，最出名的當(dāng)是ijkplayer泼返，嗶哩嗶哩出品硝逢，跨平臺(tái)還有彈幕。做視頻彈幕真是開(kāi)箱即用绅喉。ffmpeg功能強(qiáng)大渠鸽，唯一的缺點(diǎn)就是軟解碼，這也是他兼容性好的原因柴罐，我們知道硬解碼依賴各個(gè)廠家硬件實(shí)現(xiàn)兼容性自然就下降了徽缚。
在使用自解碼的時(shí)候，我們建議將自己的MediaPlayer封裝成Android高版本上面添加的接口一樣：
/** * Sets the data source (MediaDataSource) to use. * *@paramdataSource the MediaDataSource for the media you want to play *@throwsIllegalStateException if it is called in an invalid state *@throwsIllegalArgumentException if dataSource is not a valid MediaDataSource */publicvoidsetDataSource(MediaDataSource dataSource)throwsIllegalArgumentException, IllegalStateException{? ? _setDataSource(dataSource);}
這樣做的好處是所有實(shí)現(xiàn)都對(duì)MediaPlayer透明革屠，我們只需要定義好MediaDataSource接口凿试，后面只需要專注于實(shí)現(xiàn)就可以了，比如HttpDataSource,FileDataSource,MemoryDataSource等似芝。
或許自解碼會(huì)引入更多的不確定性红省，但是這一步遲早都要邁出去。推薦小型app或者需求不強(qiáng)的產(chǎn)品使用系統(tǒng)解碼国觉，在我上面提到的一些解決思路上進(jìn)行改進(jìn)應(yīng)該能滿足絕大部分場(chǎng)景。而那些音視頻作為主業(yè)務(wù)的產(chǎn)品則不得不面對(duì)自解碼來(lái)提高兼容性虾啦。
于是我們又在造輪子了麻诀；）
更多文章請(qǐng)關(guān)注微信公眾號(hào)：anzhuozhimei
