APK：它是什么、文件结构及工作原理

什么是 APK 及其用途

APK（Android Package Kit）是一种归档格式，Android 应用程序被打包在其中以便分发。从技术上讲，APK 是一个具有特定结构的 ZIP 归档文件，包含应用程序在设备上运行所需的所有组件。

格式的历史

APK 格式与 2008 年第一个版本的 Android 一起出现。其基础是 JAR（Java Archive）标准，而 JAR 本身又基于 ZIP。这种继承确保了与现有归档工具的兼容性——任何解压软件都可以像打开普通 ZIP 一样打开 APK。

应用领域

Google Play 是 APK 分发的主要渠道，但该格式也用于其他场景：通过浏览器直接安装（侧载）、企业应用商店、在开发者设备上测试以及在模拟器中安装。根据 Statista 的数据，2025 年大约有 15% 的 Android 应用安装在 Google Play 之外进行。

APK 文件的内部结构

APK 的内部结构有严格规定：每个应用程序必须包含特定的文件和目录。违反结构会导致安装错误。

AndroidManifest.xml

清单 是应用程序的中央配置文件。在编译后的二进制形式中（不是可读的 XML），它包含包名、版本、活动列表、服务、权限和 SDK 要求。没有清单，系统不知道如何运行应用程序。

DEX 文件

Java 或 Kotlin 的源代码被编译为 DEX（Dalvik Executable）文件。主文件名为 classes.dex。如果字节码超过 64K 方法的限制，则会创建 classes2.dex、classes3.dex 等——这就是 multidex 机制。

本地库

lib/ 目录包含针对不同架构编译的 C/C++ 库：armeabi-v7a、arm64-v8a、x86、x86_64。每个库都有 .so（Shared Object）扩展名。现代应用程序通常只提供 arm64-v8a。

通过 Gradle 构建 APK 的过程

构建 APK 是一个多阶段过程，由 Gradle 构建系统和 Android Gradle Plugin 自动化完成。每个阶段将源文件转换为最终归档的组件。

构建阶段

源代码被编译为 Java 字节码（.class），然后通过 d8 工具（以前是 dx）转换为 DEX。资源通过 AAPT2 编译为二进制格式。所有组件被打包到 ZIP 归档中并使用数字签名进行签名。

// build.gradle.kts — APK 构建的基本配置
android {
    defaultConfig {
        applicationId = "com.example.app"
        minSdk = 24
        targetSdk = 34
        versionCode = 1
        versionName = "1.0.0"
    }
    buildTypes {
        release {
            isMinifyEnabled = true
            proguardFiles(
                getDefaultProguardFile("proguard-android-optimize.txt")
            )
        }
    }
}

ProGuard 和减小大小

ProGuard 或 R8 混淆代码，删除未使用的类和方法，从而减小 APK 的大小。没有混淆，APK 包含完整的类名，这简化了反编译。R8 还在 DEX 级别执行字节码优化。

APK 签名：v1、v2、v3 和 v4 方案

数字 签名是 APK 的必需元素。Android 不安装未签名的包。签名确保应用程序在发布后未被修改，并确定包的归属。

签名方案的演进

v1（JAR 签名）——基于对归档中每个文件进行签名的原始方案。弱点：可以从 META-INF 中删除文件而不被检测到。v2（APK Signature Scheme v2）出现在 Android 7.0 中——对整个归档进行签名，防止修改。v3 支持密钥轮换，v4 支持增量安装。

Google Play 自 2021 年 8 月起要求所有新应用使用 v2 或更高版本。建议使用所有三种方案对 APK 进行签名，以最大限度地兼容不同版本的 Android。

通过 Gradle 的签名过程

在 build.gradle 中指定 keystore、密码和别名。私钥存储在加密的存储库中。要在 Google Play 中发布，使用 App Signing——Google 存储私钥，开发人员上传已签名的 APK。

在 Android 设备上安装 APK

安装 APK 通过系统包管理器 PackageManager 进行。该过程包括验证签名、解析清单、复制文件和通过 dex2oat 优化 DEX。

通过 ADB 安装

ADB（Android Debug Bridge）工具允许直接从开发人员的计算机安装 APK。命令 `adb install app.apk` 将文件复制到设备并启动安装。标志 -r 重新安装应用程序并保留数据，标志 -d 允许安装 versionCode 较低的版本。

安装安全

从 Android 8.0 开始，系统要求每个应用程序单独确认从未知来源安装。Android 14 加强了控制：通过第三方商店安装 APK 只有在设置中明确许可后才能进行。Google Play Protect 会在安装时扫描每个 APK 是否存在恶意代码。

APK Expansion Files（OBB）

对于大于 150 MB 的应用程序，Google Play 支持 Expansion Files——每个最多 2 GB 的额外 OBB 包。OBB 文件不包含在 APK 中，而是在安装后单独下载。该格式支持两种类型：main（基本资源）和 patch（更新）。

// 通过 PackageManager 检查 APK 版本
val pm = packageManager
val info = pm.getPackageInfo(
    "com.example.app",
    PackageManager.GET_ACTIVITIES
)
Log.d("APK", "版本：${info.versionName}")

dex2oat 优化

在具有 ART（Android Runtime）的设备上，安装后通过 dex2oat 启动 DEX 到本地代码的编译。该过程可能需要几秒钟，并增加已安装应用程序的大小，但会加快其启动速度。

APK 与 AAB：选择哪种格式

AAB（Android App Bundle）——Google 推广的替代 APK 用于在 Google Play 发布的格式。区别是根本性的：AAB 不能直接安装，而是作为一个容器，Google Play 从中生成优化的 APK。

Google Play 自 2021 年 8 月起要求新应用程序使用 AAB。然而，APK 仍然是 Google Play 之外分发的主要格式——通过网站、企业商店和测试。

APK 常见问题及解决方案

开发人员 在构建和安装 APK 时经常遇到问题。大多数问题与版本不兼容、签名或归档结构有关。

INSTALL_FAILED_UPDATE_INCOMPATIBLE

当尝试安装具有相同包名但不同签名的 APK 时会出现此错误。Android 不允许重新安装具有更改证书的应用程序。解决方案——在安装前删除旧版本。

超过方法限制（65K）

如果项目超过 65536 个方法的限制，构建将失败并出现 dex 错误。解决方案——在 build.gradle 中启用 multidex，或通过删除未使用的库来优化依赖项。

APK 体积过大

Google Play 将 APK 大小限制为 150 MB。对于更大的应用程序，使用 APK Expansion Files（OBB）。建议通过 R8、WebP 图像和 Android App Bundle 减小大小。每增加一兆字节都会对安装转化率产生负面影响：根据 Google 的数据，每 10 MB 会降低 1% 的转化率。

APK 反编译与安全

APK 可以使用 JADX、APKTool 或 Bytecode Viewer 等工具进行反编译。JADX 从 DEX 中恢复原始 Java 代码，这使得没有混淆的应用程序完全可读。为了保护代码，使用 ProGuard/R8，它将类、方法和字段重命名为简短不可读的名称，并删除调试信息。

通过工具分析 APK

用于分析 APK 内容的有 Android Studio Profiler、apkanalyzer（来自 Android SDK 的 CLI 工具）和第三方实用程序。apkanalyzer 显示 APK 每个组件的大小：DEX、资源、本地库和签名。分析有助于识别哪些依赖项占用最多空间，并决定替换或删除它们。