屏幕录制（二）——帧率控制屏幕录制（二）——帧率控制

我的上一篇文章《屏幕录制一——MediaProjection简介》讲述了如何使用API MediaProjection录制手机屏幕（截屏（含状态栏）也是这样做的），先让我们来回顾一下：
获得用户截屏权限后，先创建MediaProjection对象：

MediaProjection mMediaProjection = ((MediaProjectionManager) getSystemService(Context.MEDIA_PROJECTION_SERVICE)) .getMediaProjection(int resultCode, intent resultData);

由创建好的MediaProjection对象来创建VirtualDisplay对象：

mMediaProjection.createVirtualDisplay("MyDisplay", mWidth, mHeight, mScreenDensity, DisplayManager.VIRTUAL_DISPLAY_FLAG_AUTO_MIRROR, mSurface, null, null);

【屏幕录制（二）——帧率控制】这个方法中需要传入一个Surface对象作为参数，帧数据由MediaProjection截取，送入这个mSurface，就像上篇文章中所说的一样，这个Surface对象一般由mMediaCodec对象创建然后向VirtualDisplay对象注册：

mInputSurface = mVideoEncoder.createInputSurface();

其中mVideoEncoder是MediaCodec的一个实例。
那么，整个帧数据流可以表示为：

MediaProjection -> VirtualDisplay -> MediaCodec

一直到这里都没有任何问题，但是，我们这种处理是针对一种情况的：录制本地视频。将手机屏幕录制为本地视频，在大多数情况下都没什么卵用，我们遇到最多的情况是这样的：录制视频，然后分享；或者是这样的：直播！
我们手机端一帧一帧的截取屏幕，远程一帧一帧的收到数据，理想的情况下这很好，但是，当网络差的时候呢？这个时候我们就不得不对所录制的视频进行处理，可以调整码流，降低每一帧画面的质量，以此来降低传输负载压力，也可以是降低帧率，同样可以降低负载，还不会影响每一帧的清晰度。
在MediaCodec对象进行configure时，需要事先预备MediFormat对象，而MediaFormat对象刚好提供了提供了API设置码流，因此，本文不再对码流设置进行赘述（MediaFormat中对Frame Rate的设置并不是对手机屏幕截取频率的设置，它指的是MediaCodec对象输出的视频的帧率）。
对于VirtualDisplay来说，帧数据的生产者是MediaProjection对象，消费者是向它注册的MediaCodec的Surface对象，这样的话整个数据流我们是没法对每一帧数据作控制的，除非是经MediaCodec编解码后，但这样会对性能有较大的浪费，所以没我们需要换过一种思路：自创建Surface对象，而不是直接使用MediaCodec所创建的。
VirtualDisplay只要求向它注册的是一个Surface对象，所以我们自己创建Surface是可行的，创建Surface对象的代码如下：

mSurfaceTexture = new SurfaceTexture(mTextureId); mSurface = new Surface(mSurfaceTexture); mSurfaceTexture.setOnFrameAvailableListener(mListener);

OnFrameAvailableListener在每当有数据将要更新时被回调，因此，可以在其中利用Handler发送消息，或者使用obj.notifyAll()实现线程间通信。
那么，现在的帧数据流就变为如下情况：

MediaCodec -> Surface(created by myself) -> Surface(Created by MediaCodec)

现在所有的问题就集中在了一点：怎么在两个Surface对象之间实现帧数据的转移，这里给出一个思路：当有数据将要更新时，系统调用onFrameAvailable()，我们手动调用updateTexImage()向Surface(SuraceTexture)更新数据，通过GLES向Surface(MediaCodec)更新数据，在GLES处理过程中即可实现对某一帧数据的抛弃保留等。
通过对竞品反编译分析，他们的项目中还是直接向VirtualDisplay注册MediaCodec创建的Surface，在网络环境较差的情况下，网络延迟明显比我们的这种实现方法要长，（800ms对比150ms），所以还不能直接上代码，很抱歉！我也会争取尽早将源码放出，大家一起讨论研究。