Android Play Feature Delivery D

自 2021 年 8 月起，新应用需要使用 Android App Bundle 才能在 Google Play 中发布
。当用户下载您的应用时，安装应用所需的压缩 APK（例如，基本 APK + 配置 APK）的总大小不得超过 150 MB

---

AAB 简介

示例项目 模块可单独出包，也可以在主模块展示所有可用模块

Demo 展示
桌面
内容

AAB 很简单，无非是APK套个壳

测试项目生成的AAB压缩包

重要的是AAB的特性，仔细看上图，其实base、feature_ngapi、feature_ktv其实分别对应项目中:app、: feature_ngapi、:feature_ktv三个模块，也就是说AAB支持APK动态下发。

测试项目的结构

注意：这个:base模块只是一个依赖库，:app打包后才会生成base文件夹

但是如果是传统的开发模式，肯定最终还只是一个base.apk，支持这种多模块单独打包需要使用标题提到的Play Feature Delivery，以及将需要单独分发的部分独立出一个模块，并且使用Dynamic Feature Module依赖。

注意点

按照官网的教程新建完项目后，有以下几个需要格外注意的点

• dynamicFeatures 参数设置

这里面填的应该是模块的名称，而不是module_title

• 子模块会依赖主模块（比如:feature_ktv会依赖:app）

是的，这个功能就是建立在这个基础上，无法避免。所以当子模块与主模块有相同的文件名打包时会出错，建议使用resourcePrefix隔离。

• 这不是组件化的最佳实践？

我就是抱着这个想法来了解的，我不需要Play Store 的动态下发，我只用来解耦组件。但，尝试了一段时间后，发现还是得和传统的实现方式一样从代码手动控制，比如使用ProductFlavors控制最终打包哪些模块，最后还是得用Manifest间接实现，但也许对Gradle足够了解后可以搞定。

• ProductFlavors 问题

如果模块的依赖项有声明特定flavor，则该模块也需要作出声明；如果依赖项没有则不用管。

:base -> :app -> :feature_ktv

:base没有声明，:app依赖它，所以不用管。
但是:app自己有声明flavor，由于所有DFM默认依赖:app，所以它们都需要声明，这也导致开发异常繁琐，从而加重上一问题中Manifest方案的实现成本。