新的发布格式对 Android 的未来意味着什么

得益于其开放性，Android 在前十年取得了显著的增长和成功。有各种各样的设备可供选择，以及一个由蓬勃发展的开发者生态系统提供的海量应用和游戏，这些应用和游戏让这些设备栩栩如生。作为开发者，您希望确保您的用户获得最佳体验，并且您的应用能在所有这些设备上尽可能好地运行。您还希望鼓励尽可能多的用户安装您的应用；您希望他们继续使用它；您不希望他们因为超出您控制的原因而卸载它。到目前为止，Android 应用的发布和交付方式在所有这些方面都有改进的空间。我想探讨一下开发者面临的一些挑战，并告诉您 Google 正在做什么来提供帮助。

Android 的前 10 年

十年来，在 Android 上发布应用一直是这样的

• 步骤 1：您在 Android Studio 等 IDE 中编写应用的所有代码。
• 步骤 2：当您准备好测试或发布应用时，您可以将其构建为 APK，这是 Android 的应用格式。在构建 APK 的过程中，您需要使用应用签名密钥对其进行数字签名。签名应用意味着为其安全地附加一个唯一的证书。这是一种确保只有您才能继续更新此应用已安装副本的机制。这如何工作？在更新应用之前，Android 始终会检查更新的唯一证书是否与设备上应用的唯一证书匹配。稍后我将详细说明这一点。
• 步骤 3：您将签名的 APK 上传到 Google Play Console 中的一个测试轨道。当您准备好时，您会将应用发布到生产轨道并面向全世界。
• 步骤 4：当用户安装应用时，Google Play 会将您上传的签名 APK 精确地分发到每个用户设备上。

多年来，这一直运作得相当不错。事实上，每月有超过 80 亿的应用从 Google Play 安装！但是，正如您将看到的，这种模式给开发者带来了越来越难以忽视的挑战。

“大”问题

问题是：应用越来越大。事实上，自 2012 年以来，平均应用大小增长了 5 倍。这是可以理解的；您想在应用中添加炫酷的功能和新内容，以吸引用户并促进业务增长。设备不断改进，您想利用这些闪亮的新功能。设备生态系统也变得更加多样化，因此您最终会在应用中复制代码和资源，以使其在小屏幕上与在大屏幕上一样运行良好，在一种 CPU 上与另一种 CPU 上一样运行良好，等等。

如果每个用户都有无限的存储空间、无限的数据和极快的连接，应用变大也不会有太大影响。不幸的是，情况并非如此（也许有一天会！）。查看上面的图表，您可以看到 Google Play 上应用的大小与其安装转化率呈负相关。这意味着随着应用的增大，其安装成功率会下降。这发生的原因有很多。许多用户设备上没有足够的可用空间。这会影响存储空间有限的入门级设备用户，以及那些将照片、视频和其他媒体填满设备的高端设备用户——所有这些媒体的质量都在不断提高，占用了设备上的更多空间。用户也不想耗尽昂贵的数据套餐，并等待慢速连接下载较大的应用，尤其是在新兴市场。

因此，我们知道大型应用的安装率会下降。我们的用户研究还表明，应用大小也是导致卸载的主要动机，这使得它对于专注于留存的应用变得越来越重要。对于专注于留存的应用，这一点越来越重要。想想您自己的经历。当您尝试安装应用时，是否曾收到 Google Play 的警告，提示您卸载不使用的应用以释放空间？每天都有数百万人看到这些警告，他们常常会在面临此选择时卸载最大、最占空间的应用和游戏。Google Photos 拍摄了一个有趣的 广告，展示了这个问题有多普遍。在 Google Play 去年进行的一项用户研究调查中，人们卸载至少使用了一个月的应用和游戏的头号原因是释放空间。

我应该提到，对于我概述的问题，有一个不太理想的解决方案。如今，您可以在一次发布中为每个设备配置构建和版本化多个 APK。如果您想针对屏幕尺寸、CPU 架构（32 位和 64 位）等进行优化，这很快就会变得失控。您最终可能会为每次发布构建数百个 APK。这很麻烦，而且大多数开发人员都不会这样做。许多人只是将所有内容放在一个“巨型”APK 中，而用户最终会在其设备上获得未使用的、重复的内容。而且，即使您使用多 APK，您也无法针对语言进行优化。您必须在每个 APK 中为每个设备包含所有翻译的字符串，即使用户只需要一种或两种语言，这也会浪费更多空间。

因此，您现有的选择并不理想：增加应用的大小，但会冒着转化率下降和卸载率升高的风险；或者使您的发布效率低下且更加痛苦，使用多 APK；或者花费所有时间权衡此功能与彼功能，以避免增加应用的大小。

“小”解决方案

Google 不希望开发人员做出这些妥协，因此我们一直在努力寻找更好的方法。以下是核心思想：如果您将所有所需内容上传到 Google Play，那么 Play 就可以负责为每个用户和设备仅交付所需的内容。这很简单，不是吗？此过程可以减少您支持 Android 多样化生态系统所需的工作量和精力，并使您的应用对用户来说小得多。正如您将在本文稍后发现的那样，这种新模式还有助于改善用户获取过程：从发现和安装，到通过功能和更新吸引和留住用户。

更小的安装

为了实现这一愿景，Google 在今年早些时候推出了新的应用发布格式——Android App Bundle。以下是它的详细工作原理

• 步骤 1：您像往常一样在 Android Studio 等 IDE 或 Unity 等游戏引擎中编写应用的所有代码。
• 步骤 2：现在，当您准备好测试或发布应用时，您可以将其构建为 Android App Bundle，这是 Android 的新应用发布格式。您仍然需要对应用进行签名，以便 Google Play 可以验证它来自您。
• 步骤 3：如果您还没有这样做，请选择由 Google Play 进行应用签名。如果您发布新应用，可以在上传应用时通过单击一次完成此操作。选择后，Play 会将您用于签名应用束的密钥指定为“上传密钥”。此密钥仅用于安全身份验证目的，如果您丢失了它，可以联系 Google 来验证您的身份并重置它。对于现有应用，您需要访问 Play Console 中的应用签名部分，并将您的应用签名密钥转移到 Google Play。您为什么需要这样做？继续执行步骤 4 以了解原因。
• 步骤 4：当您将应用束上传到 Google Play 时，Play 会对其进行处理，并为支持的每种可能的设备配置和语言生成使用应用签名密钥签名的拆分 APK。拆分 APK 是 Android L 中引入的 Android 平台功能。只要每个拆分 APK 都使用相同的密钥签名，Android 平台就会将其视为一个应用。您可以将拆分 APK 视为 APK 的“一部分”：要运行该应用，设备会将所需的“部分”组合成一个“完整”的应用。
• 步骤 5：当用户安装应用时，Play 会向设备提供基础 APK（所有设备通用的代码）、语言拆分 APK（用于用户所说的语言）以及设备配置拆分 APK（包括用于设备屏幕尺寸和 CPU 架构的）。这意味着设备只获取它需要的东西，而不会浪费空间。为了让设备接受更新，每次发布的拆分 APK 必须使用与原始应用安装相同的应用签名密钥进行签名。

这种新模式的结果是应用体积大大减小，下载速度更快，并且占用设备空间更少。您为用户提供了一个更高效的应用，其中不包含他们不会使用的代码和资源。对大多数开发人员来说，切换也非常简单。在 Android Studio 中构建应用束的过程与构建 APK 非常相似。使用 Unity 的游戏开发者也可以在 Unity 的 2018.3 beta 版本及更高版本中构建应用束。Android App Bundle 是开源的，并且向后兼容（对于 L 版本之前的 Android，Play 会为每种设备配置生成一个包含所有语言资源的单个 APK，而不是使用拆分 APK）。

我们切换到应用束，并在不到一个小时的时间内上传了第一个内部版本。Swiggy ▼23%

成千上万的开发人员正在生产环境中使用应用束。使用 Android App Bundle 的开发人员的 APK 大小比发布“通用 APK”（一个包含支持 Android App Bundle 支持的所有设备配置和语言所需内容的所有内容的 APK）时要小约 35%。更重要的是，对于那些必须管理每次发布的人来说，新格式意味着您不再需要使用多 APK。Google Play 会为您处理设备配置优化，让您的生活更轻松。Android App Bundle 将很快开始支持高达 500MB 的应用束，因此在大多数情况下，您无需使用扩展文件。

应用束为我们节省了时间，因为我们不再需要使用多 APK。RedBus ▼22%

新模式和新发布格式的一个好处是，Google Play 可以在 APK 生成过程中引入优化，从而为您节省时间和精力。一个刚刚宣布的例子是支持未压缩的本地库，这是 Android Marshmallow 中引入的一个很少使用的平台功能。使用应用束的开发人员无需额外工作即可获得此功能。

在 Android M 之前，包含在应用中的任何本地库都必须在每个设备上从 APK 中解压缩。这意味着每个设备上都安装了两个库副本：APK 中的压缩副本和未压缩副本。这是浪费空间。从 Android M 开始，库可以直接从 APK 以未压缩的状态读取，从而节省了设备上的一个副本。Play 在下载过程中对 APK 进行压缩通常比压缩 APK 中的本地库更有效，因此总体下载大小也更小。因此，所有应用都将获得此优势，Play 的大小限制正在发生变化，以便它们基于用户下载的压缩 APK 大小，而不是您上传到 Play Console 的应用大小。平均而言，仅此一项优化就将使用本地库的应用的下载大小减少了 8%，设备上的安装大小减少了 16%。这与切换到应用束所带来的优势相比，是一个惊人的尺寸缩减！

包含 20 多个语言的资源在开始使用 Android App Bundle 之前，正在增加我们的应用大小并明显降低我们的访问量到安装转化率。Riafy ▼37%

如前所述，应用必须选择由 Google Play 进行应用签名才能使用应用束。应用签名密钥是一种机制，用于确保在应用安装后，更新始终来自同一开发人员。Google 通过持有此密钥，不会获得开发人员的额外访问权限或身份识别信息。它仅用于为安装和更新签名拆分 APK。Google 非常重视安全，并且拥有一支工程师和先进基础设施团队，利用 Google 用于保护其应用密钥的相同安全密钥存储来保护开发者的密钥。事实上，对于大多数开发者来说，选择由 Google Play 进行应用签名，然后使用上传密钥为每次发布签名（与 Google 持有的应用签名密钥不同）比持有密钥更安全，因为密钥可能会丢失或被泄露。如果您没有选择由 Google Play 进行应用签名，并且丢失了您的应用签名密钥，您将无法更新您的应用，很抱歉，我们对此无能为力。

动态功能

Android App Bundle 中的下一个重要创新是其模块化设计。这意味着您可以向应用添加包含附加应用功能的模块，这些功能可以按需加载。这有助于解决我之前提到的应用变大的另一个主要原因：功能增长。现在，您可以添加更多功能，而不会增加应用安装时的体积。动态功能是一种安全地动态加载 Android 代码的方式，因为动态功能模块的扫描和检查方式与 Google Play Protect 扫描和检查应用本身的方式相同。

任何应用功能都可以包含在动态功能模块中，并按需提供。您以与开发应用相同的方式编码动态功能。适合的特性能包含

• 安装时不需要的大功能：您可以按需加载这些功能，或者告诉 Google Play 延迟安装它们，这意味着在后台安装它们。您可以通过这种方式加载高达 100MB 的功能。在启动时不是应用核心体验的高级功能或附加功能是很好的候选者，例如付费用户的优质功能、个性化选项、AR 功能等。
• 特定受众的功能：您可以通过将功能从应用中拆分出来作为动态功能，而不是包含适用于所有受众的功能。例如，商务应用可以将销售功能隔离在动态功能模块中，这样在安装时只有购买功能会被交付给所有用户。需要销售功能的小部分受众可以在需要时下载并访问它。一些开发人员还将动态功能作为一种避免拥有针对不同受众的多个应用变体的方法。相反，他们可以整合并提供一个应用，同时将针对每个受众的定制功能移至动态功能模块。
• 很少使用的功能：动态功能模块的另一个好用途是用于很少使用或只使用一次的功能。例如，如果您的应用具有一次性 ID 验证或信用卡扫描功能，那么按需加载并在使用后立即将其卸载是避免在安装时增加应用大小的有效方法。它还可以避免占用应用生命周期内不使用的空间的占用（请记住，较大的应用更容易被卸载）。

即时发现

我讨论了 Android App Bundle 如何帮助您保持应用体积小巧，并通过动态功能实现高度可配置的应用。Android App Bundle 还支持即时应用。Google Play Instant 允许用户在安装完整应用或游戏之前，通过 Play 商店中的“立即试用”按钮、广告和链接来试用应用和游戏。Instant 目前已覆盖 1.2B 设备，并且已被证明是推动发现和安装的绝佳方式，它吸引了那些可能不会安装应用的受众。Vimeo 是 许多通过 Google Play Instant 取得成功的合作伙伴之一，据报道，他们的新安装中有 15% 来自其即时体验。

过去，由于独立的构建和发布流程，一些开发人员采用即时应用并不容易。有了 Android App Bundles，您就不必再单独构建和维护即时应用了。切换到应用束后，您可以添加一个模块作为即时应用的入口点，或者，如果您的应用足够小，您可以直接启用您的基础模块为即时应用。您的应用基础模块和即时应用模块的总大小限制为 10MB，以便在 Play 商店和网络横幅上启用“立即试用”按钮。即时应用只能请求 支持的权限。如果您的已安装应用使用其他权限，请在即时应用中妥善处理这些权限，以确保积极的用户体验。

这并不是说让所有应用都低于 10MB 限制都很容易。使用动态功能模块逐步加载功能是 许多方法之一，可以显著减小应用的大小。大小限制仅在将启用即时应用的应用束推送到生产环境时适用，因此您可以在达到大小限制之前进行测试。如果您能够进一步减小基础模块和即时入口模块的大小至 4MB 以下，您就可以激活更多即时表面，例如 Google 搜索以及通过电子邮件或社交媒体共享的任何网络链接。在 Android Studio 3.3 beta 版本中，可以为即时体验和已安装体验构建单个应用束。

更快的更新

我最后想谈的是让您的用户保持最新。吸引和留住用户的最后一步是确保他们拥有所有最新功能和修复。虽然许多 Google Play 用户已开启自动更新，但许多用户没有，还有些用户不会频繁连接到强大的 Wi-Fi 连接来更新所有应用。新的应用内更新 API 将允许您检测是否有可用更新，并集成一个可自定义的、行内更新流程，该流程看起来和感觉都像是您应用的一部分。检测到更新时，您可以向用户显示一个提示，要求他们立即更新，或者在您选择的时间和方式显示一个灵活更新的提示。

立即更新流程专为关键更新而设计，例如安全修复或隐私增强，您希望用户尽快应用这些更新。当用户在您的应用中接受此更新时，它将被下载并应用，然后应用将重新启动。灵活更新更具可定制性。当接受此更新时，它将在后台下载。下载完成后，您可以提示用户重新启动应用，或者可以在应用转到后台时应用。

Google Chrome 今天正在测试应用内更新 API。为了获得良好的更新率，最好向用户清楚地说明更新的好处，并在可能的情况下，在他们完成一项任务后要求他们更新，而不是在他们首次打开应用时要求。当有人首次打开您的应用时，他们通常有原因，并且不希望在应用更新时等待。

更小、更好、更快、更新

这些努力旨在通过更小的应用和更简单的发布来帮助您获得更多安装并减少卸载。Android App Bundle 还支持高度可配置的应用，具有动态功能和即时体验，可以提高转化率。最后，让用户保持应用更新变得越来越容易。切换到 Android App Bundle 非常简单，您可以从 g.co/androidappbundle 开始，还可以阅读 这篇文章 和 Google Play Medium 博客上的 更多内容。祝 Android 生态系统在未来十年继续增长和成功！

如果您对帖子中讨论的任何内容有疑问或评论，请使用 #AskPlayDev 在 Twitter 上与团队联系，我们将从 @GooglePlayDev 回复，我们定期分享有关如何在 Google Play 上取得成功的最新消息和技巧。