此外，手机游戏中并不是只有3D画面，通常还会有许多2D菜单及界面元素。而要想让这些内容的显示效果清晰，就得根据各种不同画面比例、不同分辨率的设备，分别做出不同DPI（像素密度）的2D界面。大概做个七八种，应该也就够用了。
最后一个步骤，就是将上述所有的这些数据整合成一个安装包，也就是APK里，然后进行发布、上传。
不难看出，对于开发者而言，为了确保应用的兼容性，不得不每次都编写大量的兼容性代码，从而使得最终的APK安装包体积极度臃肿。而对于用户来说，这也意味着当他们耗费了大量的时间和流量，下载并安装了想要的应用后，实际上其中可能有大量的代码、数据包都不是针对自己那台手机的，但是这些代码却又会占用存储空间，并间接对性能造成不良影响。
AAB的好处是什么？它能让程序更小更快
明白了传统Android APK的困境后，我们再来看谷歌此次用来替代它的AAB，其实就十分明了了。
在上文中的开发者场景中，这次虽然依旧需要为市面上的不同处理器、不同分辨率的设备等，适配各种各样的数据包。但是在最后一步将所有文件打包时，不再需要构建APK安装包，而是在Android Studio（谷歌官方提供的编程工具）中选择“Build Bundle”即可。
此时，编程工具不会将所有的素材打包成一个APK文件，而是会其生成一个个“程序模块”。比如说，有的模块对应的是低分辨率屏幕的界面素材、有的模块对应高分辨率的界面素材、有的模块是纯64位的ARM v9代码、有的模块是32位的ARM v7代码，还有的则是各种不同GPU适配的3D材质包。
有意思的是，这些“程序模块”本身其实也是.APK后缀名的文件，但是它们将无法通过此前的方法进行安装。而开发者唯一需要做的，就是将它上传到Play Store中，剩下的事情就不需要管了。
相比传统APK，AAB机制不会下载手机不需要的功能模块
这时假使有一名用户正好在Play Store中看到了刚刚上传、采用AAB技术的应用，那么当其点击“安装”时，手机就会首先将自身的屏幕分辨率、CPU指令集架构、GPU纹理格式这些信息报告给应用商店。然后，应用商店就会自动从刚才的那一串“程序模块”里，挑选出这台手机所需要的那几个进行下载及自动安装。
这就相比于我们前文中所讲到的通过APK安装的应用，藉由模块化AAB技术安装应用的优势就显现了出来。首先，它不需要下载手机用不着的那些功能模块，因此可以节省流量，能够加快下载速度。其次，也不会安装手机所不支持的那些部分，因此程序装好后占用的存储空间更小。并且除此之外，它还可以确保手机安装的一定是最适合其软硬件配置的代码，从而提高应用的执行效率。
