随着我们越来越接近稳定的 Android 12 版本，谷歌正在对 Android 设备上的应用程序交付和分发进行一些根本性的改变。 从 2021 年 8 月起，Play 商店中的所有新应用都将以 Android App Bundle (.aab) 格式发布，而不是现有的 APK 格式。 那么 APK 和 Android App Bundle (AAB) 之间的主要区别是什么？ 我们可以像 APK 一样安装 AAB 吗？ 为了回答您的所有问题，大眼仔旭（www.dayanzai.me）为您提供了有关 APK 与 AAB 的详细指南。 因此，不要浪费任何时间，让我们直接进入。

APK vs AAB

APK 与 AAB：综合比较

在这里，我们用通俗的语言解释了 AAB 和 APK 格式，以便任何人都可以轻松理解这个概念。 我们还详细介绍了如何安装 AAB 文件、从 AAB 中提取 APK 等。

APK 与 AAB：了解基础知识

首先，我们需要掌握一些基础知识，才能正确理解 APK 和 Android App Bundle 之间的区别。

APK 自成立以来一直是 Android 上的首选分发应用程序包。 一个 APK 主要由应用代码、图片、音频等大量资源和开发者生成的应用签名密钥组成。 请注意，Android 设备具有各种外形和规格。 例如，设备可以具有不同程度的屏幕密度（320dpi、480dpi 等）、处理器类型（ARM、ARM64、x86）等。 此外，根据用户所在的地区，应用程序需要有一个语言包（en、fr、ger 等）。

在理想情况下，开发人员必须根据用户的地区、处理器类型和屏幕密度在 Play 商店中构建和上传多个 APK。当用户点击 Play 商店中的“安装”按钮时，正确且最适合的 APK 就会安装在他们的设备上。然而，所有这一切都让开发人员面临着巨大的任务。他们不仅要开发应用程序，还要管理多个 APK 以支持大量设备。

为避免这种复杂且耗时的工作，大多数开发人员会构建一个随附所有资源（语言包、代码等）的通用 APK，即使您在特定设备上可能不需要其中的大部分资源。这会导致体积庞大的 APK 具有更大的应用程序大小，需要更长的安装时间并占用更多带宽。

谷歌希望通过 Android App Bundles (AAB) 解决这个问题，并为开发者承担大部分负担。反过来，这将有助于减少应用程序大小、安装时间和带宽消耗。该公司在 2018 年 Google I/O 大会上推出了 AAB，而现在，将近两年后，Google 要求您必须在 Play 商店以 AAB 格式提交新应用程序。

与 APK 相比，AAB 格式并不是一个全新的分发包。 实际上，AAB 是一个容器，它托管一个基本 APK 和多个拆分 APK。 基本上，AAB 是开发人员提交给 Play 商店的发布格式，而 APK 是您在设备上安装的 Android 应用程序的打包格式。

那么这里到底发生了什么变化呢？ 从 2021 年 8 月开始，开发人员不必为各种设备处理和管理一大堆 APK。 使用 AAB，开发人员将一切都交给 Google——应用程序代码、资产、大量资源、所有语言包，最重要的是，私有应用程序签名密钥。 现在，Google 可以根据用户的设备配置生成优化的 APK 并将其提供给用户。 它可以创建一个更小的 AAB 包，一个体积小，安装很快，并且为低端设备消耗更少的数据。 这是 AAB 与 APK 的主要主张，但还有更多内容需要解开。

与 Google 共享私钥

看看 AAB 带来了什么，它似乎是 APK 的绝佳替代品。 AAB 格式减少了应用程序的大小，开发人员不必构建多个 APK。但是，许多开发人员对与 Google 共享私人签名密钥表示担忧。

正如我上面提到的，签名密钥是验证 APK 完整性的最重要信息。即使您从第三方来源旁加载 APK，Google Play 商店也会检查签名密钥以确定没有任何内容被篡改。

对于 AAB，Google 要求开发人员必须共享私有签名密钥，以便 Google 可以生成应用程序包并使用相同的私有密钥签署 AAB。当用户安装应用程序或更新到新版本时，Play 服务将匹配签名密钥，并且安装将在没有密钥不匹配或签名失败问题的情况下进行。话虽如此，开发人员表示它可能为代码注入打开了大门。谷歌表示，所有“签名密钥都存储在谷歌用来存储自己的密钥的同一基础设施上。”所以请放心，您所有的私人签名密钥都受到铁定的安全保护。

此外，为了缓解开发人员的担忧，谷歌宣布了代码透明，允许开发人员生成一个单独的私钥，只有他们才能访问。 然后，开发人员可以从单独的私钥创建一个额外的签名，用于验证应用程序的完整性。 但是，这种方法有一个限制。 代码透明度仅处理代码，而不处理资产、资源或清单。 此外，这是一项可选功能，可能会让许多开发人员望而却步。

AAB 会让第三方应用商店的事情变得更难吗？

与谷歌共享私钥产生的另一个问题是，它可能会让第三方应用商店的事情变得更加困难。 例如，如果您从 Play 商店安装一个应用程序，但想要从另一个 Play 商店替代品（例如 Amazon App Store 或 Aptoide Store）更新到最新版本，则安装可能会因签名不匹配而失败。

这是因为 Google 现在正在管理私有签名密钥，因此您不能在将应用程序上传到第三方 Android 应用程序商店时使用相同的密钥。 您将不得不使用另一个私钥，这将导致私钥不匹配错误。 对于 Windows 11 上的 Android 应用程序支持，这会是一个问题吗？ 我们将不得不等待并找出答案。

除此之外，AAB 会阻碍开发者将 APK 上传到第三方应用商店的假设似乎是错误的。谷歌已经开发了一个名为 bundletool 的开源工具，允许开发人员从 AAB 包中创建 APK。目前唯一的问题是私有签名密钥的共享会影响 Android 高级用户。

我们可以像 APK 一样安装 AAB 吗？

据我们所知，在 Android 设备上侧载 AAB 似乎是可能的，但它不会像侧载 APK 那样方便。 Android 的包安装程序目前不支持 AAB 打包格式，这意味着无法在本地安装 AAB。但是，您可以使用第三方安装程序应用在设备上安装 AAB 包。

例如，目前，APKMirror 安装程序（免费，提供应用内购买）允许您使用其安装程序应用安装 APKM 捆绑包（基本 APK + 拆分 APK）。

除此之外，您将无法通过 adb 旁加载安装 AAB。您必须使用开源 bundletool 来获取与您的设备兼容的正确 APK。随着 AAB 变得更加主流，可能会出现新的、方便的旁加载方法。请记住，仅旁加载 Base APK 会在您的设备上崩溃。

APK vs AAB：优点和缺点

在完成所有要点之后，您可以看出 AAB 不会对大多数用户的用户体验产生太大影响。是的，它会减少应用程序的大小，这对大多数用户都有帮助。例如，Airbnb 在从 APK 切换到 AAB 后将其应用程序大小减少了 22%，而 Netflix 将其应用程序大小减少了 57%。这是应用程序大小的显着差异。除此之外，废弃的即时应用功能将在 Android 设备上通过 AAB 获得新的生命。

然而，对于想要侧载 AAB 的高级用户来说，事情会变得有点棘手和不方便。您可能需要使用 bundletool 为您的设备提取 APK 或使用第三方安装程序。需要注意的一件事是，AAB 将远离 OBB（不透明二进制 blob）以下载大型资产和资源。相反，它将使用 Play Asset Delivery 或 Play Feature Delivery 来下载下载大小为 150MB 或更大的大量资源。我们将不得不看看这如何影响诸如 Battlegrounds Mobile India、PUBG Mobile、FAU-G 等侧载游戏。

对于受此更改影响最大的开发人员，他们不需要重构他们的代码，这很好。 AAB 还带来了模块化，这意味着它们可以更改代码片段并将其与核心库合并，而不会面临许多合并冲突。 AAB 的一大优势是它为开发人员带来了自定义选项。他们可以选择要定位的 API 级别或要支持的设备类型。开发人员还可以决定在运行最低 SDK 版本的特定设备类型或智能手机上提供哪些所有功能。

至于缺点，问题的核心是共享私钥，现在将由谷歌管理。与第三方应用商店的不兼容可能是另一个大问题，开发人员将不得不加倍努力在其他应用商店上发布和管理 APK（就像现在的 Play 商店）。

APK vs AAB（Android App Bundles）：你怎么看？

对我来说，这种变化最大的问题是过度依赖谷歌。从托管应用程序到管理私钥，Google 现在控制着 Android 上应用程序发布和分发的所有方面。开发人员可能对新变化感到满意，因为他们不再需要管理多个 APK，但从长远来看，它对用户来说会怎样？我们还不知道。开发者把控制权交给谷歌，会带来好的改变吗？我们将不得不拭目以待。无论如何，这一切都来自我们。但是请在下面的评论部分告诉我们您对 APK 与 AAB 辩论的看法。