PMS及App安装过程
PMS,全称PackageManagerService,是用来获取Apk包的信息的。
在前面分析四大组件与AMS通信的时候,我们介绍过,AMS总是会使用PMS加载包的信息,将其封装在LoadedApk这个类对象中,然后我们就可以从中取出在manifest声明的四大组件信息了。
(一)
在下载并安装App的过程,会把Apk存放在data/app目录下。
Apk是一个zip压缩包,在文件头会记录压缩包的大小,所以后续在文件尾巴就算是追加一部小电影,也不会对解压造成影响——木马其实就是这个思路,在可执行文件exe尾巴上挂一个木马病毒,执行exe的同时也会执行这个木马,然后你就中招了。
我们可以把木马思想运用在Android多渠道打包上。在比较老的Android 4.4版本中,我们会在Apk尾巴上追加几个字节,来标记Apk的渠道。Apk启动的时候,从apk中的尾巴上读取这个渠道值。
后来Google也发现这个安全漏洞了,在新版本的系统中,就会在Apk安装的时候,检查Apk的实际大小,看这个值与Apk的头部记录的压缩包大小,是否相等,不相等就会报错说安装失败。
(二)
我们继续说App的安装过程。Android系统使用PMS解析这个Apk中的manifest文件,包括:
四大组件的信息,比如说,前面讲过的静态Receiver。比如说默认启动的Activity。
分配用户Id和用户组Id。用户Id是唯一的,因为Android是一个Linux系统。用户组Id指的是各种权限,每个权限都在一个用户组中,比如读写SD卡,比如网络访问,分配了哪些用户组Id,就拥有了哪些权限。
3)在Launcher生成一个icon,icon中保存着默认启动的Activity的信息。
4)App安装过程的最后,是把上面这些信息记录在一个xml文件中,以备下次安装时再次使用。
(三)
其实,在Android手机系统每次启动的时候,都会使用PMS,把Android系统中的所有Apk都安装一遍,一共4个步骤,如下所示:
![](http://images2015.cnblogs.com/blog/13430/201705/13430-20170526223853482-683221082.png)
其中的第3步、第4步,和单独安装一个App的步骤是一样的。我们分析一下前两步:
第1步,因为结束安装的时候,都会把安装信息保存在xml文件中,所以Android系统再次启动时,再次重新安装所有的Apk,就可以直接读取之前保存的xml文件了。
第2步,从5个目录中读取并安装所有的apk。
最后,回答前面提及的一个问题,为什么App安装时,不把它解压呢?直接从解压文件中读取资源文件比如图片是不是更快呢?其实并不是这样的,这部分逻辑需要到底层C++的代码去寻找,我没有具体看过,只是道听途说问过Lody,他是这么给我解释的:
每次从apk中读取资源,并不是先解压再找图片资源,而是解析Apk中的Resource.arsc文件,这个文件中存储着资源的所有信息,包括资源在Apk中的地址、大小等等,按图索骥,从这个文件中快速找到相应的资源文件。这是一种很高效的算法。
不解压Apk的好处,自然是节省空间
**附录**:
应用程序的完整安装过程图
![](https://box.kancloud.cn/361c74acb0fc44c590c3a2d8134b5873_2764x5616.jpg)
- 前言
- Android 热补丁技术——资源的热修复
- 插件化系列详解
- Dex分包——MultiDex
- Google官网——配置方法数超过 64K 的应用
- IMOOC热修复与插件化笔记
- 第1章 class文件与dex文件解析
- Class文件解析
- dex文件解析
- class与dex对比
- 第2章 虚拟机深入讲解
- 第3章 ClassLoader原理讲解
- 类的加载过程
- ClassLoade源码分析
- Android中的动态加载
- 第4章 热修复简单讲解
- 第5章 热修复AndFix详解
- 第6章 热修复Tinker详解及两种方式接入
- 第7章 引入热修复后代码及版本管理
- 第8章 插件化原理深入讲解
- 第9章 使用Small完成插件化
- 第10章 使用Atlas完成插件化
- 第11章 课程整体总结
- DN学院热修复插件化笔录
- 插件化
- 热修复
- Android APP开发应掌握的底层知识
- 概述
- Binder
- AIDL
- AMS
- Activity的启动和通信原理
- App启动流程第2篇
- App内部的页面跳转
- Context家族史
- Service
- BroadcastReceiver
- ContentProvider
- PMS及App安装过程