關於進程之間的通信又很多種方式，不同的方式適用於不同的場景。
五種不同形式的IPC形式
1.消息傳遞（管道，FIFO和消息隊列）
2.同步（互斥量，條件變量，讀寫鎖，文件和記錄鎖，信號量）
3.共享內存（匿名的和具名的）
4.遠程過程調用（Solaris門和Sun RPC 以及Android Binder）
5.通過計算機網絡通信的程序，使用TCP/IP協議族API（跨網絡IPC）
1.管道(pipe)
特點：單向的，具有“讀取”端和“寫入”端，容量有限。
2.Signal 實時信號量
3.Trace 跟蹤
以上三種只適合父進程與子線程或者 兄弟進程之間的通信
4.System V 之 報文隊列（Message）
5.System V 之 共享內存（ShareMessage）
實現共享內存的步驟
1.創建內存共享區
2.映射內存區
3.訪問內存共享區
4.進程間通信
5.撤銷內存映射區
6.刪除內存共享區
6.System V 之 信號量 (Semaphore)
信號量與PV原語是由Dijkstra發明的，也是使用最爲廣泛的互斥方法之一。
P操作的執行過程
- 信號量S自減1
- 如果此時S依然>=0。說明共享資源此時是允許訪問的，因而調用者直接返回，然後開始操作共享資源
- 否則的話就要等待別人主動釋放資源，這種情況調用者會被加入等待序列，直到後續被喚醒
- 當某人釋放了共享資源後，等待隊列中的相關（取決於具體情況）對象會被喚醒，此時該對象具備訪問資源的權力
- 信號量S自增1
- 此時如果S>0 ，說明當前沒有希望訪問資源的等待者，所以直接返回
- 否則V操作要喚醒等待隊列中的相關對象，對應P操作中的最後一步。
7.基於TCP／IP的Socket IPC通信
8.同步
由Posix線程標準定義的兩種同步形式：互斥鎖(Mutex)、讀寫鎖和條件變量。
Mutex 中文釋義爲互斥體。
它與Semaphore的區別：
如果允許多個變量同時訪問，稱爲Counting Semaphores；而對於只允許取值0或1 則叫做Binary Semaphore 後者與Mutex具有相同的性質。
Mutex通常對某一排他資源的共享控制要麼資源被佔用（locked）要麼就是可以訪問（unlocked）。
兩者沒有本質區別
管程 ：它實際是對Semaphore的擴展和延伸，是一種控制更爲簡單的同步手段
9.Unix Domain Socket
UDS是專門針對單機內的進程間通信提出來的，有時被稱爲IPC socket。實際實現機制不依賴於TCP／IP協議族。
- 服務端監聽IPC請求
- 客戶端發起IPC申請
- 雙方成功建立IPC連接
- 客戶端向服務端發送數據，證明IPC通信有效
10.System V 消息隊列，信號量，和共享內存與 Posix 消息隊列，信號量，和共享內存的區別？
11.android中的同步機制
Mutex
Condition：是條件變量在android系統中的實現類，
Barrier：同時基於Mutex和Condition實現的一個模型，
Android Binder
Socket作爲一款通用的接口，其傳輸效率低,開銷大，主要用在跨網絡的進程間通信和本機進程間的低速通信。
消息隊列和管道採取存儲-轉發方式，即數據先從發送方緩存區拷貝到內核開闢的緩衝區中，再從內核緩衝區拷貝到接收方緩存區，至少兩次拷貝過程。
共享內存雖然無需拷貝，但是控制複雜，難以使用。
Binder只需拷貝一次
傳統IPC沒有任何安全做措施，完全依賴上層協議來確保。
這時android需要建立一套新的IPC機制來滿足系統對通信的要求
Binder提供遠程調用(Remote Procedure Cails)功能，可以讓C++或者Java的對象實例從一個進程遷移到另一個進程，從而透明地實現跨進程的調用面向對象思想的引入將進程間通信轉化爲通過對某個Binder對象的引用調用該對象的方法,而其獨特之處在於Binder對象是一個可以跨進程引用的對象,它的實體位於一個進程中,而它的引用卻遍佈於系統的各個進程之中。最誘人的是,這個引用和java裏引用一樣既可以是強類型,也可以是弱類型,而且可以從一個進程傳給其它進程,讓大家都能訪問同一Server,就象將一個對象或引用賦值給另一個引用一樣。Binder模糊了進程邊界,淡化了進程間通信過程,整個系統彷彿運行於同一個面向對象的程序之中。形形色色的Binder對象以及星羅棋佈的引用彷彿粘接各個應用程序的膠水,這也是Binder在英文裏的原意
主要組成部分：Server ，Client ，ServiceManager 以及Binder驅動
1.binder驅動：
它位於內核，是通訊的核心，負責進程之間Binder通信的建立,Binder在進程之間的傳遞,Binder引用計數管理,數據包在進程之間的傳遞和交互等一系列底層支持。
2.ServiceManager（SMgr）
和DNS類似,SMgr的作用是將字符形式的Binder名字轉化成Client中對該Binder的引用,使得Client能夠通過Binder名字獲得對Server中Binder實體的引用。
3.Server
Server創建一個Binder實體，Client在獲得實體引用後，向Server傳送數據，Server收到數據後做出相應的處理。
4.Client
Server向SMgr註冊了Binder實體及其名字後,Client就可以通過名字獲得該Binder的引用了。
完成一次通信的過程
1.客戶端進程調用Stub接口
2.Stub根據系統的要求進行打包
3.內核來完成與服務器的具體交互，它負責將客戶端的數據發送給服務端內核
4.服務端Stub解包，並調用與數據包匹配的進程
5.進程執行操作
6.服務端以上述步驟的逆向過程返回給客戶端