從很多方面來看，每個Android 應用程序都存在於它自己的世界之中：
• 默認情況下，每個應用程序均運行於它自己的Linux 進程中。當應用程序中的任意代碼開始執行時，Android 啟動一個進程，而當不再需要此進程而其它應用程序又需要系統資源時，則關閉這個進程。
• 每個進程都運行於自己的Java 虛擬機（VM）中。所以應用程序代碼實際上與其它應用程序的代碼是隔絕的。
• 默認情況下，每個應用程序均被賦予一個唯一的Linux 用戶ID，並加以權限設置，使得應用程序的文件僅對這個用戶、這個應用程序可見。當然，也有其它的方法使得這些文件同樣能為別的應用程序所訪問。
通過共享用戶ID來實現多個應用程序使用同一個進程，這樣也能使這些應用程序之間共享內存。
1. 同一Apk中的同一包中的多個Activity調用時進程狀況驗證
[1]創建Project：
project name: FirstProject
package : com.demo
默認Activity : MainActivity
[2]添加一個新的Activity：
name: SecondActivity
[3]修改布局。在MainActivity布局中添加一個Button，當點擊此Button時啟動SecondActivity。在SecondActivity的布局中放置一個Textview，以證明SecondActivity已啟動。
[4]運行程序，查看此App進程情況：
USER：app_36 PID：8360 NAME：com.demo
[5]點擊按鈕，啟動SecondActivity，再次查看進程情況：
USER：app_36 PID：8360 NAME：com.demo
結論：進程列表沒有變化，兩個Activity運行在同一進程中。
2. 同一Apk中的不同包的Activity調用時進程狀況驗證
[1]將SecondActivity挪到包com.demo.second中去，相應修改AndroidManifest.xml中的name為：com.demo.second.SecondActivity
[2]運行程序，查看此時進程情況：
USER：app_36 PID：10593 NAME：com.demo
[3]點擊按鈕啟動SecondActivity，查看此時進程情況：
USER：app_36 PID：10593 NAME：com.demo
結論：進程列表沒有變化，兩個Activity運行在同一進程中。即進程name只受AndroidManifest.xml中manifset結點的package屬性影響。
3. 同一Apk中Activity process屬性修改后進程狀況驗證
[1]為SecondActivity添加process屬性，其值為":abc"，也可以隨便是其他的":"開頭的字符串，常見的名字是":remote"：
</activity>
[2]運行程序，查看進程情況：
USER：app_36 PID：12137 NAME：com.demo
[3]點擊按鈕，啟動SecondActivity，查看進程情況：
USER：app_36 PID：12137 NAME：com.demo
USER：app_36 PID：12303 NAME：com.demo:abc
結論：進程表多了一項。兩個Activity各自有一個進程，SecondActivity的進程名稱為 包名+后綴。
4. 不同Apk中不同包名的Activity進程狀況驗證
[1]運行FirstProject：
USER：app_36 PID：12137 NAME：com.demo
[2]創建SecondProject：
project name: SecondProject
package:com.demo2
默認Activity:MainActivity
[3]運行SecondProject：
USER：app_37 PID：14191 NAME：com.demo2
結論：進程表多了一項。兩個Activity各自有一個進程，同時其進程用戶id、包名也不同，互不影響。
5. 不同Apk，簽名相同、包名相同的Activity進程狀況驗證
[1]修改SecondProject的包也為com.demo，相應要修改AndroidManifest.xml內容。
[2]運行SecondProject，查看進程情況：
USER：app_36 PID：14944 NAME：com.demo
結論：進程表只有一項，但是實際上FirstProject此時已經被覆蓋了，系統中只存在SecondProject了，因為模擬器調試時apk使用的簽名key都是一樣的，系統看到key一樣，包名一樣認為這個包就是FirstProject所以覆蓋掉了。
可以通過DDMS復制/data/system/packages.xml查看一下內容:
這個文件里面，package name都是唯一的，同時可以看到用戶名是通過userId來決定的。
6.不同Apk，簽名不相同，包名相同的Activity進程狀況驗證
[1]在Eclipse的Package Explorer導航樹中選中FirstProject，點右鍵。
[2]Android tools-->Export Signed Application Package，按照向導創建一個用指定key簽名的apk包。
[3]同樣導出Second Project。
[4]切換窗口到模擬器，按Home鍵-->按Menu鍵-->設置-->應用程序-->管理應用程序-->SecondProject-->卸載。這是為了用命令行安裝做准備。
[5]啟動一個命令行窗口，執行adb install firstproject.apk，會提示成功安裝。
[6]執行adb install secondproject.apk，提示安裝失敗。
結論：
1> 默認的Apk其安裝時會分配新的UserId，即此時FirstProject以及SecondProject的UserId可以認為是不同的。
2> 包名不同，則簽名key是否相同無所謂，兩個apk都可以安裝。【第4個實驗】
3> 包名相同時，簽名key相同則會覆蓋【第5個實驗】；簽名不同則第二個apk安裝會失敗。【第6個實驗】
7.不同Apk，Share User Id相同，包名不同時進程情況分析
[1]修改firstproject、secondproject的AndroidManifest.xml的manifset結點，增加屬性
[2]修改secondproject的包為com.demo2，不然其會覆蓋firsetproject。
[3]運行firsetproject、secondproject，查看進程列表：
USER：app_35 PID：19993 NAME：com.demo2
USER：app_35 PID：20045 NAME：com.demo2
結論:
仍然存在兩個進程。但是進程的用戶名一樣，說明shareUserId確實有效了，進程pid不相同。
再次導出/data/system/packages.xml，查看其內容，可以看到兩個項目的UserId都是10035，確實是一樣的：
<package name="com.demo2" codePath="/data/app/com.demo2.apk" system="false" ts="1279957473000" version="1" sharedUserId="10035">
8.不同Apk，Share User Id相同，包名不同、指定Activity的process屬性進程情況分析
[1]修改SecondProject的MainActivity的process屬性，指定綁定到進程名為com.demo的進程上：
[2]運行firstProject、SecondProject，查看進程情況：
USER：app_35 PID：21387 NAME：com.demo
結論：兩個Activity運行於同一個進程。
9.不同Apk，Share User Id相同，包名不同、簽名key不同
經實驗，安裝第二個apk時會提示INSTALL_FAILED_UPDATE_INCOMPATIBLE錯誤，安裝失敗。
總結：
UserId不同時：
包名不同：
未設定process屬性時，各自的Activity在各自的進程。即使process指定了包名，也不會和另一個用戶的同名包共享進程。
包名相同：
簽名相同：覆蓋舊的同包名apk。簽名不同：新的apk會安裝失敗。【簽名key一般都是不同的】
UserId相同時：
包名不同：
未設定process屬性時，各自的Activity在各自的進程。process屬性指定，則可以共享進程。
包名相同：
簽名相同：覆蓋舊的同包名apk。簽名不同：新的apk會安裝失敗。【簽名key一般都是不同的】