如何在Android手机上安装应用？看到这个问题，可能许多朋友会觉得“这太简单”。特别是对于“玩机老手”来说，他们甚至可以一口气举出多种在Android手机上安装应用的办法。
比如说，可以直接在应用商店搜索想要的应用，然后点击“安装”即可；比如说，还可以自行下载安装包，也就是APK文件，然后在文件管理器里点击打开。当然，更“高级”点的话，还可以将手机连接到电脑，然后用ADB程序直接向手机推送安装包。
这几种安装方式装入的程序，在性能上有没有区别？按照以往的经验来说，几乎是没有的。但问题就在于，在今年8月份后，这个情况可能就会发生巨大的变化。
因为APK的碎片化太严重，谷歌即将放弃
日前有消息显示，自今年8月起，谷歌官方应用商店Play Store的应用上传技术规范将进行调整，已经使用了十年以上的APK安装包将不再作为默认的上传格式，取而代之的将是全新的AAB格式，也就是Android App Bundles。
为什么谷歌要放弃APK？要理解这个问题，我们就必须要明白一件事，那就是发展了十几年的整个Android开放生态，到底对开发者造成了多大的麻烦。
设想一下，如果你是某游戏的开发者，当游戏需要添加新的内容时需要编写哪些东西呢？
首先，必须要考虑对市面上所有移动CPU架构的兼容性。这一点相对比较容易，因为目前主流的手机CPU就只有两种指令集，ARM V7与ARM V8，就算考虑到今年底发布的新品，最多也就再加一个ARM V9，也就是只需要写三份主程序代码就行。
其次，现在市面上主控芯片通常内建的是高通Adreno、ARM Mali，以及Imagination PowerVR三种移动GPU方案。由于每一种方案使用的纹理代码、画面特效技术都是不同的，所以需要准备好三个不同的3D建模数据包，但如果考虑到年底三星使用AMD RDNA2架构GPU的新旗舰SoC也即将上市，就需要准备四套数据包才行。
此外，手机游戏中并不是只有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技术安装应用的优势就显现了出来。首先，它不需要下载手机用不着的那些功能模块，因此可以节省流量，能够加快下载速度。其次，也不会安装手机所不支持的那些部分，因此程序装好后占用的存储空间更小。并且除此之外，它还可以确保手机安装的一定是最适合其软硬件配置的代码，从而提高应用的执行效率。
不仅如此，AAB不只可以用于应用第一次安装，其在应用更新时也能够发挥作用。Play Store会智能识别那些需要更新的“模块”，然后只推送这部分内容的下载，从而起到加快更新速度、减少流量消耗的作用。
然而从APK变成AAB，谷歌也变相“封闭”了生态
可以看到对于开发者来说，从APK转向AAB，虽然不能减少开发的工作量，但确实可以强化应用的兼容性、减少下载和安装的耗时、提高使用体验。而对于大部分用户来说，谷歌的这一新政策也确实能够让应用安装后的存储空间占用量更小，应用更新速度更快，乍看之下是一个相当有意义的技术改进。
但问题就在于，从APK切换到AAB模式后，应用的安装包不再是一个APK文件，而是很多个的模块。并且最要命的问题是，虽然这些功能模块的文件后缀也是.APK，但它们却无法再在手机上以简单的方式手动安装了。
换而言之，开发者要么从此以后只能依赖谷歌的应用商店作为分发渠道，要么就必须同时维护传统的单文件APK和新式的模块化AAB两种安装包。而且此时的APK相比于AAB，注定还是会存在着文件更大、下载更慢、安装更占空间、执行效率更低的问题。对于开发者而言，为了降低自身的工作量、同时避免被用户吐槽，确实就有动机放弃APK，全面拥抱谷歌所倡导的AAB模块化安装包技术。
但是这样一来，对于那些旨在直接提供APK文件下载的第三方分发渠道，对于一些技术不过关，实现不了智能分发功能的应用商店来说，谷歌此举无异于从源头上给它们“断了粮”。
不仅如此，如果我们联想到最近微软Windows 11通过亚马逊应用商店支持Android应用下载、运行，而且也允许用户自行安装APK的设计，就会意识到谷歌此举更是变相地为开发者将应用分发至Windows11设置了阻碍。毕竟谁都知道亚马逊应用商店在技术上确实要落后Play Store不少，大概率是很难短时间里为AAB这种新的应用分发技术做好准备。再加上采用AAB封装后，APK文件会变得无法直接安装，这实际上也变相封堵了用户利用Windows11侧载功能“直装”Android应用的渠道。
谷歌在开发者网站上列出了采用AAB机制之后，应用可以节约多大的安装体积
当然，我们不能说谷歌在应用商店里升级新技术，目的就是为了“恶心”竞争对手，同时“干掉”第三方分发渠道，因为AAB对于用户是可以带来明显体验提升的，而且谷歌也并没有禁止竞争对手使用它（前提是他们有那个能力）。但至少从其可能导致的结果来看，我们可以说，谷歌这已经很明显是在收紧对于Android生态的控制了。虽然这也有好的一面，但也确实反映了这家巨头如今利用技术优势，为自己在市场竞争中提供额外助力的事实。