AIDL是Binder的延伸。一定要先看懂我前面介紹的Binder，再來看AIDL。要按順序閱讀。 Android系統中很多系統服務都是aidl，比如說剪切板。舉這個例子，是為了讓App開發人員知道AIDL無處不在，和我們距離非常近。 AIDL中需要知道下面幾個類： * IBinder * IInterface * Binder * Proxy * Stub 當我們自定義一個aidl文件時（比如MyAidl.aidl，里面有一個sum方法），Android Studio會幫我們生成一個類文件MyAidl.java，如下圖所示：  MyAidl.java這個生成文件中，包括MyAidl接口，以及Stub和Proxy兩個實現了MyAidl接口的類，其中Stub是定義在MyAidl接口中的，而Proxy則定義在Stub類中。 我曾經很不理解，為什么不是生成3個文件，一個接口，兩個類，清晰明了。都放在一個文件中，這是導致很多人看不懂AIDL的一個門檻。其實Android這么設計是有道理的。當有多個AIDL類的時候，Stub和Proxy類就會重名，把它們放在各自的AIDL接口中，就必須MyAidl.Stub這樣去使用，就區分開了。 對照這張圖，我們繼續來分析，Stub的sum方法是怎么調用到Proxy的sum方法？然后又調用另一個進程的sum方法的？ 起決定意義的是Stub的asInterface方法和onTransact方法。其實這個圖沒有畫全，把完整的Binder Server也畫上，就應該是這樣：  1）先從Client看起，對于AIDL的使用者，我們這么寫程序： MyAidl.Stub.asInterface(某IBinder對象).sum(1, 2); //最好在執行sum方法前判空。 asInterface方法的作用是判斷參數——也就是IBinder對象，和自己是否在同一個進程： * 是，則直接轉換、直接使用，接下來就跟Binder跨進程通信無關啦； * 否，則把這個IBinder參數包裝成一個Proxy對象，這時調用Stub的sum方法，間接調用Proxy的sum方法。 ~~~ return new MyAidl.Stub.Proxy(obj); ~~~ 2）Proxy在自己的sum方法中，會使用Parcelable來準備數據，把函數名稱、函數參數都寫入_data，讓_reply接收函數返回值。最后使用IBinder的transact方法，把數據就傳給Binder的Server端了。 ~~~ mRemote.transact(Stub.TRANSACTION_addBook, _data, _reply, 0); //這里的mRemote就是asInterface方法傳過來的obj參數 ~~~ 3）Server則是通過onTransact方法接收Client進程傳過來的數據，包括函數名稱、函數參數，找到對應的函數，這里是sum，把參數喂進去，得到結果，返回。 所以onTransact函數經歷了讀數據-->執行要調用的函數-->把執行結果再寫數據的過程。 下一篇文章要介紹的四大組件的原理，我們都可以對照著AIDL的這張圖來看，比如說，四大組件的啟動和后續流程，都是在和ActivityManagerService（簡稱AMS）來來回回的通信，四大組件給AMS發消息，四大組件就是Binder Client，而AMS就是Binder Server；AMS發消息通知四大組件，那么角色就互換。 那么四大組件中，比如說Activity，又是哪個類扮演了Stub的角色，哪個類扮演了Proxy的角色呢？這也是我下一篇文章要介紹的，包括AMS、四大組件各自的運行原理。