android基础部分再学习---Android中的APK,TASK,PROCESS,USERID之间的关系 UID和PID
2016-04-04 22:56
573 查看
参考地址:http://www.cnblogs.com/perseus/articles/2354173.html
PID:为Process Identifier, PID就是各进程的身份标识,程序一运行系统就会自动分配给进程一个独一无二的PID。进程中止后PID被系统回收,可能会被继续分配给新运行的程序,但是在android系统中一般不会把已经kill掉的进程ID重新分配给新的进程,新产生进程的进程号,一般比产生之前所有的进程号都要大。
UID:一般理解为User Identifier,UID在linux中就是用户的ID,表明时哪个用户运行了这个程序,主要用于权限的管理。
在android 中又有所不同,因为android为单用户系统,这时UID 便被赋予了新的使命,数据共享,为了实现数据共享,android为每个应用几乎都分配了不同的UID,不像传统的linux,每个用户相同就为之分配相同的UID。(当然这也就表明了一个问题,android只能时单用户系统,在设计之初就被他们的工程师给阉割了多用户),使之成了数据共享的工具。
因此在android中PID,和UID都是用来识别应用程序的身份的,但UID是为了不同的程序来使用共享的数据。
在android 中要通过UID共享数据只需在程序a,b中的menifest配置即可,具体如下:
这样我们就可以在a程序中通过跳转activity的形式访问b中的数据了。
这样的话你也许会有疑问,如果让其他的开发这知道了我们的shareUserId知道了我们的ID,那我们的数据不是暴露了,放心吧google不会犯这样的低级错误的,我们要使不同的程序能够相互访问,还需要拥有相同的签名,每个公司或者开发者的签名是唯一的,这样我们就不用担心了,另外两者能够访问,别忘了权限
http://blog.csdn.net/jiangwei0910410003/article/details/19975283
apk一般占一个dalvik,一个进程,一个task。当然通过通过设置也可以多个进程,占多个task。
task是一个activity的栈,其中"可能"含有来自多个App的activity
默认情况下,同一个应用程序中的所有组件运行在同一个进程中(即默认运行在同一个进程中的一个线程中),
而且绝大多数的应用程序也都是这样的。
但是,如果我们想要控制让某个特定的组件属于某个进程,我们可以在manifest文件中进行配置。
在每种组件元素(activity、service、receiver、provider)的manifest条目中,都支持一个 “android:process”的属性,
通过这个属性,我们可以指定某个组件运行的进程。
我们可以通过设置这个属性,让每个组件运行在它自己的进程中,也可以只让某些组件共享一个进程。
我们要可以通过设置“android:process”属性,让不同应用程序中的组件运行在相同的进程中,这些应用程序共享相同的Linux用户ID,拥有相同的证书。
<application>元素也有一个“android:process”属性,可以设置一个应用于全部组件的默认值。
当可用内存数量低,而一些与用户即时交互的进程又需要内存时,Android随时可能会终止某个进程。
运行在被终止的进程中的组件会因此被销毁,但是,当再次需要这些组件工作时,就会再启动一个进程。
在决定要终止哪个进程时,Android系统会权衡它们对于用户的重要性。
例如,相较于运行可见activities的进程,终止一个运行不可见activities的进程会更加合理。
是否终止一个进程,依赖于运行在这个进程中的组件的状态。
如果不能将两个activity放入同一个application中的话,可以通过在各自的manifest中设置以下属性,让这两个activity强制运行在同一个进程中,从而可以充分利用进程内共享的资源,减少内存占用:
Java代码
(1)设置相同的User Id:
<manifest android:sharedUserId="aaa.bbb"
(2)被调用的activity设置以下属性:
<activity android:multiprocess="true"
或者
<activity android:process="com.cienet.test"
对于3D OpenGL程序,修改以上属性后,被调用的activity的内存占用会明显减少,比如:30MB -> 2MB。
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 android:name="com.demo.second.SecondActivity" android:process=":abc"> </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="com.demo" codePath="/data/app/com.demo.apk" system="false" ts="1279955425000"version="1" userId="10036">
这个文件里面,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结点,增加属性
android:sharedUserId="com.demouser"
[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.demo" codePath="/data/app/com.demo.apk" system="false" ts="1279957484000"version="1" sharedUserId="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的进程上:
<activity android:name=".MainActivity" android:label="@string/app_name" android: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一般都是不同的】
PID:为Process Identifier, PID就是各进程的身份标识,程序一运行系统就会自动分配给进程一个独一无二的PID。进程中止后PID被系统回收,可能会被继续分配给新运行的程序,但是在android系统中一般不会把已经kill掉的进程ID重新分配给新的进程,新产生进程的进程号,一般比产生之前所有的进程号都要大。
UID:一般理解为User Identifier,UID在linux中就是用户的ID,表明时哪个用户运行了这个程序,主要用于权限的管理。
在android 中又有所不同,因为android为单用户系统,这时UID 便被赋予了新的使命,数据共享,为了实现数据共享,android为每个应用几乎都分配了不同的UID,不像传统的linux,每个用户相同就为之分配相同的UID。(当然这也就表明了一个问题,android只能时单用户系统,在设计之初就被他们的工程师给阉割了多用户),使之成了数据共享的工具。
因此在android中PID,和UID都是用来识别应用程序的身份的,但UID是为了不同的程序来使用共享的数据。
在android 中要通过UID共享数据只需在程序a,b中的menifest配置即可,具体如下:
<manifest xmlns:android="http://schemas.android.com/apk/res/android" package="com.perseus.a" android:versionCode="1" android:versionName="1.0" android:sharedUserId="com.share" >
<manifest xmlns:android="http://schemas.android.com/apk/res/android" package="com.perseus.b" android:versionCode="1" android:versionName="1.0" android:sharedUserId="com.share" >
这样我们就可以在a程序中通过跳转activity的形式访问b中的数据了。
这样的话你也许会有疑问,如果让其他的开发这知道了我们的shareUserId知道了我们的ID,那我们的数据不是暴露了,放心吧google不会犯这样的低级错误的,我们要使不同的程序能够相互访问,还需要拥有相同的签名,每个公司或者开发者的签名是唯一的,这样我们就不用担心了,另外两者能够访问,别忘了权限
http://blog.csdn.net/jiangwei0910410003/article/details/19975283
apk一般占一个dalvik,一个进程,一个task。当然通过通过设置也可以多个进程,占多个task。
task是一个activity的栈,其中"可能"含有来自多个App的activity
默认情况下,同一个应用程序中的所有组件运行在同一个进程中(即默认运行在同一个进程中的一个线程中),
而且绝大多数的应用程序也都是这样的。
但是,如果我们想要控制让某个特定的组件属于某个进程,我们可以在manifest文件中进行配置。
在每种组件元素(activity、service、receiver、provider)的manifest条目中,都支持一个 “android:process”的属性,
通过这个属性,我们可以指定某个组件运行的进程。
我们可以通过设置这个属性,让每个组件运行在它自己的进程中,也可以只让某些组件共享一个进程。
我们要可以通过设置“android:process”属性,让不同应用程序中的组件运行在相同的进程中,这些应用程序共享相同的Linux用户ID,拥有相同的证书。
<application>元素也有一个“android:process”属性,可以设置一个应用于全部组件的默认值。
当可用内存数量低,而一些与用户即时交互的进程又需要内存时,Android随时可能会终止某个进程。
运行在被终止的进程中的组件会因此被销毁,但是,当再次需要这些组件工作时,就会再启动一个进程。
在决定要终止哪个进程时,Android系统会权衡它们对于用户的重要性。
例如,相较于运行可见activities的进程,终止一个运行不可见activities的进程会更加合理。
是否终止一个进程,依赖于运行在这个进程中的组件的状态。
如果不能将两个activity放入同一个application中的话,可以通过在各自的manifest中设置以下属性,让这两个activity强制运行在同一个进程中,从而可以充分利用进程内共享的资源,减少内存占用:
Java代码
(1)设置相同的User Id:
<manifest android:sharedUserId="aaa.bbb"
(2)被调用的activity设置以下属性:
<activity android:multiprocess="true"
或者
<activity android:process="com.cienet.test"
对于3D OpenGL程序,修改以上属性后,被调用的activity的内存占用会明显减少,比如:30MB -> 2MB。
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 android:name="com.demo.second.SecondActivity" android:process=":abc"> </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="com.demo" codePath="/data/app/com.demo.apk" system="false" ts="1279955425000"version="1" userId="10036">
这个文件里面,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结点,增加属性
android:sharedUserId="com.demouser"
[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.demo" codePath="/data/app/com.demo.apk" system="false" ts="1279957484000"version="1" sharedUserId="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的进程上:
<activity android:name=".MainActivity" android:label="@string/app_name" android: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一般都是不同的】
相关文章推荐
- zookeeper3.4.6的可视化zkui2.0的安装
- 给easyui tree树加图标
- 设计模式之创造者模式 Builder
- 典型的错误码和错误信息匹配代码------本质就是key value匹配
- 【FLUENT案例】04:利用DDPM+DEM模拟鼓泡流化床
- 【FLUENT案例】03:冲蚀
- java之GUI文件对话框javax.swing.JFileChooser
- 【FLUENT案例】02:DPM模型
- 【FLUENT案例】01:T型管混合器中的流动与传热
- java中线程队列BlockingQueue的用法
- 【转载】gcc configure: error: Building GCC requires GMP 4.2+, MPFR 2.3.1+ and MPC 0.8.0
- request.getParameterMap()
- Microsoft Build 2016 Day 2
- Vulkan Device and Queue --2
- iOS开发学习笔记——页面滚动(UIPageControl)、(时间)选择器(UIPicker)
- request.getHeader("referer")的作用
- UE4:ICU data directory was not discovered
- codeforces_598B. Queries on a String
- hdu 1242 Rescue bfs+优先队列 解题报告
- UE4 技巧总结