① android開發中跨進程通信有幾種方式
Android進程間通信的幾種方式 定義多進程
第一：Android應用中使用多進程只有一個辦法（用NDK的fork來做除外），就是在AndroidManifest.xml中聲明組件時，用android:process屬性來指定。
不知定process屬性，則默認運行在主進程中，主進程名字為包名。
android:process = package:remote，將運行在package:remote進程中，屬於全局進程，其他具有相同shareUID與簽名的APP可以跑在這個進程中。
android:process = :remote ，將運行在默認包名:remote進程中，而且是APP的私有進程，不允許其他APP的組件來訪問。
第二：多進程引發的問題
靜態成員和單例失效：每個進程保持各自的靜態成員和單例，相互獨立。
線程同步機制失效：每個進程有自己的線程鎖。
SharedPreferences可靠性下降：不支持並發寫，會出現臟數據。
Application多次創建：不同進程跑在不同虛擬機，每個虛擬機啟動會創建自己的Application，自定義Application時生命周期會混亂。
綜上，不同進程擁有各自獨立的虛擬機，Application，內存空間，由此引發一系列問題。
第三： 進程間通信
Bundle/Intent傳遞數據：
可傳遞基本類型，String，實現了Serializable或Parcellable介面的數據結構。Serializable是java的序列化方法，Parcellable是Android的序列化方法，前者代碼量少（僅一句），但I/O開銷較大，一般用於輸出到磁碟或網卡；後者實現代碼多，效率高，一般用戶內存間序列化和反序列化傳輸。
文件共享：
對同一個文件先後寫讀，從而實現傳輸，Linux機制下，可以對文件並發寫，所以要注意同步。順便一提，Windows下不支持並發讀或寫。
Messenger：
Messenger是基於AIDL實現的，服務端（被動方）提供一個Service來處理客戶端（主動方）連接，維護一個Handler來創建Messenger，在onBind時返回Messenger的binder。
雙方用Messenger來發送數據，用Handler來處理數據。Messenger處理數據依靠Handler，所以是串列的，也就是說，Handler接到多個message時，就要排隊依次處理。
AIDL：
AIDL通過定義服務端暴露的介面，以提供給客戶端來調用，AIDL使伺服器可以並行處理，而Messenger封裝了AIDL之後只能串列運行，所以Messenger一般用作消息傳遞。
通過編寫aidl文件來設計想要暴露的介面，編譯後會自動生成響應的java文件，伺服器將介面的具體實現寫在Stub中，用iBinder對象傳遞給客戶端，客戶端bindService的時候，用asInterface的形式將iBinder還原成介面，再調用其中的方法。
ContentProvider：
系統四大組件之一，底層也是Binder實現，主要用來為其他APP提供數據，可以說天生就是為進程通信而生的。自己實現一個ContentProvider需要實現6個方法，其中onCreate是主線程中回調的，其他方法是運行在Binder之中的。自定義的ContentProvider注冊時要提供authorities屬性，應用需要訪問的時候將屬性包裝成Uri.parse("content://authorities")。還可以設置permission，readPermission，writePermission來設置許可權。 ContentProvider有query，delete，insert等方法，看起來貌似是一個資料庫管理類，但其實可以用文件，內存數據等等一切來充當數據源，query返回的是一個Cursor，可以自定義繼承AbstractCursor的類來實現。
Socket：
學過計算機網路的對Socket不陌生，所以不需要詳細講述。只需要注意，Android不允許在主線程中請求網路，而且請求網路必須要注意聲明相應的permission。然後，在伺服器中定義ServerSocket來監聽埠，客戶端使用Socket來請求埠，連通後就可以進行通信。
② 033 Android多進程-共享內存
要使用一塊共享內存
還是先看共享內存的使用方法，我主要介紹兩個函數：
通過 shmget() 函數申請共享內存,它的入參如下
通過 shmat() 函數將我們申請到的共享內存映射到自己的用戶空間，映射成功會返回地址，有了這個地址，我們就可以隨意的讀寫數據了，我們繼續看一下這個函數的入參
共享內存的原理是在內存中單獨開辟的一段內存空間，這段內存空間其實就是一個tempfs（臨時虛擬文件），tempfs是VFS的一種文件系統，掛載在/dev/shm上，前面提到的管道pipefs也是VFS的一種文件系統。
由於共享的內存空間對使用和接收進程來講，完全無感知，就像是在自己的內存上讀寫數據一樣，所以也是 效率最高 的一種IPC方式。
上面提到的IPC的方式都是 在內核空間中開辟內存來存儲數據 ，寫數據時，需要將數據從用戶空間拷貝到內核空間，讀數據時，需要從內核空間拷貝到自己的用戶空間，
共享內存就只需要一次拷貝 ，而且共享內存不是在內核開辟空間，所以可以 傳輸的數據量大 。
但是 共享內存最大的缺點就是沒有並發的控制，我們一般通過信號量配合共享內存使用，進行同步和並發的控制 。
共享內存在Android系統中主要的使用場景是 用來傳輸大數據 ，並且 Android並沒有直接使用Linux原生的共享內存方式，而是設計了Ashmem匿名共享內存 。
之前說到有名管道和匿名管道的區別在於有名管道可以在vfs目錄樹中查看到這個管道的文件，但是匿名管道不行， 所以匿名共享內存同樣也是無法在vfs目錄中查看到 的， Android之所以要設計匿名共享內存 ，我覺得主要是為了安全性的考慮吧。
我們來看看共享內存的一個使用場景，在Android中，如果我們想要將當前的界面顯示出來，需要將當前界面的圖元數據傳遞Surfaceflinger去做圖層混合，圖層混合之後的數據會直接送入幀緩存，送入幀緩存後，顯卡就會直接取出幀緩存里的圖元數據顯示了。
那麼我們如何將應用的Activity的圖元數據傳遞給SurfaceFlinger呢？想要將圖像數據這樣比較大的數據跨進程傳輸，靠binder是不行的，所以這兒便用到匿名共享內存。
從谷歌官方提供的架構圖可以看到，圖元數據是通過BufferQueue傳遞到SurfaceFlinger去的，當我們想要繪制圖像的時候， 需要從BufferQueue中申請一個Buffer，Buffer會調用Gralloc模塊來分配共享內存 當作圖元緩沖區存放我們的圖元數據。
可以看到Android的匿名共享內存是通過 ashmem_create_region() 函數來申請共享內存的，它會在/dev/ashmem下創建一個虛擬文件，Linux原生共享內存是通過shmget()函數，並會在/dev/shm下創建虛擬文件。
匿名共享內存是通過 mmap() 函數將申請到的內存映射到自己的進程空間，而Linux是通過*shmat()函數。
雖然函數不一樣，但是Android的匿名共享內存和Linux的共享內存在本質上是大同小異的。
。
③ Android多進程通信之 Binder
在 Linux 中一個進程空間可以分為 用戶空間 和 內核空間 ，不同的進程它們的用戶空間數據不可共享，但是它們的內核空間的數據可共享，即所有進程共用 1 個內核空間。進程內用戶空間和內核空間進行交互需通過系統調用。
Android 系統時基於 Linux 內核的，Linux 已經提供了多種 IPC 方式，如下：
所以，Android 為啥又單獨弄出一個 Binder 呢？主要有如下原因：
直觀地說，Binder 是 Android 中的一個類，它實現了 IBinder 介面；從 Android Framework 角度來說，Binder 是 ServiceManager 連接各種 Manager(ActivityManager、WindowManager...) 和相應 ManagerService 的橋梁；從 Android 應用層來說，Binder 是客戶端和服務端進行通信的媒介，當 bindService 的時候，服務端會返回一個包含了服務端業務調用的 Binder 對象，通過這個 Binder 對象，客戶端就可以獲取服務端提供的服務或者數據，這里的服務包括普通服務和基於 AIDL 服務。
Binder 定義了四個角色：Server，Client，ServiceManager 和 Bidner 驅動，其中 Server、Client、ServiceManager 運行於用戶空間，Binder 驅動運行於內核空間。
Binder 工作原理：