把这个搞明白，算是顿悟的一个真实例子。怎么也搞不懂的架构，突然就想明白了。不过这其实是一个思维的过程。
当然如果你想明白这些东西，至少要非常清楚一个概念：接口。
我只是一个半路出家的开发者，我真正明白什么接口时，我已经写了一年多代码了。书面的解释实在拗口，我记不住。
我的理解就是：接口，在C语言里面，就是函数接口，在C++里面就是纯虚函数，在java里面就是interface。用接口，而不是实现来编程一个最大的好处就是：隔离变化。其实这些东西，都是我在李先静老师《系统程序员成长计划》里面领悟到的。
好吧说完了接口的体会，少说废话，步入正题。
我们要思考一个问题，对于一个播放器，解决的主要问题有哪些？当然是播放音视频。如何播放？播放的过程有哪几步？
想到这一点，剩下的东西，就很简单了。
播放器的四大基本组件：access/demux/decode/render。（这些知识，我已经在之前的文章写过了）
下面来看android awesomeplayer是如何抽象这四大组件的。时刻记住，我们是面向接口编程，一定要找准接口。
1.access
有些问题我们之前说过，获取stream的方式是多样的，本地文件，rtsp，http都有可能。我们要足够抽象才行。其实我不知道如何抽象一个好的接口，这也不是这个文章的要点，我们的要点是：印证自己的想法，理解别人的设计理念。
android抽象了一个叫DataSource的接口类，来隔离获stream方式的变化。
virtual status_t initCheck() const = 0;
virtual ssize_t readAt(off64_t offset, void *data, size_t size) = 0;
这个类，规定了两个接口。我们剩下的任务就是找出谁继承了这个类，就知道android能支持的stream种类了。
class FileSource : public DataSource
struct HTTPBase : public DataSource
struct ChromiumHTTPDataSource : public HTTPBase
struct NuCachedSource2 : public DataSource
这里http方式的流，没有直接继承datasource，而是又加了一层包装，另外这个http协议的实现是直接使用的webkit的库。
最后一种stream，我也没搞明白是什么。。。。。
这三种流，分别实现了上述的两个接口，完全了第一步抽象。
2.demux
同理，不同的container，也是需要隔离变化的，avi,mkv,mp4,需要不同的实现。我们不多说其他的，找出基类，看看谁继承了他。
原来他叫MediaExtractor ，再来看看他抽象了什么接口：
virtual size_t countTracks() = 0;
virtual sp<MediaSource> getTrack(size_t index) = 0;
virtual sp<MetaData> getTrackMetaData(size_t index, uint32_t flags = 0) = 0;
ok，原来是这三个接口需要实现。
再来看看谁实现了他。
class AacAdtsExtractor : public MediaExtractor
class AACExtractor : public MediaExtractor
struct ARTSPController : public MediaExtractor
struct AVIExtractor : public MediaExtractor
class DRMExtractor : public MediaExtractor
class FLACExtractor : public MediaExtractor
struct MatroskaExtractor : public MediaExtractor
class MP3Extractor : public MediaExtractor
struct MPEG2TSExtractor : public MediaExtractor
class MPEG4Extractor : public MediaExtractor
struct OggExtractor : public MediaExtractor
class WAVExtractor : public MediaExtractor
这就是android默认支持的demux文件各类了，如果我们要支持新的文件格式，比如flv，就可以新加个类
比如：class FlvExtractor:pulic MediaExtractor这样的，然后实现上述三个接口，就可以支持flv文件格式了。
3.encodec/decodec
这块代码主要是omx在实现，比较复杂，但还是符合我们上述所说的接口抽象，隔离变化的原则的
主要的抽象类是：
MediaSource
virtual status_t start(MetaData *params = NULL) = 0;
virtual status_t stop() = 0;
virtual sp<MetaData> getFormat() = 0;
virtual status_t read(MediaBuffer **buffer, const ReadOptions *options = NULL) = 0;
MediaBufferObserver
virtual void signalBufferReturned(MediaBuffer *buffer) = 0;
这里使用了观察者模式，我不知道为什么要这么设计才好，理解不了这样的设计，但是隐隐知道是有道理的。
实现这两个类的是：
struct OMXCodec : public MediaSource,public MediaBufferObserver
当然是OMXCodec，这个类，隔离了所有的codec的种类，软解，硬解，h264，mpeg4，mp3。。。。。
这是awesomeplayer中最复杂的类，隔离了最复杂的东西，屏避了最大的变化。
从代码分析，原生代码里面omxcodec只支持软解，但是对实际的soc来说，都加入了硬解支持。
下篇文章会分析，omx的组件如何构成以及如何在omxcodec里面加入硬解支持。
4.render。
对于这一步来说，android似乎是最轻松的，因为不用考虑太多变化的问题。因为对android的render来说，实际上没有任何变化。音频直接给audioflinger，图像直接给surfaceflinger。
这里只需要简单包装一下即可。
因为我只对视频有兴趣，我们就看看视频是如何抽象的。这一步甚至已经简单到不用单独起一个文件的地步了。其实整个stragefright目录，除掉上面写的那些类（每个类基本都是一个文件）和一些基本工具类（比如handler,timeevent,string。。类）,就没有太多额外的东西了。整体架构比较简洁，比起vlc/directshow这种重型的多媒体框架/应用来说，相当简单。
这个类，只有一个接口。两种实现
struct AwesomeRenderer
virtual void render(MediaBuffer *buffer) = 0;
struct AwesomeLocalRenderer : public AwesomeRenderer
struct AwesomeNativeWindowRenderer : public AwesomeRenderer
local/native不同codec出来的数据
这里有几行注释，
// Hardware decoders avoid the CPU color conversion by decoding
// directly to ANativeBuffers, so we must use a renderer that
// just pushes those buffers to the ANativeWindow.
可以解释这个问题。
localrenderer，额外做了colorspace转化的工作，当然一般都是yv12/nv12(i420p)到rgb565这种，大众的，呵呵，如果你要支持特殊硬件，就要自己手写了。
好了。主要内容就是这些，理一下框架
datasource-->MediaExtractor-->MediaSource--->AwesomeRenderer
四大步，四种抽象接口。与其他的多媒体框架相比，抽象方法是一样的，只是接口略有区别。over..