我的上一篇文章《屏幕錄制一——MediaProjection簡(jiǎn)介》講述了如何使用API MediaProjection錄制手機(jī)屏幕（截屏（含狀態(tài)欄）也是這樣做的）狮惜，先讓我們來回顧一下：
獲得用戶截屏權(quán)限后簸州，先創(chuàng)建MediaProjection對(duì)象：
MediaProjection mMediaProjection = ((MediaProjectionManager) getSystemService(Context.MEDIA_PROJECTION_SERVICE))
.getMediaProjection(int resultCode, intent resultData);
由創(chuàng)建好的MediaProjection對(duì)象來創(chuàng)建VirtualDisplay對(duì)象：
mMediaProjection.createVirtualDisplay("MyDisplay", mWidth, mHeight, mScreenDensity,
DisplayManager.VIRTUAL_DISPLAY_FLAG_AUTO_MIRROR, mSurface, null, null);
這個(gè)方法中需要傳入一個(gè)Surface對(duì)象作為參數(shù)岂嗓，幀數(shù)據(jù)由MediaProjection截取贬堵，送入這個(gè)mSurface，就像上篇文章中所說的一樣践樱，這個(gè)Surface對(duì)象一般由mMediaCodec對(duì)象創(chuàng)建然后向VirtualDisplay對(duì)象注冊(cè)：
mInputSurface = mVideoEncoder.createInputSurface();
其中mVideoEncoder是MediaCodec的一個(gè)實(shí)例哮肚。
那么，整個(gè)幀數(shù)據(jù)流可以表示為：
MediaProjection -> VirtualDisplay -> MediaCodec
一直到這里都沒有任何問題很钓，但是香府，我們這種處理是針對(duì)一種情況的：錄制本地視頻。將手機(jī)屏幕錄制為本地視頻码倦，在大多數(shù)情況下都沒什么卵用企孩，我們遇到最多的情況是這樣的：錄制視頻，然后分享袁稽；或者是這樣的：直播勿璃！
我們手機(jī)端一幀一幀的截取屏幕，遠(yuǎn)程一幀一幀的收到數(shù)據(jù)运提，理想的情況下這很好，但是闻葵，當(dāng)網(wǎng)絡(luò)差的時(shí)候呢民泵？這個(gè)時(shí)候我們就不得不對(duì)所錄制的視頻進(jìn)行處理，可以調(diào)整碼流槽畔，降低每一幀畫面的質(zhì)量栈妆，以此來降低傳輸負(fù)載壓力，也可以是降低幀率厢钧，同樣可以降低負(fù)載鳞尔，還不會(huì)影響每一幀的清晰度。
在MediaCodec對(duì)象進(jìn)行configure時(shí)早直，需要事先預(yù)備MediFormat對(duì)象寥假，而MediaFormat對(duì)象剛好提供了提供了API設(shè)置碼流，因此霞扬，本文不再對(duì)碼流設(shè)置進(jìn)行贅述（MediaFormat中對(duì)Frame Rate的設(shè)置并不是對(duì)手機(jī)屏幕截取頻率的設(shè)置糕韧，它指的是MediaCodec對(duì)象輸出的視頻的幀率）枫振。
對(duì)于VirtualDisplay來說，幀數(shù)據(jù)的生產(chǎn)者是MediaProjection對(duì)象萤彩，消費(fèi)者是向它注冊(cè)的MediaCodec的Surface對(duì)象粪滤，這樣的話整個(gè)數(shù)據(jù)流我們是沒法對(duì)每一幀數(shù)據(jù)作控制的，除非是經(jīng)MediaCodec編解碼后雀扶，但這樣會(huì)對(duì)性能有較大的浪費(fèi)杖小，所以沒我們需要換過一種思路：自創(chuàng)建Surface對(duì)象，而不是直接使用MediaCodec所創(chuàng)建的愚墓。
VirtualDisplay只要求向它注冊(cè)的是一個(gè)Surface對(duì)象予权，所以我們自己創(chuàng)建Surface是可行的，創(chuàng)建Surface對(duì)象的代碼如下：
mSurfaceTexture = new SurfaceTexture(mTextureId);
mSurface = new Surface(mSurfaceTexture);
mSurfaceTexture.setOnFrameAvailableListener(mListener);
OnFrameAvailableListener在每當(dāng)有數(shù)據(jù)將要更新時(shí)被回調(diào)转绷，因此伟件，可以在其中利用Handler發(fā)送消息，或者使用obj.notifyAll()實(shí)現(xiàn)線程間通信议经。
那么斧账，現(xiàn)在的幀數(shù)據(jù)流就變?yōu)槿缦虑闆r：
MediaCodec -> Surface(created by myself) -> Surface(Created by MediaCodec)
現(xiàn)在所有的問題就集中在了一點(diǎn)：怎么在兩個(gè)Surface對(duì)象之間實(shí)現(xiàn)幀數(shù)據(jù)的轉(zhuǎn)移，這里給出一個(gè)思路：當(dāng)有數(shù)據(jù)將要更新時(shí)煞肾，系統(tǒng)調(diào)用onFrameAvailable()咧织，我們手動(dòng)調(diào)用updateTexImage()向Surface(SuraceTexture)更新數(shù)據(jù)，通過GLES向Surface(MediaCodec)更新數(shù)據(jù)籍救，在GLES處理過程中即可實(shí)現(xiàn)對(duì)某一幀數(shù)據(jù)的拋棄保留等习绢。
通過對(duì)競(jìng)品反編譯分析，他們的項(xiàng)目中還是直接向VirtualDisplay注冊(cè)MediaCodec創(chuàng)建的Surface蝙昙，在網(wǎng)絡(luò)環(huán)境較差的情況下闪萄，網(wǎng)絡(luò)延遲明顯比我們的這種實(shí)現(xiàn)方法要長(zhǎng)，（800ms對(duì)比150ms）奇颠，所以還不能直接上代碼败去，很抱歉！我也會(huì)爭(zhēng)取盡早將源碼放出烈拒，大家一起討論研究圆裕。
