作者 / Dom Elliott, 产品经理, Google Play

由于其开放性，Android 在其前十年取得了显著的增长。有大量的设备可供选择，蓬勃发展的开发者生态系统提供了许多应用和游戏，为这些设备赋予了长久的生命力。作为开发者，您希望确保用户尽可能获得最佳体验，并确保您的应用尽可能在所有这些设备上运行。您还希望尽可能多的用户安装您的应用; 您也希望他们持续使用它; 并且您不希望他们因您无法控制的原因卸载您的应用。到目前为止，Android 应用的发布和分发方式在所有这些方面都有待改进。我想观察一下开发者面临的一些挑战，并告诉您 Google 正在采取哪些措施来提供帮助。

回首 Android 的第一个十年

十年来，在 Android 上发布应用的流程如下：

   第 1 步：在 IDE 中为您的应用编写代码，例如 Android Studio。

   第 2 步：当您准备好测试或发布应用时，您可以将其构建为 APK，也就是 Android 的应用格式。作为构建 APK 的一部分，您可以使用应用签名密钥对其进行数字签名。为应用签名意味着安全地为其添加唯一证书。这种机制可以确保您是唯一可以继续更新此应用的人。这种机制是这么工作的：在更新应用之前，Android 始终会检查更新的证书是否与设备上应用的证书相匹配。稍后我会详细阐明为什么我要讲这些。

    第 3 步：使用 Google Play Console 将已签名的 APK 上传到测试轨道。待测试和调整就绪后，将应用正式发布，并分发到世界各地。

    第 4 步：Google Play 会将已经被您签名的 APK (就是您上传的那个) 在安装时分发至每个用户的设备。

多年来，这种方法运作良好。实际上，人们每个月都会从 Google Play 安装超过 80 亿个应用！但是，正如您将看到的，这种模式为开发者带来了难以忽视的挑战。

难以忽视的 “大” 问题

挑战在于：应用的体积越来越大了。事实上，自 2012 年以来，应用体积平均增长了 5 倍。这很好理解： 您希望为应用添加炫酷功能和新内容，以确保用户留存/回归并保持业务增长。设备性能越来越好，您希望能把那些闪亮的新功能利用起来。设备生态系统变得更加多样化了，因此您决定复制应用中的代码和资源，使其在大屏幕和小屏幕上都能流畅运行，在不同种类的 CPU 上都能流畅运行，等等。

如果每个用户都拥有无限的存储空间、无限的数据流量和永远存在的快速连接，那么应用越来越大并没有什么问题。遗憾的是，事实并非如此 (当然我们希望有一天能够如此！)。通过查看下图，您可以看到 Google Play 上的应用大小与其安装转化率呈负相关关系。这意味着随着应用变大，其安装率会下降。出现这种情况有很多原因：许多用户的设备上没有足够的可用空间。用户可能在使用存储空间一般的入门级设备，即使对于那些拥有高端设备的用户而言，他们的照片、视频和其他媒体文件的品质也在逐渐提升，从而占据了越来越大的空间，设备上的可用空间正在逐渐紧缩。用户也不希望一边用着昂贵的流量套餐，一边等待大型应用去慢慢连接网络，在新兴市场尤其如此。

△ 应用文件尺寸和安装率呈负相关关系  

我们知道，较大体积应用的安装率会下降。我们的用户研究还表明，应用大小是推动卸载的主要动力，这使得应用大小成为提升保留率的一个越来越重要的因素。想想您自己的经历吧。当您尝试安装应用时，您是否曾经看到 Google Play 发出警告，提示您需要卸载部分不经常使用的应用，释放空间来安装新的应用？数以百万计的人们每天都会看到这些警告，在接到这个警告时，他们经常会卸载体积最大的应用和游戏。在 Google Play 去年进行的用户调查中，人们卸载应用和游戏的主要原因是为了腾出空间，即便这些应用和游戏已经被使用了至少一个月。

针对上述问题，开发者们能采用的解决方案很有限。您可以在单个版本中为每个设备配置构建多个 APK。但当您想要针对不同屏幕尺寸和 CPU 架构进行优化，同时针对 32 位和 64 位时，情况很快就会失控——您最终可能会为每个版本构建数百个 APK。这很痛苦，大多数开发者都不会这样做。许多人只是将所有内容都放在一个“胖胖的” APK 中，最终导致用户设备上存在着大量未使用过的内容。而且，即使您使用多重 APK，也无法针对语言进行优化。即使用户只需要一种或两种语言，您也必须在每个 APK 中包含针对每个设备的所有翻译字符串，这样会浪费更多空间。

因此，开发者的困境就显而易见了：增加应用的体积，但可能会导致较低的转换率和较高的卸载风险；使用多重 APK，会降低您的版本迭代效率并导致您疲惫不堪，您还可能会花费大量的时间权衡不同的功能之间的取舍，以避免增加应用体积。

“小” 而 “巧” 的解决方案来了

Google 不希望开发者面临这些困境，因此我们一直在努力改进。大致的想法是这样的：如果您将所需的所有内容上传到了 Google Play，让 Play Store 为每个用户和设备按需提供相应的内容。这很简单，不是吗？这一过程可以减少您支持 Android 多样化生态系统所需的工作量，并使用户手中的应用体积更小。正如您稍后将在本文中发现的那样，这个新方案还有助于改善用户获取过程：通过功能和更新，即时发现、安装、吸引，以及保留用户。

更小的安装包

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

     第 1 步：您可以在 IDE (如 Android Studio) 或 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 Lollipop 中引入的 Android 平台功能。只要每个分拆 APK 都使用相同的密钥签名，Android 平台就会将它们视为一个应用。您可以将各个分拆 APK 视为一个完整 APK 的各个“部件”：为了运行应用，设备会将全体部件整合起来，视为单个应用。

     第 5 步：当用户安装该应用时， Play 会提供基础 APK (每台设备上都需要用到的代码)，语言 APK (用于用户使用的语言)，以及配置 APK (用于适配设备的屏幕大小和 CPU 架构)。这意味着设备可以在不浪费空间的情况下获得所需的功能。要让设备接受更新，必须使用与原始应用相同的应用签名密钥对每个版本的分拆 APK 进行签名。

     第 6 步：在您的应用安装在设备上后，Play 也会根据需要提供额外的分拆 APK，例如，当用户更改设备语言或是想要使用动态功能时。更具体的细节将在稍后详述。

这个新分发模式可以显著缩小应用体积，减少下载时间，减少对存储空间的占用。您为用户提供了一个更高效的应用，其中不包含用户不会用到的代码和资源。对于大多数开发者来说，切换到这个新分发模式也很简单。在 Android Studio 中构建 App Bundle 与构建 APK 的过程大致相同。使用 Unity 的游戏开发者也可以在 Unity 的 2018.3 测试版及更高版本中构建应用束。Android App Bundle 是开源和向下兼容的 (对于 Android L 之前的版本，Play 会自动使用多 APK——即 Play 为每个设备配置生成一个 APK，包含所有语言资源，而不是使用分拆 APK)。

我们切换到 App Bundle，并在一小时内就上传了我们的第一个内部版本。

Swiggy ~使用 Apple Bundle 减少了 23% 的应用体积

成千上万的热门应用开发者正在使用 App Bundle 打包其应用。使用 Android App Bundle 的开发者的 APK 大小平均比之前采用的“完整 APK”小 3.5％ (“完整 APK”是指一个 APK 包含了 Android App Bundle 支持的所有设备配置和语言所需的一切）。更重要的是，对于那些必须管理每个版本的人来说，新格式意味着您不再需要使用多 APK 来进行设备配置。Google Play 会为您解决此问题，让您的生活轻松一点。Play Console 即将开始允许您上传大型 App Bundle，其对应的 APK 大小为500MB。在提升过尺寸上限后，我们相信在大多数情况下您也不需要使用额外的扩展文件了。

现在我们不必使用多 APK 了，App Bundle 节省了我们的时间。

redBus ~使用 App   Bundle 减少了 22% 的应用体积

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

在 Android M 之前，您的应用中包含的任何本地代码库都必须从 APK 中解压缩。这意味着每个设备上都安装了两个代码库副本：APK 中的压缩副本和未压缩的副本。这会导致空间浪费。从 Android M 开始，您可以直接以未压缩的状态从 APK 中读取代码库。Play 在下载过程中对 APK 的压缩通常比压缩 APK 中的本地代码库更有效，因此整体下载体积也更小。为了让您可以从中受益而不必担心上传大小，Play Console 的大小限制正在发生变化，它们基于用户下载的压缩 APK 大小，而不是您上传到 Play Console 的应用大小。平均来讲，仅此一项优化就足以将使用本地代码库的应用的文件下载量减少 8％，将设备上的安装大小减少 16％。只要切换到应用束，就可以享受到如此惊人的文件体积缩减！

20 多种语言的资源文件增加了我们的应用体积，并显著拉低了我们的访问安装转化率。我们使用 Android App Bundle 后情况大为改观。

Riafy ~使用 Apple Bundle 减少了 37% 的应用体积

正如我所提到的，应用必须选择通过 Google Play 进行应用签名才能使用应用束。应用签名密钥是一种机制，它可以确保在安装应用后，更新始终来自同一个开发者。Google 无法通过此密钥获得额外的访问权限，也无法识别有关开发者的信息。它仅用于签署拆分 APK 以进行安装和更新。Google 非常重视安全性，Google 拥有一支工程师团队以及高级的基础架构，使用与 Google 用来保护自用应用密钥相同的安全密钥存储来保护开发者的密钥。事实上，对于大多数开发者来说，选择进行应用签名然后使用上传密钥签署每个版本比自己持有密钥更安全，因为密钥可能会丢失或暴露。如果您决定不采用这种机制，并丢失了您的应用签名密钥，您将无法更新您的应用，很遗憾，一旦发生这种情况我们就无法提供任何帮助了。

动态功能

Android App Bundle 的另一个重要创新是模块化设计。这意味着您可以向应用添加模块，其中包含能够按需加载的其他应用功能。这就是我之前提到的应用变大的一个重要原因：功能的增长。现在，您可以添加更多功能，而无需在安装时增加应用的大小。使用动态功能也是在 Android 上动态加载代码的安全做法，因为动态功能模块的扫描和检查方式与 Google Play Protect 扫描和检查应用本身的方式相同。

任何应用功能都可以包含在动态功能模块中，并按需提供。您可以像编写应用一样对动态功能进行编码。适用的功能包括：

    安装时不需要的大型功能：您可以按需加载这些功能，或者告诉 Google Play 推迟安装它们，即在后台安装它们。您可以通过这种方式加载高达 100MB 的功能。在发布时，不属于核心应用体验范畴的高级功能或附加组件很适合进行这样的处理，例如付费高级功能、个性化选项、AR 功能等。

     针对特定受众群体的功能：您可以将其作为动态功能进行创建，而不是为每个受众群体添加功能。例如，商业应用可以隔离动态功能模块中的销售功能，因此只有购买功能在安装时才会分发给每个用户。需要销售功能的小部分用户群体 (即销售人员) 可以在需要时下载和访问这个功能。一些开发者还在探索动态功能，避免为仅仅是略有不同的用户群体提供为数过多的不同应用变体。

      很少使用的功能：动态功能模块的另一个用武之地是，用于那些很少使用或仅使用一次的功能。例如，如果您的应用包含有一次性身份验证或信用卡扫描功能，那么如果您能够根据用户需要加载此功能，并在使用后立即将其卸载，就可以有效避免增加应用体积。它还可以避免占用应用生命周期内未使用的空间——再次强调，更大的应用更有可能被卸载。

即时发现

我已经讲过了 Android App Bundle 如何帮助您保持应用的小巧，并通过动态功能实现应用的高度配置化。Android App Bundle 还支持免安装应用 (Instant Apps)。Google Play Instant 允许用户在安装完整应用或游戏之前，通过 Play Store 中的“立即试用”按钮、广告和链接试用应用和游戏。Instant 现在安装在 13 亿台设备上，并且被证明是驱动应用发现和安装的极佳方法，从而争取到那些可能尚未安装应用的用户。Vimeo 是利用 Google Play Instant 取得成功的众多合作伙伴之一，他们的报告显示，15％ 的新安装量都来自他们的试用功能。

过去，由于构建和发布过程都是独立的，有些开发者并不是很容易采用免安装应用。但是随着 Android App Bundles 的到来，您不必再去构建和维护单独的免安装应用。切换到应用束后，您可以添加一个模块作为免安装应用的入口点，如果您的应用足够小的话，只需启用基本模块即可。应用基本模块和免安装应用模块的大小限制为 10MB，这样就可以启用 Play Store 和 Web 横幅上的“立即试用”按钮。免安装应用只能请求受到支持的权限。如果您安装的应用需要使用其他权限，请在免安装应用中妥善地进行提示，以确保用户能够获得良好的体验。

这并不意味着每个应用都很容易满足 10MB 的体积限制。使用动态功能模块逐步加载功能是大幅减少应用体积的众多方法之一。10MB 的大小限制仅适用于将启用了免安装功能的应用束推送到生产环境的时候，所以在此之前您可以在超出大小限制的情况下对其进行测试。如果您能够将基本模块和免安装入口模块进一步减少到 4MB 以下，则可激活更多免安装体验的曝光机会，例如 Google Search 以及通过电子邮件或社交媒体等渠道共享的任何 Web 链接。想创建支持免安装的或者正常安装的应用束的话，您也可以使用 Android Studio 3.3 beta 版。

更快的更新速度

我想谈的最后一件事是，让用户手中的应用保持在最新状态。吸引和留住受众的最后一步是，确保他们拥有您所有的最新功能和最新补丁。虽然许多 Google Play 用户已经启用了自动更新功能，但许多用户还尚未启用，还有些用户无法频繁连接到高速的 Wi-Fi 连接并保持所有应用的正常更新。新的应用内更新 API  (In-app Updates API) 可让您检测何时有可用的更新，并集成可定制的在线更新流程，它的外观和感觉就像是应用的一部分。检测到更新时，您可以通过提示通知用户立即更新，也可以按照您选择的方式进行提示，从而更灵活地通知用户进行更新。

我们专门为关键的更新设计了即刻更新流程，例如安全修复程序或隐私增强功能，从而确保用户尽快应用这些更新。当用户在您的应用中接受此更新时，系统会下载并应用此更新，并会自动重新启动应用。有些应用已经为此实现了自己的解决方案，不过新的 API 通过一种更简单的标准化方式，在您的应用在运行中执行此操作。另外，更新的时机也更加灵活，只要用户接受了更新，它将在后台开始下载。下载完成后，您可以提示用户重新启动应用，也可以在应用进入后台时对其进行更新。

Google Chrome 现在正在测试应用内更新 API，我们很快就会向更多开发者推出。它适用于任何应用，因此您可以在切换到应用束时使用它。如果您想要获得良好的更新率，最好向用户明确说明更新的好处，如果有可能的话，让他们在完成想做的事情后再进行更新，而不是在他们首次打开您的应用时就询问他们是否需要更新。当有人第一次打开您的应用时，他们一定是带有明确的使用目的的，这时的他们并不想等待应用更新。

更小，更好，更快，更鲜活

所有的这些努力旨在帮助您通过更小、更高效的应用以及更快，更简化的版本来促成更多的安装量和更小的卸载率。Android App Bundle 还支持高度可配置的应用，它们拥有动态功能和即时试用体验，从而增加转换率。最后，想要让用户的应用保持最新也比以前更加容易了。

我们相信，这会让我们的应用生态朝着更鲜活的方向发展。让我们一起期待 Android 的下一个十年！祝大家开发路上顺利 & 成功！

点击这里了解 Android App Bundle 详情