當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對象。