Android Instant Apps的目标是让用户点击一个链接就能直接进入应用中的某个具体功能，而不需要先到应用商店安装完整APK。实现这一体验的关键在于应用被拆分成多个可独立下载的模块，Google Play会根据用户访问的入口自动加载必要的模块。这种模块化加载机制和传统单体APK完全不同，它要求开发者在工程结构、Gradle配置、清单文件声明以及Deep Link路由上都做出适配。
Instant Apps的模块结构：Base模块与Feature模块
在传统的Android工程里，所有代码和资源通常集中在一个application模块中，最终打包成一个APK。Instant Apps则要求至少拆出一个基础模块，称为Base Feature Module，以及一个或多个功能模块，称为Feature Module。Base模块负责存放应用启动所必需的公共资源、主题、工具类、网络基础组件以及全局Application类。它不会单独被用户访问，而是作为其他功能模块的依赖被一起下载。
Feature模块对应具体的业务场景，例如视频播放、商品详情、新闻列表等。每个Feature模块都拥有自己的AndroidManifest文件、资源目录和代码，可以独立编译成一个小型APK。当用户点击某个深层链接进入商品详情页时，Google Play只会下载Base模块和商品详情对应的Feature模块，而不是整个应用。这样既能降低等待时间，也能减少用户因为下载体积过大而放弃的风险。模块之间的边界越清晰，按需下载的效果就越明显。
Base模块和Feature模块之间还需要一个可安装的应用模块。这个安装版模块使用普通的application插件，它把Base和所有Feature模块打包成完整的APK，用于常规的Google Play发布。同时，工程中还需要一个instantapp模块，它使用instantapp插件，负责描述即时体验版本包含哪些Feature模块。这样一套工程可以同时产出可安装APK和免安装的Instant App版本。
Gradle插件与Manifest分发配置
模块化加载的工程配置从Gradle开始。Base模块和Feature模块都需要使用com.android.feature插件，而不是传统的com.android.application插件。Base模块的build.gradle中需要声明baseFeature为true，Feature模块则不需要这个标记，但必须在dependencies里依赖Base模块。下面是一个Feature模块的Gradle配置示例：
plugins {
id 'com.android.feature'
}
android {
compileSdk 33
defaultConfig {
minSdk 23
targetSdk 33
versionCode 1
versionName "1.0"
}
}
dependencies {
implementation project(':base')
implementation 'androidx.appcompat:appcompat:1.6.1'
}
这段配置表明当前模块是一个可独立分发的Feature模块，它依赖Base模块提供的基础能力。Base模块的build.gradle中需要使用baseFeature true，并且不能包含applicationId。applicationId只能出现在可安装的app模块中，这与传统项目有明显区别。instantapp模块则使用com.android.instantapp插件，并通过implementation project依赖所有需要参与即时体验的Feature模块。
除了Gradle配置，每个Feature模块的AndroidManifest.xml还需要声明分发信息。Google Play依靠这些信息判断模块是否允许被单独下载，以及下载到设备后如何展示。清单文件中需要引入distribution命名空间，并在根节点下添加<dist:module>标签。常见的配置如下：
<manifest xmlns:android="http://schemas.android.com/apk/res/android"
xmlns:dist="http://schemas.android.com/apk/distribution"
package="com.ippipp.instantapp.video">
<application>
<activity android:name=".VideoActivity">
<intent-filter>
<action android:name="android.intent.action.VIEW" />
<category android:name="android.intent.category.DEFAULT" />
<category android:name="android.intent.category.BROWSABLE" />
<data
android:scheme="https"
android:host="www.ippipp.com"
android:pathPrefix="/video" />
</intent-filter>
</activity>
</application>
<dist:module
dist:instant="true"
dist:title="@string/video_module_title" />
</manifest>
其中dist:instant为true表示该模块可以被Google Play作为即时模块单独分发，dist:title用于在系统界面或加载提示中显示模块名称。intent-filter中的data字段则声明了哪些URL路径会触发该模块的加载。当用户点击符合规则的链接时，系统会根据这个声明找到对应Feature模块并下载执行。
Deep Link路由与运行时模块加载流程
用户点击一个Instant App链接后，系统首先会通过Google Play服务查询该链接对应的模块信息。如果设备上尚未安装相关模块，Google Play会在后台下载Base模块和目标Feature模块。下载完成后，系统解析目标Activity的intent-filter，匹配链接中的scheme、host和pathPrefix，最终启动对应的Activity。整个过程对用户来说像打开一个普通网页一样迅速。
为了让路由准确，开发时需要为每个可独立访问的入口配置清晰的Deep Link规则。同一个Feature模块内部可以有多个Activity，每个Activity可以通过不同的pathPrefix或pathPattern匹配不同的URL路径。例如视频模块可以配置/video/detail匹配详情页，/video/player匹配播放页。这样即使用户只下载了一个Feature模块，也能在该模块内部完成页面跳转，而不会跨模块请求未下载的内容。
运行时需要注意，Feature模块之间的直接依赖应当尽量避免。一个Feature模块如果依赖另一个Feature模块，那么加载前者时会把后者也一并下载，这会降低模块化的收益。正确的做法是把公共能力下沉到Base模块，Feature模块只依赖Base模块和外部库。对于跨模块的页面跳转，可以通过重新触发Deep Link来完成，而不是直接引用另一个模块的Activity类。这样能保证每个Feature模块真正独立。
模块划分、体积控制与启动性能优化
模块拆分粒度直接影响Instant App的启动速度和用户体验。如果Feature模块拆得过细，虽然单次下载量更小，但模块间依赖和数据传递会变复杂，容易出现重复代码和不一致问题。如果拆得过粗，单模块体积可能过大，用户等待时间变长，免安装的优势就会减弱。一般来说，可以按照用户最常访问的路径来划分模块，例如首页、搜索、商品列表、详情、下单等，核心路径模块尽量保持轻量。
Instant Apps对APK大小有限制，单个Feature模块和Base模块的下载大小需要控制在合理范围内。Google Play在分发时会压缩模块，但开发阶段仍然需要关注资源文件和依赖库的体积。图片资源可以放在服务端按需加载，避免打包进模块；大型SO库可以针对不同架构拆分，或者只保留必要架构。Base模块中不要塞入所有工具类和第三方SDK，只保留各模块都需要的核心能力。
启动性能还受到网络请求和模块下载时间的影响。Feature模块的Activity应当设计为轻量入口，先展示基础界面，再异步加载业务数据。如果模块初始化时同步执行大量网络请求或数据库操作，点击链接后的首屏时间会明显变长。可以把初始化逻辑拆分到后台线程，并在Base模块中提供统一的初始化框架。这样即使模块体积稍大，用户也能先看到界面，减少流失感。
调试Instant App时可以通过Android Studio的运行配置选择instantapp模块，并在设备上测试实际下载流程。需要注意，免安装功能依赖Google Play服务，模拟器或部分定制设备可能无法完整支持。开发时还可以使用本地模块加载工具模拟模块下载，验证路由是否正确。测试时应重点关注首次点击的冷启动时间、模块下载失败后的降级逻辑，以及用户取消下载后的状态恢复。只有把这些场景都覆盖到，模块化加载才能真正稳定地服务线上用户。
Android Instant Apps模块化加载Feature Module修改时间：2026-08-25 06:27:04