定義多進程
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來請求端口，連通后就可以進行通信。