#### 2.2.2 多進程模式的運行機制 如果用一句話來形容多進程，那筆者只能這樣說：“**當應用開啟了多進程以后，各種奇怪的現象都出現了**”。為什么這么說呢？這是有原因的。大部分人都認為開啟多進程是很簡單的事情，只需要給四大組件指定android:process屬性即可。比如說在實際的產品開發中，可能會有多進程的需求，需要把某些組件放在單獨的進程中去運行，很多人都會覺得這不很簡單嗎？然后迅速地給那些組件指定了android:process屬性，然后編譯運行，發現“正常地運行起來了”。這里筆者想說的是，那是真的正常地運行起來了嗎？ 現在先不置可否，下面先給舉個例子，然后引入本節的話題。還是本章剛開始說的那個例子，其中SecondActivity通過指定android:process屬性從而使其運行在一個獨立的進程中，這里做了一些改動，我們新建了一個類，叫做UserManager，這個類中有一個public的靜態成員變量，如下所示。 public class UserManager { public static int sUserId = 1; } **MainActivity.java** ``` package com.ryg.chapter_2; public class MainActivity extends Activity { private static final String TAG = "MainActivity"; @Override protected void onCreate(Bundle savedInstanceState) { super.onCreate(savedInstanceState); setContentView(R.layout.activity_main); UserManager.sUserId = 2; } @Override protected void onResume() { Log.d(TAG, "UserManage.sUserId=" + UserManager.sUserId); persistToFile(); super.onStart(); } } ``` **SecondActivity.java** ``` package com.ryg.chapter_2; public class SecondActivity extends Activity { private static final String TAG = "SecondActivity"; @Override protected void onCreate(Bundle savedInstanceState) { super.onCreate(savedInstanceState); setContentView(R.layout.activity_second); Log.d(TAG, "onCreate"); } @Override protected void onResume() { super.onResume(); Log.d(TAG, "UserManage.sUserId=" + UserManager.sUserId); } } ``` 然后在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方式就比較簡單了。