剛開始看的時候，我的頭是這麼大
，看了一夜的時候，頭就變成這樣了，
，嚇得寶寶趕緊上牀休息了，、
先喝喝茶講個故事再來說這個通訊。
(寫完之後，看到這個終於承認了自己寫作的能力很爛，但是好歹也是自己一個一個敲上去的，不能白白辛苦啊，嘿嘿)
-----------------------------------------------------------------------------------------------------------------
話說我有一哥們，最近他前女友來找他複合，但是他現在有女友，所以很是煩惱，整天吃不好睡不着，所以他打算問問上帝有什麼好主意，可是爲了安全起見，他又不能直接去找上帝，總不能一天死個5，6次吧，人生是沒有bug的。那怎麼辦呢，幸好這世上還有一種生物叫神父，然後他就去找神父。
“father ，我最近很煩惱，你可以幫我問問上帝該怎麼辦嗎”
“oh my son 上帝是萬能的，他可以幫我們解決任何問題，有什麼就說吧”
“我現在有女朋友了，可是我的前女友最近又來找我複合，兩個都對我很好，我該怎麼辦呢。。。。。(此處省略N多字)”
神父把上帝從睡夢中喊醒“上帝啊，這人有病啊，有兩個女的都喜歡他，直接收了不就完了，他還在糾結該選那個，您看這個怎麼辦纔好呢”
“哦，這件事我知道，他不是有個好朋友叫楊XX嗎，我已經施法讓他的前女友喜歡上楊XX了，哈哈”
“son，上帝已經施法讓你的前女友喜歡上了別人，是你的一個好朋友楊XX,你看這樣好不”
。。。。。。。。。。
情景轉到籃球場，我正在一羣少女的歡呼中揮灑魅力，突然被一個手臂一拉。
“XX，你知道我最近很煩心的那個事嗎？”
我正因爲被他從少女的崇拜中打攪不爽“不就是那個前女友嗎，怎麼了”
“哈哈，我今天去找上帝，上帝已經幫我解決了”
“哦，怎麼解決的，看你高興的”
“上帝施法讓我的前女友喜歡你了”
我眼前一黑，一口心血噴出“上帝，臥槽你X“
我的女友是跆拳道黑帶三段。
---------------------------------------------------------------------------------------------------------------
(我又看了一遍，這個故事的確有點扯。。。。)
好了，忘掉吧，你可能會感到這個故事跟進程間通訊半毛錢關係沒有，但我感覺還是挺好的。。
Android進程間通訊，
爲什麼不能直接跨進程進行通訊啊？
-
- 因爲，爲了安全考慮。Android系統中，應用所在的內存是獨立的，無法相互訪問，各個應用的數據都在自己的內存中。
那麼如何跨進程進行通訊呢？
-
- 要想跨進程，必須找一個公共的大家都能訪問的地方，通過暗號來達到通訊的目的。
Android中的跨進程通訊採用的是binder機制。
那麼什麼是binder呢，這個工作原理是什麼呢，
Binder呢，其實就是一塊內存，它在Linux層面屬於一個驅動，但是這個驅動不是驅動硬件，而是驅動一塊內存。不同的應用通過對一塊公共的內存進行數據的讀寫，來達到通訊的目的。而且應用之間進行通訊，
必須要有暗號（沒有暗號就成了火鍋，亂套了！），當兩個應用持有相同的暗號（AIDL時），纔可以進行通訊。
知道了爲什麼跨，怎麼跨，那麼具體步驟怎麼寫呢？
由於不是本文重點，請看官方開發文檔，現在開發文檔越來越詳細，估計人家美國12歲的小學生都能隨便開發一個簡單的應用。唉 英語啊。
知道了以上這些東西，可是binder是怎麼工作的，卻還不知道，接下來爲大家介紹一下binder的工作原理。
在Android系統中的binder機制中，分別由Client,Server,ServiceManager和Binder驅動程序組成，其中Client、Server和Service Manager運行在用戶空間，Binder驅動程序運行內核空間。Binder驅動程序是核
心組件， Service Manager是一個守護進程，用來管理Server，並向Client提供查詢Server接口的功能，開發者只需要在用戶空間實現自己的Client和Server即可。而Client和Server正是在Binder驅動和ServiceManager提供的基礎設施上，進行通信的。
binder工作原理：
binder通信是一種client-server的通信結構，
1.從表面上來看，是client通過獲得一個server的代理接口，對server進行直接調用；
2.實際上，代理接口中定義的方法與server中定義的方法是一一對應的；
3.client調用某個代理接口中的方法時，代理接口的方法會將client傳遞的參數打包成爲Parcel對象；
4.代理接口將該Parcel發送給內核中的binder driver.
5.server會讀取binder driver中的請求數據，如果是發送給自己的，解包Parcel對象，處理並將結果返回；
6.整個的調用過程是一個同步過程，在server處理的時候，client會阻塞
直接看不好理解，還好有圖。
前面已經說過，Service Manager組件是用來管理Server並且向Client提供查詢Server遠程接口的功能，那麼，Service Manager就必然要和Server以及Client進行通信了。然而，Service Manager、Client和
Server三者分別是運行在獨立的進程當中，這樣它們之間的通信也屬於進程間通信了，而且也是採用Binder機制進行進程間通信，因此，ServiceManager在充當Binder機制的守護進程的角色的同時，也在充當Server
的角色，也就是說，它是一種特殊的Server。
其實在平時開發中，系統服務就是通過Binder機制來和應用通訊的，接下來爲大家詳細解釋一下系統服務和應用通訊流程，以幫助大家更容易深刻的理解binder機制。
系統服務和應用的通信機制
系統服務：
1.是一個Binder類的子類，一旦創建後，就開啓一個線程死循環用來檢測某段內存是否有數據寫入。
2.它自身創建時，創建一個xxxRemote遠程對象，存放到Binder驅動中,xxxRemote遠程對象可以和xxxService系統服務通信
應用端：
通過context. getSystemService獲取xxxServiceProxy對象，該對象內部引用了xxxRemote對象， xxxServiceProxy和xxxService具有相同的API，我們調用xxxServiceProxy時，xxxServiceProxy就調用
xxxRemote並等待xxxRemote返回。xxxRemote會往某段內存中寫入數據，寫完後就開始監視該內存區域，Binder驅動會把xxxRemote寫入的數據拷貝到xxxService監視着的內存區域，當xxxService一旦發現有數
據，就讀取並進行處理，處理完畢後，就寫入該區域，這時Binder驅動又會把該數據拷貝到xxxRemote監視的內存區域，當xxxRemote發現內存區域有數據讀取該區域數據，並把內容返回給xxxServiceProxy。這樣
就完成了一次進程間的通信。
所以一個系統服務會產生兩個Binder對象，一個是運行在系統中的系統服務本身，一個是存放到Binder驅動中的遠程對象。所不同的是系統服務Binder對象會開啓一個線程監聽消息，遠程對象不會，它是運行在
調用者的線程中。
客戶端也可以不使用系統服務的遠程Binder對象，而是自己創建一個Binder對象，通過Binder驅動和系統服務進行關聯，這樣的好處客戶端可以隨時通知系統服務，系統服務也可以隨時通知客戶端，而不是像上
面所說的系統服務只能被動的等着客戶端調用。
那麼binder內部是怎麼操作的
Binder對象都有各自的內存區域，當Binder1想要向Binder2發送數據時，就會把數據寫入自己的內存區域，然後通知Binder驅動，Binder驅動會把數據拷貝到Binder2的內存區
域，然後通知Binder2進行讀取，Binder2讀取完畢後，將把數據寫入binder2的內存區域，然後通知Binder驅動，Binder驅動將會把數據拷貝到Binder1的內存區域中。這樣就完成
了一次通信。
如果Binder1是系統服務，Binder2是系統服務的遠程對象，這樣任何應用程序在獲取了Binder2的引用後，都可以和Binder1進行通信。但是缺點也很明顯，只能由應用端請求
系統服務，系統服務不能主動去聯繫應用端。WifiManagerService之類的就是採用這種方式。
還有一種方式是Binder1是系統服務，Binder2是應用端創建的Binder對象，他們兩者通過Binder驅動進行連接後，應用端可以主動調系統服務，系統服務也可以主動調用應用
端。WindowManagerService就是採用的這種方式。
我是看了很多資料才寫出的這篇博客，大家有興趣可以去看看http://blog.csdn.net/luoshengyang/article/details/6618363#comments的博客，的確大牛。