安卓应用安装方式大改,技术进步还是垄断封闭?( 二 )

此时，编程工具不会将所有的素材打包成一个APK文件，而是会其生成一个个“程序模块” 。比如说，有的模块对应的是低分辨率屏幕的界面素材、有的模块对应高分辨率的界面素材、有的模块是纯64位的ARMv9代码、有的模块是32位的ARMv7代码，还有的则是各种不同GPU适配的3D材质包。
有意思的是，这些“程序模块”本身其实也是.APK后缀名的文件，但是它们将无法通过此前的方法进行安装。而开发者唯一需要做的，就是将它上传到PlayStore中，剩下的事情就不需要管了。

相比传统APK ， AAB机制不会下载手机不需要的功能模块
这时假使有一名用户正好在PlayStore中看到了刚刚上传、采用AAB技术的应用，那么当其点击“安装”时，手机就会首先将自身的屏幕分辨率、CPU指令集架构、GPU纹理格式这些信息报告给应用商店。然后，应用商店就会自动从刚才的那一串“程序模块”里，挑选出这台手机所需要的那几个进行下载及自动安装。
这就相比于我们前文中所讲到的通过APK安装的应用，藉由模块化AAB技术安装应用的优势就显现了出来。首先，它不需要下载手机用不着的那些功能模块，因此可以节省流量，能够加快下载速度。其次，也不会安装手机所不支持的那些部分，因此程序装好后占用的存储空间更小。并且除此之外，它还可以确保手机安装的一定是最适合其软硬件配置的代码，从而提高应用的执行效率。

不仅如此， AAB不只可以用于应用第一次安装，其在应用更新时也能够发挥作用。 PlayStore会智能识别那些需要更新的“模块” ，然后只推送这部分内容的下载，从而起到加快更新速度、减少流量消耗的作用。
然而从APK变成AAB ，谷歌也变相“封闭”了生态
可以看到对于开发者来说，从APK转向AAB ，虽然不能减少开发的工作量，但确实可以强化应用的兼容性、减少下载和安装的耗时、提高使用体验。而对于大部分用户来说，谷歌的这一新政策也确实能够让应用安装后的存储空间占用量更小，应用更新速度更快，乍看之下是一个相当有意义的技术改进。
但问题就在于，从APK切换到AAB模式后，应用的安装包不再是一个APK文件，而是很多个的模块。并且最要命的问题是，虽然这些功能模块的文件后缀也是.APK ，但它们却无法再在手机上以简单的方式手动安装了。

换而言之，开发者要么从此以后只能依赖谷歌的应用商店作为分发渠道，要么就必须同时维护传统的单文件APK和新式的模块化AAB两种安装包。而且此时的APK相比于AAB ，注定还是会存在着文件更大、下载更慢、安装更占空间、执行效率更低的问题。对于开发者而言，为了降低自身的工作量、同时避免被用户吐槽，确实就有动机放弃APK ，全面拥抱谷歌所倡导的AAB模块化安装包技术。
【安卓应用安装方式大改,技术进步还是垄断封闭?】但是这样一来，对于那些旨在直接提供APK文件下载的第三方分发渠道，对于一些技术不过关，实现不了智能分发功能的应用商店来说，谷歌此举无异于从源头上给它们“断了粮” 。