IPC是Inter-Process Communication的縮寫讽坏，含義為進(jìn)程間通信或跨進(jìn)程通信妥箕，是指兩個進(jìn)程之間進(jìn)行數(shù)據(jù)交換的過程笙隙。
進(jìn)程和線程是兩個不同的概念结啼，它們之間是包含與被包含的關(guān)系。
進(jìn)程：一個執(zhí)行單元沮榜，指一個程序或應(yīng)用盘榨；
線程：CPU調(diào)度的最小單元；
一個進(jìn)程可以包含多個線程蟆融。
Android應(yīng)用內(nèi)多進(jìn)程唯一的方法：給四大組件在AndroidMenifest中指定android:process屬性草巡，無法給一個實體類或一個線程指定其運行時所在的進(jìn)程。
（非常規(guī)的多進(jìn)程方法：通過JNI在native層去fork一個新的進(jìn)程型酥。這種方法屬于特殊情況山憨，不是常用的創(chuàng)建多進(jìn)程的方式查乒，暫不討論）
進(jìn)程名命名方式：
以“:”開頭的進(jìn)程屬于當(dāng)前應(yīng)用的私有進(jìn)程，其他應(yīng)用的組件不可以和它跑在同一進(jìn)程中郁竟；
不以“:”開頭的進(jìn)程屬于全局進(jìn)程玛迄，其他應(yīng)用通過ShareUID的方式可以和它跑在同一進(jìn)程中（要求兩個應(yīng)用具有相同的ShareUID并且簽名相同）。
Android會為每個進(jìn)程分配一個獨立的虛擬機棚亩，這個過程就是啟動一個應(yīng)用的過程蓖议，不同的虛擬機在內(nèi)存分配上有不同的地址空間，這就導(dǎo)致在不同的虛擬機中訪問同一個類的對象會產(chǎn)生多份副本蔑舞。運行在同一個進(jìn)程中的組件是屬于同一個虛擬機和同一個Application的拒担，運行在不同進(jìn)程中的組件是屬于兩個不同的虛擬機和Application的。所以攻询，應(yīng)用內(nèi)使用多進(jìn)程會造成如下問題：
(1) 靜態(tài)成員和單例模式完全失效从撼；
(2) 線程同步機制完全失效；
(3) SharedPreferences的可靠性下降钧栖；
(4) Application會多次重建低零。
為了解決進(jìn)程間數(shù)據(jù)共享問題，提供了如下幾種IPC方式：
1. 使用Bundle
我們知道拯杠，Activity掏婶、Service、BroadcastReceiver都支持在Intent中傳遞Bundle數(shù)據(jù)潭陪，由于Bundle實現(xiàn)了Parcelable接口雄妥，所以它可以在不同進(jìn)程間傳輸，我們只要在Bundle中附加需要傳輸給其他進(jìn)程的數(shù)據(jù)并通過Intent發(fā)送出去即可依溯。注意老厌，傳輸?shù)臄?shù)據(jù)必須能夠被序列化。
2. 使用文件共享
兩個進(jìn)程可以通過讀/寫同一個文件來交換數(shù)據(jù)黎炉，這種方式來共享數(shù)據(jù)對文件格式?jīng)]有具體要求枝秤，只要約定好格式即可。這種方式的局限性在于慷嗜，可能出現(xiàn)并發(fā)讀/寫的問題淀弹，導(dǎo)致讀出的內(nèi)容不是最新的，并發(fā)寫的話更嚴(yán)重庆械。所以薇溃，這種方式適合在對數(shù)據(jù)同步要求不高的進(jìn)程之間通信，并要妥善處理并發(fā)讀/寫的問題缭乘。
注意：SharedPreferences是個特例痊焊，它也屬于文件的一種，但是系統(tǒng)對它的讀/寫有一定的緩存策略忿峻，在內(nèi)存中會有一份SharedPreferences文件的緩存薄啥，因此在多進(jìn)程模式下，系統(tǒng)對它的讀/寫就變得不可靠逛尚，面對高并發(fā)的讀/寫操作垄惧，它有很大幾率會丟失數(shù)據(jù)，因此绰寞，不建議在進(jìn)程間通信使用SharedPreferences到逊。
3. 使用AIDL
大致流程：服務(wù)端首先要創(chuàng)建一個Service來監(jiān)聽客戶端的連接請求，然后創(chuàng)建一個AIDL文件滤钱，將暴露給客戶端的接口在這個AIDL文件中聲明觉壶，接著創(chuàng)建一個類繼承自AIDL接口中的Stub類并實現(xiàn)Stub中的抽象方法，在Service的onBind方法中返回這個類對象件缸；最后铜靶，客戶端綁定服務(wù)端service，建立連接后就可以訪問服務(wù)端方法了他炊。詳情鏈接
4. 使用Messenger
Messenger譯為信使争剿，可以在不同進(jìn)程中傳遞Message對象，在Message中放入需要傳遞的數(shù)據(jù)即可痊末。它是一種輕量級的IPC方案蚕苇，底層實現(xiàn)是AIDL。
它一次處理一個請求凿叠，在服務(wù)端不需要考慮線程同步的問題涩笤，因為在服務(wù)端不存在并發(fā)執(zhí)行的情形。實現(xiàn)一個Messenger的步驟：
- 服務(wù)端首先要創(chuàng)建一個Service來監(jiān)聽客戶端的連接請求盒件，同時創(chuàng)建一個Handler并通過它來創(chuàng)建一個Messenger對象蹬碧，然后在Service的onBind中返回這個Messenger對象底層的Binder。
- 客戶端首先要綁定服務(wù)端的Service履恩，綁定成功后用服務(wù)端返回的IBinder對象創(chuàng)建一個Messenger對象锰茉，通過這個Messenger就可以向服務(wù)端發(fā)送消息了，消息類型為Message對象切心。當(dāng)客戶端需要服務(wù)端回應(yīng)時飒筑，還需要創(chuàng)建一個Handler并創(chuàng)建一個新的Messenger，并把這個Messenger對象通過Message的replyTo參數(shù)傳遞給服務(wù)端绽昏，服務(wù)端通過這個replyTo參數(shù)就可以回應(yīng)客戶端了协屡。
5. 使用ContentProvider
6. 使用Socket
Socket氛圍流式套接字和用戶數(shù)據(jù)報套接字，分別對應(yīng)網(wǎng)絡(luò)控制傳輸層的TCP和UDP協(xié)議全谤。進(jìn)程間通信一般不選用此方式肤晓，故本章節(jié)對此方式不做詳細(xì)介紹。
TCP協(xié)議：面向連接的協(xié)議，提供穩(wěn)定的雙向通信功能补憾。TCP連接的建立需要經(jīng)過“三次握手”漫萄，本身也提供了超時重傳機制，有很高的穩(wěn)定性盈匾；
UDP協(xié)議：無連接的協(xié)議腾务，提供不穩(wěn)定的單向通信功能。在性能上削饵，UDP有更好的效率岩瘦，缺點是不保證數(shù)據(jù)一定能夠正確傳輸，尤其在網(wǎng)絡(luò)擁塞的情況下窿撬。
總結(jié)：IPC方式對比（優(yōu)缺點及適用場景）
