android簽名後的內容共用實現機制

標籤：shareduserid   process   

apk一般佔一個dalvik,一個進程，一個task。task是一個activity的棧，其中"可能"含有來自多個App的activity

分類	APK	Task
工作空間	Dalvik虛擬機器	Activity棧
進程	一個進程中	一個進程中
存在於多個進程中	可以	不可以
存放其它進程的Activty		可以
設定方法	Application下的（簽名相同） Android:sharedUserId=”com.xx” Android:process:”com.aa”	Application下的（簽名相同） Android:sharedUserId=”com.xx” 在Activity下 Android:process:”com.aa”

        預設情況下，同一個應用程式中的所有組件運行在同一個進程中，而且絕大多數的應用程式也都是這樣的。但是，如果我們想要控制讓某個特定的組件屬於某個進程，我們可以在 manifest.xml檔案中進行配置。 

       在每種組件元素（activity、service、receiver、provider）的manifest條目中，都支援一個 “android:process”的屬性，通過這個屬性，我們可以指定某個組件啟動並執行進程。可以通過設定這個屬性，讓每個組件運行在設定的進程中，也可以只讓某些組件共用一個進程。我們要可以通過設定“android:process”屬性，讓不同應用程式中的組件運行在相同的進程中，這些應用程式需要共用相同的Linux使用者ID，擁有相同的認證，很重要的前提。 

        <application>元素也有一個“android:process”屬性，可以設定一個應用於全部組件的預設值。 
       當可用記憶體數量低，而一些與使用者即時互動的進程又需要記憶體時，Android隨時可能會終止某個進程。運行在被終止的進程中的組件會因此被銷毀，主要是Task被銷毀，但是，當再次需要這些組件工作時，就會再啟動一個進程。 
       在決定要終止哪個進程時，Android系統會權衡它們對於使用者的重要性。例如，相較於運行可見activities的進程，終止一個運行不可見activities的進程會更加合理。是否終止一個進程，依賴於運行在這個進程中的組件的狀態。 

       如果不能將兩個activity放入同一個application中的話，可以通過在各自的manifest中設定以下屬性，讓這兩個activity強制運行在同一個進程中，從而可以充分利用進程內共用的資源，減少記憶體佔用：

（1）設定相同的User Id： <manifest android:sharedUserId="com.xx" （2）被調用的activity設定以下屬性： <activity android:multiprocess="true" 或者 <activity android:process="com.aa"

對於3D OpenGL程式，修改以上屬性後，被調用的activity的記憶體佔用會明顯減少，比如：30MB -> 2MB。

<strong>如上證明那個APK共用進程要兩個條件</strong>（1）設定相同的UserId：（2）被調用的activity設定以下屬性：Java代碼 <activity android:multiprocess="true"或者<activity android:process="com.aa"

這裡使用別人已經證實的例子，說明問題。

1.同一Apk中的同一包中的多個Activity調用時進程狀況驗證

[1]建立Project：projectname:FirstProject

package:com.demo

預設Activity:MainActivity

[2]添加一個新的Activity：

name:SecondActivity

[3]修改布局。在MainActivity布局中添加一個Button，當點擊此Button時啟動SecondActivity。在SecondActivity的布局中放置一個Textview，以證明SecondActivity已啟動。
[4]運行程式，查看此App進程情況：

USER：app_36PID：8360NAME：com.demo

[5]點擊按鈕，啟動SecondActivity，再次查看進程情況：

USER：app_36PID：8360NAME：com.demo

結論：進程列表沒有變化，兩個Activity運行在同一進程中。

2.同一Apk中的不同包的Activity調用時進程狀況驗證[1]將SecondActivity挪到包com.demo.second中去，相應修改AndroidManifest.xml中的name為：com.demo.second.SecondActivity
[2]運行程式，查看此時進程情況：

USER：app_36PID：10593NAME：com.demo

[3]點擊按鈕啟動SecondActivity，查看此時進程情況：

USER：app_36PID：10593NAME：com.demo

結論：進程列表沒有變化，兩個Activity運行在同一進程中。即進程name只受AndroidManifest.xml中manifset結點的package屬性影響。

3.同一Apk中Activity process屬性修改後進程狀況驗證[1]為SecondActivity添加process屬性，其值為":abc"，也可以隨便是其他的":"開頭的字串，常見的名字是":remote"：

<activityandroid:name="com.demo.second.SecondActivity"android:process=":abc"></activity>

[2]運行程式，查看進程情況：

USER：app_36PID：12137NAME：com.demo

[3]點擊按鈕，啟動SecondActivity，查看進程情況：

USER：app_36PID：12303NAME：com.demo:abc

結論：進程表多了一項。兩個Activity各自有一個進程，SecondActivity的進程名稱為包名+尾碼。

4.不同Apk中不同包名的Activity進程狀況驗證[1]運行FirstProject：

USER：app_36PID：12137NAME：com.demo

[2]建立SecondProject：projectname:SecondProject

package:com.demo2

預設Activity:MainActivity

[3]運行SecondProject：

USER：app_37PID：14191NAME：com.demo2

結論：進程表多了一項。兩個Activity各自有一個進程，同時其進程使用者id、包名也不同，互不影響。

5.不同Apk，簽名相同、包名相同的Activity進程狀況驗證[1]修改SecondProject的包也為com.demo，相應要修改AndroidManifest.xml內容。
[2]運行SecondProject，查看進程情況：

USER：app_36PID：14944NAME：com.demo

結論：進程表只有一項，但是實際上FirstProject此時已經被覆蓋了，系統中只存在SecondProject了，因為模擬器調試時apk使用的簽名key都是一樣的，系統看到key一樣，包名一樣認為這個包就是FirstProject所以覆蓋掉了。軟體更新過程。
可以通過DDMS複製/data/system/packages.xml查看一下內容:
<packagename="com.demo"codePath="/data/app/com.demo.apk"system="false"ts="1279955425000"version="1"userId="10036">
這個檔案裡面，packagename都是唯一的，同時可以看到使用者名稱是通過userId來決定的。

6.不同Apk，簽名不相同，包名相同的Activity進程狀況驗證[1]在Eclipse的PackageExplorer導航樹中選中FirstProject，點右鍵。
[2]Androidtools-->ExportSignedApplicationPackage，按照嚮導建立一個用指定key簽名的apk包。
[3]同樣匯出SecondProject。
[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，ShareUserId相同，包名不同時進程情況分析[1]修改firstproject、secondproject的AndroidManifest.xml的manifset結點，增加屬性

android:sharedUserId="com.demouser"

[2]修改secondproject的包為com.demo2，不然其會覆蓋firsetproject。
[3]運行firsetproject、secondproject，查看進程列表：

USER：app_35 PID：19993 NAME：com.demo

USER：app_35 PID：20045 NAME：com.demo2

結論:

仍然存在兩個進程。但是進程的使用者名稱一樣，說明shareUserId確實有效了，進程pid不相同。

再次匯出/data/system/packages.xml，查看其內容，可以看到兩個項目的UserId都是10035，確實是一樣的：

<packagename="com.demo"codePath="/data/app/com.demo.apk"system="false"ts="1279957484000"version="1"sharedUserId="10035"><packagename="com.demo2"codePath="/data/app/com.demo2.apk"system="false"ts="1279957473000"version="1"sharedUserId="10035">

8.不同Apk，ShareUserId相同，包名不同、指定Activity的process屬性進程情況分析[1]修改SecondProject的MainActivity的process屬性，指定綁定到進程名為com.demo的進程上：

<activityandroid:name=".MainActivity"android:label="@string/app_name"android:process="com.demo">

[2]運行firstProject、SecondProject，查看進程情況：

USER：app_35PID：21387NAME：com.demo

結論：兩個Activity運行於同一個進程。

9.不同Apk，ShareUserId相同，包名不同、簽名key不同經實驗，安裝第二個apk時會提示INSTALL_FAILED_UPDATE_INCOMPATIBLE錯誤，安裝失敗。
總結：
UserId不同時：

包名不同：

未設定process屬性時，各自的Activity在各自的進程。即使process指定了包名，也不會和另一個使用者的同名套件共用進程。

包名相同：

簽名相同：覆蓋舊的同包名apk。簽名不同：新的apk會安裝失敗。【簽名key一般都是不同的】

UserId相同時：

包名不同：

未設定process屬性時，各自的Activity在各自的進程。process屬性指定，則可以共用進程。

包名相同：

簽名相同：覆蓋舊的同包名apk。簽名不同：新的apk會安裝失敗。【簽名key一般都是不同的】

參考：http://blog.csdn.net/llping2011/article/details/12705121

android簽名後的內容共用實現機制