android签名后的内容共享实现机制

标签：shareduserid   process   

       在每种组件元素（activity、service、receiver、provider）的manifest条目中，都支持一个 “android:process”的属性，通过这个属性，我们可以指定某个组件运行的进程。可以通过设置这个属性，让每个组件运行在设置的进程中，也可以只让某些组件共享一个进程。我们要可以通过设置“android:process”属性，让不同应用程序中的组件运行在相同的进程中，这些应用程序需要共享相同的Linux用户ID，拥有相同的证书，很重要的前提。 

       如果不能将两个activity放入同一个application中的话，可以通过在各自的manifest中设置以下属性，让这两个activity强制运行在同一个进程中，从而可以充分利用进程内共享的资源，减少内存占用：

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

<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调用时进程状况验证

USER：app_36PID：10593NAME：com.demo

[3]点击按钮启动SecondActivity，查看此时进程情况：

USER：app_36PID：10593NAME：com.demo

结论：进程列表没有变化，两个Activity运行在同一进程中。即进程name只受AndroidManifest.xml中manifset结点的package属性影响。

3.同一Apk中Activity process属性修改后进程状况验证

<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进程状况验证

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进程状况验证

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>默认的Apk其安装时会分配新的UserId，即此时FirstProject以及SecondProject的UserId可以认为是不同的。

2>包名不同，则签名key是否相同无所谓，两个apk都可以安装。【第4个实验】

3>包名相同时，签名key相同则会覆盖【第5个实验】；签名不同则第二个apk安装会失败。【第6个实验】

7.不同Apk，ShareUserId相同，包名不同时进程情况分析

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属性进程情况分析

<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不同

包名不同：

未设定process属性时，各自的Activity在各自的进程。即使process指定了包名，也不会和另一个用户的同名包共享进程。

包名相同：

签名相同：覆盖旧的同包名apk。签名不同：新的apk会安装失败。【签名key一般都是不同的】

包名不同：

未设定process属性时，各自的Activity在各自的进程。process属性指定，则可以共享进程。

包名相同：

签名相同：覆盖旧的同包名apk。签名不同：新的apk会安装失败。【签名key一般都是不同的】

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

android签名后的内容共享实现机制

标签：shareduserid   process   

原文地址：http://blog.csdn.net/feiyangxiaomi/article/details/41623879