2.2 Android中的多進程模式

在正式介紹進程間通信之前，我們必須先要理解Android中的多進程模式。通過給四大組件指定android:process屬性，我們可以輕易地開啟多進程模式，這看起來很簡單，但是實際使用過程中卻暗藏殺機，多進程遠遠沒有我們想的那么簡單，有時候我們通過多進程得到的好處甚至都不足以彌補使用多進程所帶來的代碼層面的負面影響。下面會詳細分析這些問題。

2.2.1 開啟多進程模式

正常情況下，在Android中多進程是指一個應用中存在多個進程的情況，因此這里不討論兩個應用之間的多進程情況。首先，在Android中使用多進程只有一種方法，那就是給四大組件（Activity、Service、Receiver、ContentProvider）在AndroidMenifest中指定android:process屬性，除此之外沒有其他辦法，也就是說我們無法給一個線程或者一個實體類指定其運行時所在的進程。其實還有另一種非常規的多進程方法，那就是通過JNI在native層去fork一個新的進程，但是這種方法屬于特殊情況，也不是常用的創建多進程的方式，因此我們暫時不考慮這種方式。下面是一個示例，描述了如何在Android中創建多進程：

          <activity
              android:name="com.ryg.chapter_2.MainActivity"
              android:configChanges="orientation|screenSize"
              android:label="@string/app_name"
              android:launchMode="standard" >
              <intent-filter>
                  <action android:name="android.intent.action.MAIN" />
                  <category android:name="android.intent.category.LAUNCHER" />
              </intent-filter>
          </activity
          <activity
              android:name="com.ryg.chapter_2.SecondActivity"
              android:configChanges="screenLayout"
              android:label="@string/app_name"
              android:process=":remote" />
          <activity
              android:name="com.ryg.chapter_2.ThirdActivity"
              android:configChanges="screenLayout"
              android:label="@string/app_name"
              android:process="com.ryg.chapter_2.remote" />

上面的示例分別為SecondActivity和ThirdActivity指定了process屬性，并且它們的屬性值不同，這意味著當前應用又增加了兩個新進程。假設當前應用的包名為“com.ryg. chapter_2”，當SecondActivity啟動時，系統會為它創建一個單獨的進程，進程名為“com.ryg.chapter_2:remote”；當ThirdActivity啟動時，系統也會為它創建一個單獨的進程，進程名為“com.ryg.chapter_2.remote”。同時入口Activity是MainActivity，沒有為它指定process屬性，那么它運行在默認進程中，默認進程的進程名是包名。下面我們運行一下看看效果，如圖2-1所示。進程列表末尾存在3個進程，進程id分別為645、659、672，這說明我們的應用成功地使用了多進程技術，是不是很簡單呢？這只是開始，實際使用中多進程是有很多問題需要處理的。

圖2-1 系統進程列表

除了在Eclipse的DDMS視圖中查看進程信息，還可以用shell來查看，命令為：adb shell ps或者adb shell ps | grep com.ryg.chapter_2。其中com.ryg.chapter_2是包名，如圖2-2所示，通過ps命令也可以查看一個包名中當前所存在的進程信息。

圖2-2 通過ps命令來查看進程信息

不知道讀者朋友有沒有注意到，SecondActivity和ThirdActivity的android:process屬性分別為“:remote”和“com.ryg.chapter_2.remote”，那么這兩種方式有區別嗎？其實是有區別的，區別有兩方面：首先，“:”的含義是指要在當前的進程名前面附加上當前的包名，這是一種簡寫的方法，對于SecondActivity來說，它完整的進程名為com.ryg.chapter_2:remote，這一點通過圖2-1和2-2中的進程信息也能看出來，而對于ThirdActivity中的聲明方式，它是一種完整的命名方式，不會附加包名信息；其次，進程名以“:”開頭的進程屬于當前應用的私有進程，其他應用的組件不可以和它跑在同一個進程中，而進程名不以“:”開頭的進程屬于全局進程，其他應用通過ShareUID方式可以和它跑在同一個進程中。

我們知道Android系統會為每個應用分配一個唯一的UID，具有相同UID的應用才能共享數據。這里要說明的是，兩個應用通過ShareUID跑在同一個進程中是有要求的，需要這兩個應用有相同的ShareUID并且簽名相同才可以。在這種情況下，它們可以互相訪問對方的私有數據，比如data目錄、組件信息等，不管它們是否跑在同一個進程中。當然如果它們跑在同一個進程中，那么除了能共享data目錄、組件信息，還可以共享內存數據，或者說它們看起來就像是一個應用的兩個部分。

2.2.2 多進程模式的運行機制

如果用一句話來形容多進程，那筆者只能這樣說：“當應用開啟了多進程以后，各種奇怪的現象都出現了”。為什么這么說呢？這是有原因的。大部分人都認為開啟多進程是很簡單的事情，只需要給四大組件指定android:process屬性即可。比如說在實際的產品開發中，可能會有多進程的需求，需要把某些組件放在單獨的進程中去運行，很多人都會覺得這不很簡單嗎？然后迅速地給那些組件指定了android:process屬性，然后編譯運行，發現“正常地運行起來了”。這里筆者想說的是，那是真的正常地運行起來了嗎？現在先不置可否，下面先給舉個例子，然后引入本節的話題。還是本章剛開始說的那個例子，其中SecondActivity通過指定android:process屬性從而使其運行在一個獨立的進程中，這里做了一些改動，我們新建了一個類，叫做UserManager，這個類中有一個public的靜態成員變量，如下所示。

          public class UserManager {
              public static int sUserId = 1;
          }

然后在MainActivity的onCreate中我們把這個sUserId重新賦值為2，打印出這個靜態變量的值后再啟動SecondActivity，在SecondActivity中我們再打印一下sUserId的值。按照正常的邏輯，靜態變量是可以在所有的地方共享的，并且一處有修改處處都會同步，圖2-3是運行時所打印的日志，我們看一下結果如何。

圖2-3 系統日志

看了圖2-3中的日志，發現結果和我們想的完全不一致，正常情況下SecondActivity中打印的sUserId的值應該是2才對，但是從日志上看它竟然還是1，可是我們的確已經在MainActivity中把sUserId重新賦值為2了。看到這里，大家應該明白了這就是多進程所帶來的問題，多進程絕非只是僅僅指定一個android:process屬性那么簡單。

上述問題出現的原因是SecondActivity運行在一個單獨的進程中，我們知道Android為每一個應用分配了一個獨立的虛擬機，或者說為每個進程都分配一個獨立的虛擬機，不同的虛擬機在內存分配上有不同的地址空間，這就導致在不同的虛擬機中訪問同一個類的對象會產生多份副本。拿我們這個例子來說，在進程com.ryg.chapter_2和進程com.ryg. chapter_2:remote中都存在一個UserManager類，并且這兩個類是互不干擾的，在一個進程中修改sUserId的值只會影響當前進程，對其他進程不會造成任何影響，這樣我們就可以理解為什么在MainActivity中修改了sUserId的值，但是在SecondActivity中sUserId的值卻沒有發生改變這個現象。

所有運行在不同進程中的四大組件，只要它們之間需要通過內存來共享數據，都會共享失敗，這也是多進程所帶來的主要影響。正常情況下，四大組件中間不可能不通過一些中間層來共享數據，那么通過簡單地指定進程名來開啟多進程都會無法正確運行。當然，特殊情況下，某些組件之間不需要共享數據，這個時候可以直接指定android:process屬性來開啟多進程，但是這種場景是不常見的，幾乎所有情況都需要共享數據。

一般來說，使用多進程會造成如下幾方面的問題：

（1）靜態成員和單例模式完全失效。

（2）線程同步機制完全失效。

（3）SharedPreferences的可靠性下降。

（4）Application會多次創建。

第1個問題在上面已經進行了分析。第2個問題本質上和第一個問題是類似的，既然都不是一塊內存了，那么不管是鎖對象還是鎖全局類都無法保證線程同步，因為不同進程鎖的不是同一個對象。第3個問題是因為SharedPreferences不支持兩個進程同時去執行寫操作，否則會導致一定幾率的數據丟失，這是因為SharedPreferences底層是通過讀/寫XML文件來實現的，并發寫顯然是可能出問題的，甚至并發讀/寫都有可能出問題。第4個問題也是顯而易見的，當一個組件跑在一個新的進程中的時候，由于系統要在創建新的進程同時分配獨立的虛擬機，所以這個過程其實就是啟動一個應用的過程。因此，相當于系統又把這個應用重新啟動了一遍，既然重新啟動了，那么自然會創建新的Application。這個問題其實可以這么理解，運行在同一個進程中的組件是屬于同一個虛擬機和同一個Application的，同理，運行在不同進程中的組件是屬于兩個不同的虛擬機和Application的。為了更加清晰地展示這一點，下面我們來做一個測試，首先在Application的onCreate方法中打印出當前進程的名字，然后連續啟動三個同一個應用內但屬于不同進程的Activity，按照期望，Application的onCreate應該執行三次并打印出三次進程名不同的log，代碼如下所示。

        public class MyApplication extends Application {

            private static final String TAG = "MyApplication";

            @Override
            public void onCreate() {
              super.onCreate();
              String processName = MyUtils.getProcessName(getApplicationContext(),
              Process.myPid());
              Log.d(TAG, "application start, process name:" + processName);
            }

        }

運行后看一下log，如圖2-4所示。通過log可以看出，Application執行了三次onCreate，并且每次的進程名稱和進程id都不一樣，它們的進程名和我們為Activity指定的android:process屬性一致。這也就證實了在多進程模式中，不同進程的組件的確會擁有獨立的虛擬機、Application以及內存空間，這會給實際的開發帶來很多困擾，是尤其需要注意的。或者我們也可以這么理解同一個應用間的多進程：它就相當于兩個不同的應用采用了SharedUID的模式，這樣能夠更加直接地理解多進程模式的本質。

圖2-4 系統日志

本節我們分析了多進程所帶來的問題，但是我們不能因為多進程有很多問題就不去正視它。為了解決這個問題，系統提供了很多跨進程通信方法，雖然說不能直接地共享內存，但是通過跨進程通信我們還是可以實現數據交互。實現跨進程通信的方式很多，比如通過Intent來傳遞數據，共享文件和SharedPreferences，基于Binder的Messenger和AIDL以及Socket等，但是為了更好地理解各種IPC方式，我們需要先熟悉一些基礎概念，比如序列化相關的Serializable和Parcelable接口，以及Binder的概念，熟悉完這些基礎概念以后，再去理解各種IPC方式就比較簡單了。