为何说它对 Android 将来的发展十分重要？

做者 / 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 详情

访问开发者官方中文网站，快速入门 Android 开发！