一句话总结：
传统的 APK 安装，是“租客自己搬运全套家具”；而现代的 AAB (App Bundle) 模式，则是“开发商（Google Play）根据你的房型，动态生成并配送最合适的精装家具（Split APKs）”。整个过程由系统“总物业” PackageManagerService 统一管理。
第一篇章：“古典时代”——一个“大而全”的 APK 的旅程
这是我们最熟悉的、也是手动安装 APK 时所经历的流程。你的“租客入住”比喻完美地描绘了这一过程。
-
安全检查 (
PackageManagerService)： 系统“物业总管”PMS首先介入，对 APK 进行签名校验，确保“租客”身份合法、未被冒名顶替。 -
信息解析：
PMS解析AndroidManifest.xml，了解“租客”的基本信息（包名、版本）和需求（权限列表）。 -
分配空间：
- 在
/data/app/下为 APK 本身和优化后的代码创建目录。 - 在
/data/data/下为应用未来的数据（数据库、缓存）创建专属“私人储物间”。
- 在
-
代码优化 (AOT 编译)： 系统的
dex2oat进程开始工作，将 APK 中的classes.dex文件进行预编译 (Ahead-of-Time Compilation) ，生成针对当前设备优化的机器码，存入oat目录，这是为了加快 App 的首次启动速度。 -
户籍登记：
PMS将应用的完整信息，写入到系统的“户籍总册”——/data/system/packages.xml文件中。 -
广而告之：
PMS发送ACTION_PACKAGE_ADDED广播，通知Launcher等其他应用：“新邻居来啦！”，Launcher随即生成桌面图标。
这个流程，至今仍然是理解 App 安装基础的基石。
第二篇章：“现代革命”——AAB 与“动态化精装”时代
对于从 Google Play 等现代应用商店安装的应用，流程发生了根本性的改变。
核心变革：从“交付产品”到“交付蓝图”
- 旧模式 (APK): 开发者构建一个包含了所有语言、所有屏幕密度、所有 CPU 架构资源的“巨无霸”安装包。
- 新模式 (AAB): 开发者只构建并上传一个**“蓝图” (App Bundle)**。
Google Play：“云端打包工厂”
当用户点击“安装”时，Google Play 会扮演一个智能工厂的角色：
- 读取设备信息： 获知用户的设备是
xxhdpi屏幕、arm64架构、语言是“中文”。 - 按需打包： 根据“蓝图”(AAB)，动态地生成一个只包含
base模块 +xxhdpi资源 +arm64so 库 +中文语言资源的**“APK 集合” (Split APKs)**。 - 签名与分发： Google Play 使用它的密钥对这个 APK 集合进行签名，并将其下发到用户设备。
结论： AAB 的革命性在于，它将**“打包优化”的责任从“开发者”转移到了“分发平台”**，为每个用户提供了极致精简、量身定制的安装体验。
第三篇章：持续进化的“性能调优”——PGO
安装时的 AOT 编译只是“前菜”。现代 ART 虚拟机还有更智能的“主菜”——PGO (Profile-Guided Optimization) 。
- 性能监控： ART 运行时会“默默观察”用户最常使用哪些功能、哪些代码路径被执行得最频繁，并生成一份“性能剖析文件”。
- 后台深度优化： 当手机处于充电、Wi-Fi 连接且空闲的状态时，系统会启动后台优化任务，根据这份“性能剖析文件”，对那些“热点代码”进行更彻底、更激进的 AOT 编译。
这意味着，你的应用在用户手机上，是“越用越快”的。
四、总结：安装流程的演进
| 维度 | “古典时代” (手动安装 APK) | “现代时代” (通过 Play Store 安装 AAB) |
|---|---|---|
| 开发者交付物 | 大而全的通用 APK | 轻量级的 AAB 蓝图 |
| 最终安装物 | 单个 base.apk | 一组 Split APKs (base + config_xx.apk) |
| 优化责任方 | 开发者 (需手动打多渠道包) | Google Play (云端按需生成) |
| 代码优化 | 安装时 AOT | 安装时 AOT + 运行时 PGO 持续优化 |
| 核心管理者 | PackageManagerService (PMS) | PackageManagerService (PMS) |
理解从 APK 到 AAB 的演进，以及从 AOT 到 PGO 的深化，才能真正把握现代 Android 应用**“分发即优化”和“持续自优化”**的精髓。
