📚 课程目录第3章开发环境准备

开发环境准备：Android Studio 版本要求、Gradle 插件配置

说实话，做动态交付拆分这件事，最怕的不是代码怎么写，而是环境搭错了还浑然不觉。我刚接触 Split Install 时，就因为 Android Studio 版本太旧，折腾了一整天才知道问题在哪。所以这一节，咱们把开发环境从头捋一遍，一步也别跳。

核心要点：Android Studio 4.0 及以上才能支持动态交付模块，但为了稳定，我建议直接用最新的稳定版（比如目前推荐 Android Studio Hedgehog 2023.1.1 或 Iguana 2023.2.1）。Gradle 插件版本（AGP）至少 4.0，最好 7.0+。

Android Studio 版本怎么选？

你想想看，AS 版本太老，Gradle 同步都过不去，更别说配置动态功能模块了。官方的要求是 Android Studio 4.0+，但我个人实测，4.2 版本还有些小坑——比如部分模块拆分后 APK 打包失败。后来我换了 AS 2020.3.1（Arctic Fox）以上版本，就再没出过类似问题。

Android Studio 版本	推荐情况	备注
4.0 - 4.1	基本可用	可能遇到 Gradle 同步警告
4.2 (Arctic Fox)	推荐	支持 AGP 7.0，动态功能模块较稳定
2021.1 (Chipmunk)	很推荐	内置 Split Install 预览工具
2023.1+ (Hedgehog / Iguana)	最推荐	最新 API，打包速度更快

小技巧：可以在 Android Studio 的「Help → About」里查到具体版本号。如果你还在用 3.x，赶紧升级，别犹豫。

Gradle 插件配置：AGP 和 Gradle 版本对应

说白了，AGP 版本决定了你能不能使用 com.android.dynamic-feature 插件。这个插件是动态模块交付的基础。我记得有一次为了省事，用了 AGP 3.6，结果编译时报错说找不到 dynamicFeatures 属性。后来查文档才发现，AGP 4.0 才正式支持。

下面这个对应关系表，我建议你保存下来：

AGP 版本	最低 Gradle 版本	动态功能模块支持
4.0.x	6.1.1	✅ 支持
4.1.x	6.5+	✅ 支持
7.0.x	7.0+	✅ 推荐
7.4.x	8.0+	✅ 最稳定

我个人习惯是直接上 AGP 7.4 + Gradle 8.0。虽然高版本对项目配置要求更严格（比如命名空间必须写在 build.gradle 里），但好处是打包速度提升明显，而且后续 Google Play 的新特性基本都会优先支持。

配置 build.gradle：添加 Play Core 依赖

动态交付的核心依赖是 Play Core 库。记住，com.google.android.play:core 这个库要从 1.10.0 以上版本才能完美支持 Split Install API。我曾经因为用 1.9.0 版本，导致下载完成后回调没触发，排查了半天才发现是库的 bug。

先在项目根 build.gradle 里加 Google Maven（如果还没加的话）：

buildscript {
    repositories {
        google()
        mavenCentral()
    }
    dependencies {
        classpath 'com.android.tools.build:gradle:7.4.2'
        // 其他依赖...
    }
}

然后在 app 模块的 build.gradle 里添加 Play Core 依赖：

dependencies {
    implementation 'com.google.android.play:core:1.10.3'
    // 如果使用 Kotlin，可以加 KTX 扩展
    implementation 'com.google.android.play:core-ktx:1.8.1'
}

注意：Play Core 库的版本不要和 AGP 版本冲突。如果你用 AGP 8.0+，建议 Play Core 至少 1.10.3。我踩过坑——用 AGP 8.0 配 Play Core 1.8.0，编译时直接报 Duplicate class 错误。

配置动态功能模块

光有依赖还不够，你得在 app 模块的 build.gradle 里声明哪些功能是可拆分的。说白了，就是告诉 Gradle：「我把某个模块做成动态功能，用户按需下载。」

举个例子，假如你有一个 camera_module 的动态模块，在 app 模块的 build.gradle 里这样写：

android {
    ...
    dynamicFeatures = [':camera_module']
}

dependencies {
    // 注意：动态模块不需要 compileOnly，直接用 implementation
    implementation project(':camera_module')
}

同时在 camera_module 的 build.gradle 里必须应用动态功能插件：

plugins {
    id 'com.android.dynamic-feature'
}

android {
    compileSdk 34
    defaultConfig {
        minSdk 21
    }
}

dependencies {
    implementation project(':app')
    implementation 'com.google.android.play:core:1.10.3'
}

重要事项：动态模块的 minSdk 必须大于等于 app 模块的 minSdk，否则编译会失败。我当初设了个 minSdk 14（因为老用户多），结果动态模块死活编译不过，改成一致就好了。

签名配置不可忽略

动态交付模块必须使用正式签名才能正常测试。如果你像我一样习惯用调试签名，那在模拟器或真机上测试时，需要额外配置签名一致。否则 Play Core 会报签名校验失败。

建议在 app 模块的 build.gradle 里显式配置签名：

android {
    ...
    signingConfigs {
        release {
            storeFile file('release.keystore')
            storePassword 'yourPassword'
            keyAlias 'yourAlias'
            keyPassword 'yourKeyPassword'
        }
    }
    buildTypes {
        debug {
            signingConfig signingConfigs.release  // 调试阶段也使用 release 签名
        }
        release {
            signingConfig signingConfigs.release
        }
    }
}

避坑指南：千万不要把签名密码硬编码在 build.gradle 里提交到 Git！我用过 keystore.properties 文件存储在本地，然后在 gradle 中读取。

最后来张图，理清整个环境准备流程

下面这张图是我自己画的环境搭建流程图，包含了从 AS 版本选择到最终编译运行的每个关键节点。你可以对照着一步步走，保证不迷路。

嗯，到这里，环境准备这块应该没什么大问题了。你按这个流程配一遍，基本不会遇到隐性错误。如果后续编译遇到奇怪报错，先回头检查 Gradle 版本和 Play Core 版本——十有八九是版本不匹配惹的祸。