Android Play Feature Delivery D
自 2021 年 8 月起，新应用需要使用 Android App Bundle 才能在 Google Play 中发布
。当用户下载您的应用时，安装应用所需的压缩 APK（例如，基本 APK + 配置 APK）的总大小不得超过 150 MB
示例项目 模块可单独出包，也可以在主模块展示所有可用模块
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方案的实现成本。
