PackageManagerService 作为及其重要的系统服务，在系统启动的时候就会启动，PMS 在应用开发中为我们提供了很多获取系统中应用信息的方法，如下所示，那么这些跟应用相关的信息是什么时候放入 PMS 的，PMS 又是如何工作的，下面就来一一探究。
首先说明 PMS 作为一个系统进程中的服务，是不能直接跟应用进程进行交互的，所以在应用中通过 Context 对象的 getPackageManager 方法返回的其实是 PMS 在应用进程的远程代理，整个过程通过 Binder 机制实现，如果不了解 Binder 的请出门左转，前几天有专门文章来解释 Bindler 和代理模式
一、PackageManager 常用方法
首先来看 PM 的一些常用方法，这些方法大多都是通过 PMS 实现的噢,PMS 的作用主要为管理应用程序包
- 获取方式 Context 对象的 getPackageManager 方法的返回值
- 作用：可以与已经安装的程序相关 package 的信息
- getApplicationInfo 以 ApplicationInfo 方式返回指定包名的 ApplicationInfo
- getApplicationIcon
- getInstalledApplications
- getInstalledPackages
- queryIntentActivities 返回指定 Intent 的 ResolveInfo 对象，Activity集合
- queryIntentService 返回指定 Intent 的 ResolveInfo 对象，Service集合
- resolveActivity 返回指定的 Activity
- resolveService 返回指定的 Service
- 可以根据 ApplicationInfo 中的 flag 值判断应用的类型，具体如下
- FLAG_SYSTEM 系统应用
- FLAG_UPDATED_SYSTEM_APP 系统应用升级
…
这么多方法，获取到的还是这么重要的信息，那么 PMS 中是如何得到这信息这就是今天的重点，也是 PMS 的工作重点，那就是 APP 信息表的构建过程。下面具体来看
二、App 信息表的构建
系统启动之后就会注册各种系统服务，如 WindowManagerService、ActivityManagerService、PackageManagerService ，今天我们使用到的是 PackageManagerService ，简称 PMS 。
PMS 的构造函数中就开始解析工作了
- 加载 FramWork 资源
- 加载核心库
- 扫描指定目录下的 apk 文件进行解析并将解析到的信息进行存储
PMS 启动之后，会扫描系统中已安装的 APK 目录，包括系统 APP 的安装目录 /sysytem/app, 第三方应用的目录 /data/app ，PMS 会解析 apk 包下的 AndroidManifest.xml 文件得到 App 的相关信息，而每个 AndroidManifest.xml 又包含了 Activity，Service 等组件的注册信息，当 PMS 扫描并解析完这些信息之后就建立好了整个 apk 的信息树。今天的主题就是这些信息的解析和存储过程
PMS 解析 apk 信息的过程
scanDirLI 函数使用 for 循环遍历指定目录下的所有文件，解析其中 apk 类型的文件，忽略其他文件。解析方法为 scanPackageLI
scanPackageLI 首先构造一个 PackageParser 也就是一个 apk 包解析器，调用其 parsePackage 方法，其中会判断路径文件的类型，如果是文件夹类型会解析文件夹中的 apk 文件，如果是 apk 文件，直接解析调用 parseMonolithicPackage 方法解析得到 Package 对象
最后将 Package 中解析到的 activities 等列表中的数据添加到 PMS 中的对应列表中
PackageParser 的 parseMonolithicPackage 方法，解析 AndroidManifest.xml 文件得到 Package 对象
- 构建 AssetManager
- 根据 AssetManager 构建 Resources 资源
- 调用 AssetManager 对象的 openXmlResourceParser 获取 AndroidManifest.xml 解析器 XmlResourceParser 对象
- 由 parseBaseApk 方法根据解析器、Resources 资源等得到 Package 对象
- 将 Package 返回
parseBaseApk 方法，主要任务是真正的解析 AndroidManifest ，采用 Pull 解析的方式，主要有两个节点， Application 和 user-permission ，Application 节点时会调用 parseBaseApplication 方法
parseBaseApplication方法，解析 Application 标签中的信息，返回 Package 对象
- 解析获取应用名、应用图片以及 Application 标签中设置的其他属性
- 迭代 Application 元素的所有子元素，Activity，Service、Provider、Receiver 等标签，通过 parseActivity 等方法返回相应的实例
- 将解析到 Activity，Service、Provider、Receiver 实例对象添加到 Parkage 对象的 activities 等列表中
- 返回 Parkage 对象
scanPackageLI 方法的最后调用 scanPackageDirtyLI 方法
将 Package 中解析到的 activities 等列表中的数据添加到 PMS 中的对应列表中，PMS 中的这些列表都是静态的，在类初始化时就会实例化。
上面的解析过程就讲应用相关的信息做了解析和保存，以便在我们使用时直接获取。还有我们最常用的启动 Activity、Service 等系统组件时 PMS 负责根据 Intent 来匹配具体启动那个组件，下面就已启动 Activity 为例，看一下 PMS 对 Intent 的匹配过程。
匹配过程
startActivity 方法最终会调用 startActivityForResult
startActivityForResult 中直接调用 Instrumentation 的 execStartActivity 方法
通过 ActivityManagerNative.getDefault 方法得到 AMS ，调用 AMS 的 startActivity 方法
AMS 的 startActivity 方法中有一步会调用 PMS 的 resolveIntent 方法，该方法调用了 PMS 自身的 queryIntentActivites 方法，返回一个 ActivityInfo 对象列表，记录了符合 Intent 的 ActivityInfo，每个 ActivityInfo 对应一个 Activity
queryIntentActivites 方法中先获取 Intent 的 ComponentName ，不为空则根据 ComponentName 直接获取 ActivityInfo，精确跳转情况，也就是显示的启动
ComponentName 为空，说明是隐式 Intent ，查看 Intent 是否指定了要跳转到的目标组件的包名，如果指定了包名则通过包名进行匹配。如果没有指定包名则通过 Action 、Category 等信息模糊匹配 PMS 中存储的 Activity 列表中的内容。将匹配到的 ActivityInfo 列表返回
如果精确跳转情况，则直接启动，如果是模糊匹配则弹出选择窗口。
跳转的过程是由 AMS 完成的
总结
系统启动时 PMS 启动，PMS 解析已安装的应用信息
通过 Intent 启动时，根据 Intent 中的信息在 PMS 中查找对应组件，启动对应组件
APP 信息表的构建以及在启动系统组件时 Intent 的匹配就是我们在应用开发中使用 PMS 较多的地方，了解 PMS 的工作过程也更有利于我们了解 Android 系统架构
