当application需要播放音频或者视频文件的时候，通过构造一个java层的MediaPlayer对象来控制播放行为。实际的播放控制其实并不是在这个类中实现。android基于binder的通信机制和openmax的框架实现了自己的播放引擎。我将分几篇文章详细的记录整个播放过程的实现。
下面从最简单的客户端框架和通信机制开始。这篇文章关注Java层MediaPlayer和JNI的交互，以及JNI和native的MediaPlayer之间的交互。首先上图：
当我们创建一个java的MediaPlayer的时候，会在native层创建一个与之对应的MediaPlayer。同时在JNI层会创建一个JNIMediaPlayerListener，这个监视类用来通知Java层的MediaPlayer native层发生了啥事情。状态变化，错误通知等都是通过这个监视类传递给Java的MediaPlayer的。
实际上，native层的MediaPlayer也不是播放行为的最终控制者，最终的控制行为还需要media_server进程中的Client来执行。具体的细节会在以后的文章中指出。client是MediaPlayerservice的一个内部类，用于和application进程中的MediaPlayer进行交互。这两者之间是通过binder通信。
MediaPlayerService是一个注册service，native层的MediaPlayer通过查询获得一个IMediaPlayerService的proxy，然后通过这个代理获得一个Client类的代理IMediaPlayer。Client和MediaPlayer都是一个匿名binder。Client和MediaPlayer互相持有彼此的代理类，这样就可以实现双向通信。
图中蓝色部分表示自上而下的函数调用过程，即Java层的MediaPlayer通过JNI调用native的MediaPlayer的方法，然后native的MediaPlayer通过自己保存的IMediaPlayer代理类把这个方法调用请求传递给另一个进程中的Client，由Client真正去执行。然后Client通过蓝色红色部分将执行的结果或者错误消息等最终传递给Java的MediaPlayer对象。