📚 课程目录第1章 APK与AAB概述

第一章：APK与AAB概述

好，咱们直接进入正题。聊Android打包，绕不开两个东西：APK 和 AAB。很多新入行的同学觉得它们就是一回事，不就是安装包嘛。其实差别大了去了。我刚开始做Android开发那会儿，也以为APK就是全部，直到AAB出来的时候，我还纳闷：Google这又是何必呢？

今天这章，咱们就把这两个东西的来龙去脉、设计初衷、以及它们到底要解决什么问题，一次讲透。

1.1 什么是APK？

APK，全称 Android Package Kit。说白了，它就是Android系统的原生安装包。你从各种应用商店、网站下载下来，直接点一下就能装到手机里的那个文件，就是APK。

它的本质是一个压缩包（其实就是ZIP格式），里面包含了你的代码、资源、签名证书等等。

我举个例子，你拿一个APK文件，把后缀改成.zip，然后用解压软件打开，你就能看到里面的东西：

classes.dex：你的Java/Kotlin代码编译后的可执行文件。
resources.arsc：编译后的资源索引表，比如字符串、颜色、布局文件ID。
res/ 和 assets/：各种资源文件，图片、音频、布局文件等。
META-INF/：签名信息和清单文件。
AndroidManifest.xml：应用的配置清单，声明了四大组件、权限、版本号等。

嗯，这里要注意一点。APK是一个“大一统”的包。什么意思？你编译的时候，如果应用里包含了一个320dpi的图片和一个480dpi的图片，APK会把它们都打包进去。不管用户的手机是哪种屏幕，下载时都得把这两个图片的“候选”都下载下来。这就导致了包体体积的膨胀。

个人经验：我早期维护过一个老项目，里面光是为了适配不同分辨率，放了几十张启动图。每次更新，用户都要下载好几MB甚至十几MB的图片资源，其实大部分用户根本用不上。那时候我就想，有没有一种办法，能让用户只下载他们需要的资源？

1.2 什么是AAB？

AAB，全称 Android App Bundle。它不是安装包，准确地说，它是一种“发布格式”。你把AAB上传到Google Play商店，Google Play服务器会帮你做一件事：

它拿到你的AAB，再根据用户的设备特征（比如屏幕密度、CPU架构、语言等），动态地生成一个或者多个针对性的APK，然后分发给用户。

你想想看，这解决了什么问题？用户是中文用户，他就不用下载里面包含的英文、日文、法文字符串资源。用户手机是ARM64架构，他就不用下载里面包含的ARMv7或x86的so库。用户设备是420dpi的屏幕，他就不用下载里面包含的mdpi或hdpi的图片。

说白了，AAB就是“按需定制”。它把你的应用拆成了一个个的“模块”

AAB的文件结构跟APK有点像，但多了几个关键的东西：

base/：核心的基础模块，所有设备都必须包含的部分。
feature/：动态功能模块，可以按需下载，比如一些额外功能、游戏关卡等。
BundleConfig.pb：描述Bundle的元数据。
Bundle-metadata/：包含编译时的一些信息。

它的核心技术叫做 Split APK 机制。嗯，其实在AAB出现之前，Google Play就已经支持Split APK了，但那是给开发者手动配置用的，太复杂。AAB把这一切自动化了。

避坑指南：我曾经接手过一个项目，为了追求极致的包体压缩，手动把so库拆成了多个Split APK。那个配置简直是一场噩梦，各种版本依赖冲突、签名不一致的问题。后来换了AAB，世界清净了。所以个人建议，除非你有特殊渠道分发需求，否则不要手撸Split APK，老老实实用AAB。

1.3 诞生背景与设计目标

为什么会有这两个东西？咱们来梳理一下历史。

维度	APK	AAB
诞生时间	2008年，伴随Android 1.0诞生	2018年，Google I/O大会上正式推出
设计目标	简单、兼容、直接安装。在早期手机存储容量小、网络慢的时代，让应用能快速分发和安装。	减小应用下载体积、优化安装体验、支持动态功能模块。在应用越来越庞大、手机存储和网络不再是瓶颈的时代，解决“一刀切”打包带来的浪费。
核心痛点	包体冗余严重。一个APK里装着所有设备的资源，用户下载了很多用不到的数据。	兼容性。AAB本身不能直接安装，必须依赖Google Play或其他支持App Bundle分发渠道的处理。
举个栗子	就好像你去吃饭，不管你能不能吃辣，店家都给你上一份一模一样的套餐，里面有凉菜、热菜、汤。你吃不完就得浪费。	就像你点外卖，可以选择不加辣、不加葱、不要香菜。老板根据你的要求，只给你做你点的那份，不浪费原材料。

为什么会这样？这要从Android的碎片化说起。早期的Android设备五花八门，屏幕尺寸、CPU架构、语言版本千差万别。当时Google的首要目标是让所有设备都能跑起来Android应用。所以APK的设计哲学就是“全包含”，保证兼容性，牺牲了体积。

到了2018年，情况变了。手机性能过剩，存储空间也大了，但应用本身也膨胀得厉害。动辄上百MB的游戏、包体超过1GB的企鹅应用比比皆是。用户对“下载等待时间”和“存储空间”又变得敏感了。Google意识到，“一刀切”的APK模式已经走到尽头。于是AAB应运而生，它的设计目标是“最小化用户首次下载的包体”，并通过“动态分发”来承载后续功能。

核心对比：

APK：用户侧的安装包。一次性打包，全量分发。
AAB：开发者侧的发布格式。智能分包，按需分发。

记住这个区别，后面所有技术细节都围绕这个核心思想展开。

好了，本章的内容就这些。下面这张图可以帮助你快速理解APK与AAB在整个分发流程中的定位差异。

嗯，我整理完这张图，感觉思路就清楚多了。你想想看，APK的流程是“构建 -> 产物 -> 分发 -> 用户全量下载”；AAB的流程是“构建 -> 产物(AAB) -> Google Play动态拆包 -> 用户按需下载”。这就是两者最本质的区别。