重溫關於進程間通訊的方式

 

首先，咱們先要定義多進程:

定義多進程：

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來請求端口，連通後就能夠進行通訊。