SplitInstall概述：什么是动态交付、核心优势与应用场景

大家好，我是做Android模块化开发的老手了。动态交付这个概念，说白了就是把APK拆成多个按需下载的模块。用户不用一次性下载整个应用，而是先用核心功能，等需要某个模块时再临时拉取。嗯，Google Play的SplitInstall库就是干这个的。

1.1 动态交付的背景：我们为什么需要它？

你想想看，现在很多App功能越做越多，安装包动不动就上百兆。用户下载时看到那么大体积，直接放弃的情况很常见。我在项目里遇到过，一个电商App光是商品详情页的AR试穿模块就占了30MB，但90%的用户根本没点过那个入口。这些用户白白浪费了下载时间和流量，你说痛不痛？

动态交付，就是让每个模块按需加载。核心功能先装上，剩下模块等用户要用时才触发下载。

1.2 SplitInstall是什么？一张图看懂

下面这张图是我自己总结的分层结构，能帮你快速理解动态交付在Android项目中的位置：

1.3 核心优势：你想想这些场景

动态交付不是花架子，实打实解决了几个痛点。我把核心优势列出来：

优势	说明
安装包体积骤减	基础APK只放核心功能，其余按需下载。比如一个地图App，导航模块40MB，非开车用户永远不用下载。
首次打开速度变快	小体积安装包意味着下载快、安装快、冷启动快。我曾经数过，一个40MB的包比200MB的包平均快3秒加载完成。
降低用户流失	用户看到100MB可能直接放弃，但看到30MB会愿意试一试。某调研显示安装包每减少10MB，转化率提升约0.5%。
模块独立开发	开发团队可以按模块拆分git仓库，编译构建互不干扰。我用过这个后，再也不用跟隔壁组的同事抢CI排队了。
灵活更新	某个模块出问题，只需撤回该模块，不影响基础APK和其他模块。嗯，这是救命特性。

1.4 应用场景：哪里最适用？

不是所有App都适合All-in动态交付。我个人习惯这样判断：模块使用率差异大 + 模块体量大 + 模块功能独立时，效果最好。通常这些场景会用到：

• 大型游戏：主程序几百MB，又包含不同地图/剧情包，玩家可能只玩其中一小部分。我之前参与过一款ARPG游戏，把新手村设为base，地下城作为条件模块，下载量直接涨了12%。
• 电商/社交：AR试穿、直播带货、3D展厅等高消耗功能，绝大多数用户半年才用一次。把这类功能做成按需模块，安装包能瘦40%以上。
• 国际化App：语言包、地区特色功能（比如印度市场的UPI支付、日本市场的Suica卡）可以作为独立模块，用户只下载自己地区需要的。
• 工具类App：翻译App中的离线包、图像处理App的滤镜包、办公App的字体包。用户按需下载，不占地方。
• 即时通讯：已阅回执、表情商店、小游戏等非核心功能可以做成按需模块。我记得微信早期表情包都内置在APK里，后来单独抽出来做成可卸载模块。

1.5 凭什么选SplitInstall而不是其他方案？

市面上也有其他动态加载方案，但SplitInstall有它的独特优势。我做个对比：

特性	SplitInstall	插件化（如RePlugin）	热修复（如Tinker）
官方支持	Google Play原生，无需额外权限	需自定义ClassLoader，存在兼容性问题	只用于修复bug，不能动态新增功能
模块卸载	系统级支持，真正释放存储	无法真正卸载，只能标记删除	不适用
安装体验	后台静默下载，用户无感知	需开发者实现下载和解压	补丁包需重启生效
合规性	符合Google Play政策，不存在隐私风险	存在被下架风险（动态加载代码）	补丁包需审核

1.6 事前准备：你需要知道的事

开始搞SplitInstall之前，有几个硬性条件必须满足。我曾经踩过坑，提前告诉你：

1. 必须使用Android App Bundle（AAB）发布。不支持普通APK。说白了你要在build配置里改成bundle格式。
2. Google Play控制台必须启用“Play 应用签名”。因为动态交付需要Google管理密钥签名每次分发。
3. 项目结构必须模块化：基础模块（app module）+ 多个功能模块（dynamic feature module）。不是随便什么代码都能拆。
4. 最低SDK版本：API 21+。Android 5.0及以下不支持SplitInstall。好在现在新设备基本都满足。

1.7 代码结构预览

下面是一个最小化的模块定义示例，你可以先感受一下。后续章节我会详细拆解每个配置：

// app/build.gradle
android {
    dynamicFeatures = [":feature_ar", ":feature_payment"]
}

// feature_ar/build.gradle
plugins {
    id 'com.android.dynamic-feature'
}
android {
    namespace 'com.example.app.feature.ar'
}
dependencies {
    implementation project(':app')
}

// 其他模块同理

嗯，看到dynamicFeatures和com.android.dynamic-feature这两个关键词了吗？这就是SplitInstall的入口。

1.8 避坑指南（过来人的血泪史）

我曾经在一个海外社交App的项目里踩过这些坑，希望你别重蹈覆辙：

• 模块依赖关系别搞成循环：基础模块不能依赖功能模块，但功能模块可以依赖基础模块。如果你不小心引入了依赖环，Gradle会报错，然后你得花半天梳理依赖箭头。
• 资源ID冲突：不同模块里的资源ID可能重复。建议给每个模块起独特的资源前缀，比如feature_ar_、feature_payment_。
• 测试陷阱：用真机测试时，每次重新安装会清除已下载模块。如果你不想每次都等几十秒下载，可以勾选“加速下载”或使用本地模拟。