一个时代即将终结！安卓应用告别APK格式

一个时代即将终结！安卓应用告别APK格式

我们知道应用程序以 APK 格式呈现。 自从我们接触系统以来，APK就一直伴随着我们，但现在，APK的时代可能真的结束了……

01q

APK 格式称为

APK全称，意为“应用程序包”，是操作系统用来分发和安装移动应用程序和中间件的应用程序包文件格式。

一个应用程序代码想要在设备上运行，首先必须经过编译，然后打包成系统可以识别的文件，然后才能运行。 这种系统能够识别并运行的文件格式就是“APK”。

APK文件其实是zip格式，只是后缀名改为apk。 通过UnZip解压后，可以看到Dex文件。 Dex是可执行程序的缩写，它不是Java ME的字节码而是字节码。 运行程序时，首先需要UnZip，然后就直接这样了，不过不像（WPF）中的PE文件也采用这种架构方式。

在平台中，可执行文件以apk格式打包，最终运行时加载器会先对其进行解压，然后获取编译后的.xml文件中声明的安全访问限制。 要知道还是有很多安全限制的，但是当apk文件传输到//app文件夹时，你会发现执行是不受限制的。 也许我们正常安装时不会选择这个文件夹，但是在2019年，系统的apk文件会默认放在这个文件夹中，并且它们具有root权限。

现在这种格式即将被取代。 据报道，宣布AAB格式将取代APK。

02

宣布支持AAB格式

据悉，早在2018年就推出了新的AAB格式（AAB的全称是“App”）。声称这种新格式将使应用程序文件变得更小。

目前 Play 上提供的数百万个应用程序中，有数千个应用程序已率先遵循 AAB 格式。

现在已经宣布AAB正式取代APK。 从今年8月开始，所有提交到Play商店的新应用程序都必须使用AAB格式。

App 是一种发布格式 - 准确地说，是一个扩展名为 .aab 的 zip 文件。 它包含应用程序支持的所有设备的代码和资源，例如 DEX 文件、本地代码库、清单文件、各种资源文件等。上传发布后，Play 会处理 APK 的签名和生成，这个过程称为动态交付（动态交付）。 动态交付的目的是根据用户的设备配置为用户生成优化的 APK。 那么这到底是如何完成的呢？

拆分 APK（在 中介绍）是从给定的应用程序生成的，其行为类似于单个 APK。 典型的应用程序可以获得一个基本APK和多个配置APK。 此外，如果应用程序具有动态功能，用户还可以获得动态功能APK及其配置APK。 基础 APK 包含所有设备配置通用的文件，例如清单文件。 系统会为您生成配置 APK，每个 APK 都包含与特定设备配置相关的资源：语言、CPU 架构或屏幕像素密度。 因此，用户将获得一个标准的基础 APK（与所有其他设备一样）以及一个仅包含与用户设备相关的资源的配置 APK。

这意味着，如果我使用的是 One 手机（小米 A1）并且我设置的主要语言是英语，则手机将获得基础 APK 和支持英语、arm64 CPU 架构和 xhdpi 屏幕分辨率的配置 APK。 更好的是，当设备配置（例如语言）发生变化时，Play 会检测到它并下载该语言的配置 APK。 为了进一步减小 APK 大小，我们计划推出基于纹理压缩格式、图形 API 和新平台功能的分发解决方案。

动态功能 APK 包含用户首次安装应用程序时不需要的应用程序功能代码和资源。 开发人员可以将这些用途或功能添加到他们的应用程序中，Play 将按需提供这些动态功能模块，而不是在安装时全部添加，从而进一步减少应用程序下载大小。 这也很容易理解：我们有必要将那些在安装时占用空间且根本不使用的功能，以及那些很少使用的功能，打包成动态功能模块，这样在安装时会大大减少文件。用户安装它们。 下载。

安装早期版本的设备还可以享受较小安装文件的好处，但它们的 APK 将包含所有语言。

如今，构建统一的、臃肿的 APK 显然已经过时了。 App代表了应用交付的未来，接下来我们就看看如何构建这样的安装包。

035

APP即将大幅精简

了解了ABB是什么以及它的工作原理后，人们不禁想知道ABB能让APK程序占用的空间小多少？

目前国内开发者将所有资源都放在一个APK中，导致APK非常大，而AAB在压缩APK大小方面具有优势。

为了减小大小，一些开发者会故意缩小APK中的ABI目录。 例如，从 APK 中删除 arm64-v8a SO，仅保留 -v7a SO。 但这种做法让64位CPU的手机无法发挥64位计算优势，降低了程序运行速度。

Split APKs是从5.0开始提供的多APK构建机制。 通过Split APKs，可以根据ABI、屏幕密度和CPU架构将一个APK拆分为多个APK，可以有效减小单个APK的大小。 当用户下载应用安装包时，Play会自动识别用户的语言和CPU架构，并自动将平台SO对应的APK和资源下发给用户。

这听起来还是有点令人困惑吗？ 事实上，应用程序的早期采用者已经发现动态交付显着减小了应用程序的大小。 一些开发者甚至可以将APK的大小减少一半，一些知名应用程序也发布了使用Apps来减少应用程序大小的数据。

除了压缩尺寸，ABB还在“防二次包装”的安全性上有所表现。 但的这一改变真的是技术变革驱动的还是为了给用户更好的用户体验？

04

想要收紧权限的

.aab 模块引入了 Split APK 概念。 简单来说，在安装之前，它会自动检测用户的硬件配置，然后以多个.apk的形式安装应用程序。 但目前用户无法直接使用Split APK解压并安装应用程序，需要使用第三方工具来备份安装。 这意味着未来用户在谷歌应用商店以外的第三方平台下载安装应用程序将越来越困难。

虽然.aab的模块化特性极大地提高了开发人员更新和维护的便利性，但也节省了用户安装应用程序时的时间和存储空间。 仅仅因为.aab的存在，根据用户使用的设备和环境的不同，安装的应用程序可能会有所不同，应用程序是“不完整的”。

并且，通过官方文档，我们发现：要使用应用程序，开发者必须加入Play应用程序签名计划。 签名相当于一个唯一的电子标签。 因此，如果应用程序以非正常方式被提取和共享，则可能会导致签名发生变化，最终影响应用程序的运行。 除非开发者在第三方平台上提供完整的应用程序安装包。

只能通过指定的应用商店下载，应用程序“不完整”，并且有共享限制。 所有用户都会受到这些限制的影响。

进一步思考，如果实行.aab应用程序格式，对于用户来说，只会让第三方下载应用程序变得更加困难。 所以对于鸿蒙OS来说，这可能是一个巨大的挑战。

目前，鸿蒙OS的大部分软件仍然基于应用程序。 因此，如果谷歌全面使用.aab，势必会对鸿蒙造成不利。

当然，这种想法可能是我们想太多造成的。 可能需要一些时间来验证 应用程序这次到底发生了什么变化。