如何在不牺牲业务能力的前提下，把一个已经膨胀到80MB+的APP重新压回15MB左右？
最近复盘了一个比较典型的APP瘦身场景：因为主包里塞了太多非核心业务，活动页、积分商城、客服中心、问卷工具、办事预约、内部报表都跟着宿主APP一起打包。结果每次发版都很重，安装包越来越大，测试范围也越来越不可控。
后来没有继续在主包里做极限压缩，而是把业务承载方式拆开：宿主APP只保留账号、首页、消息、支付、安全等核心能力，非核心业务通过FinClip小程序容器承载，再用小程序管理平台完成上传、审核、灰度、热更新、回滚和上下架。
这次复盘里，最有效的动作不是调某个压缩参数，而是重新划业务边界：哪些能力必须留在主包里，哪些能力可以交给小程序容器和管理平台。
一、APP为什么会从30MB涨到80MB
APP包体变大，通常不是某一个文件导致的，而是业务多年叠加出来的结果。
一开始主工程很干净，只有登录、首页、消息、用户中心这些核心模块。后来业务部门陆续提需求：会员中心要上线，积分商城要做活动，客服中心要接入工单，运营要做节日活动页，内部团队还希望在APP里放一些报表和工具。
每个需求单独看都合理，但它们都会进入主包。 但麻烦的是，这些功能的使用频率并不一样。登录和首页每天都用，活动页可能只存在两周；积分商城有人常用，问卷工具可能一个月才打开一次；客服中心需要稳定在线，但不一定要和宿主APP每次一起发版。
所有业务都长在原生工程里之后，问题会一起出现：
- 用户下载的是完整主包，不管他是否使用那些低频功能；
- 业务改一个活动页，也要跟着宿主APP走完整发版流程；
- 过期资源如果没有及时清理，会长期留在安装包里；
- 不同业务线引入自己的SDK，依赖开始重复；
- 测试团队每次都要回归更多页面，发版风险变高。
这种情况下，只靠资源压缩、删除无用代码、开启混淆，收益有限。更关键的是把“必须随APP安装”的能力和“可以按需加载”的业务分开。
二、改造思路：主包只保留核心，小程序承载非核心业务
架构调整后，宿主APP从一个“大而全”的业务集合，变成“Native底座+FinClip小程序容器+小程序管理平台”的结构。
Native层负责稳定不变的核心能力，包括账号体系、首页框架、消息推送、支付通道、安全能力和基础路由。FinClip小程序容器负责在APP内运行小程序。小程序管理平台负责小程序的上传、审核、版本、灰度、热更新、回滚和上下架。
改造前的结构大概是这样：
宿主APP
├── 登录/账号
├── 首页/导航
├── 消息/推送
├── 积分商城
├── 活动页
├── 客服中心
├── 办事预约
├── 问卷工具
├── 报表工具
└── 大量资源和三方依赖
改造后的结构变成：
宿主APP
├── 登录/账号
├── 首页/导航
├── 消息/推送
├── FinClip小程序容器
├── 宿主能力网关
└── 基础安全能力
小程序管理平台
├── 积分商城小程序
├── 活动页小程序
├── 客服中心小程序
├── 办事预约小程序
├── 问卷工具小程序
└── 报表工具小程序
这样拆完之后，主包只承担“底座”职责。业务功能不再全部预置到APP里，而是以小程序包的形式独立管理。用户访问某个入口时，再由容器按策略加载对应小程序。
从包体角度看，原来所有用户都要下载的业务代码和资源，被拆成了按需加载的小程序包；从发版角度看，非核心业务可以独立发布，不再占用宿主APP的发版窗口。
三、哪些业务适合用小程序的形式做
不是所有业务都应该拆出去。很多功能还是原生的性能更好，如果一味的减少包的大小，把核心链路也拆得支离破碎，包体小了，用户体验却变差。
实践里可以按两个维度判断：一是业务是否独立，二是变化是否频繁。
| 业务类型 | 是否适合迁移 | 判断原因 |
|---|---|---|
| 登录、账号、安全校验 | 不适合 | 属于宿主基础能力 |
| 首页主导航 | 谨慎迁移 | 影响首屏和主体验 |
| 支付、强风控流程 | 谨慎迁移 | 权限和安全要求高 |
| 活动页、运营页 | 适合 | 更新频繁，生命周期短 |
| 积分商城、会员权益 | 适合 | 业务相对独立，资源占比高 |
| 问卷、客服、办事预约 | 适合 | 低频但流程完整 |
| 报表、内部工具 | 适合 | 面向特定用户群，可按需下发 |
这类拆分有一个基本原则：宿主APP负责账号、导航、基础能力和安全边界；小程序负责独立业务模块。只要业务能独立闭环，又不依赖复杂原生能力，就可以优先进入迁移清单。
实际落地时，不建议第一批就迁十几个模块。比较稳的做法是先选一个低频但完整的业务，比如问卷工具、活动页或积分商城。先跑通容器接入、路由切换、宿主API、灰度发布和回滚，再逐步迁移其他模块。
四、技术路径：先接容器，再做路由灰度
宿主APP集成FinClip之后，就具备了运行小程序的能力。迁移能不能平滑，不只看“能不能打开小程序”，还要看入口如何切换、失败如何兜底、灰度如何控制。
入口不要直接写死成某个小程序ID。项目里做了一层业务路由配置，由后台决定当前入口走原生页面还是FinClip小程序。
配置大概长这样：
{
"routes": [
{
"bizCode": "points_mall",
"mode": "miniapp",
"miniAppId": "points-mall",
"path": "/pages/home/index",
"minAppVersion": "5.6.0",
"fallback": "native://points/mall"
}
]
}
宿主侧只关心业务编码，不直接关心最终页面形态：
object BusinessRouter {
fun open(context: Context, bizCode: String, params: Map<String, String> = emptyMap()) {
val route = RouteConfigRepository.find(bizCode)
if (route == null) {
HostRouter.open(context, "native://home", params)
return
}
if (route.mode == "miniapp" && AppVersion.current().isAtLeast(route.minAppVersion)) {
FinClipRuntime.open(
context = context,
appId = route.miniAppId,
path = route.path,
query = params
)
} else {
HostRouter.open(context, route.fallback, params)
}
}
}
这里的FinClipRuntime.open是项目里对FinClip打开小程序能力的一层封装。真实项目里需要按SDK版本、初始化方式和鉴权方式做适配。示例里也加了配置缺失时的原生兜底，避免路由配置异常导致入口崩溃。
这层路由的价值在迁移期很明显。今天可以让10%的用户进入小程序版本，观察数据后再放到50%、100%；如果打开失败率升高，直接把入口切回原生页面。迁移过程不再是一次性切换，而是可灰度、可回退。
五、宿主能力要统一开放，避免SDK重复进入主包
很多APP包体膨胀，和三方能力重复接入有关。一个模块接扫码，一个模块接定位，一个模块接相册，最后每条业务线都带着自己的依赖进主工程。
迁到FinClip以后，建议把账号、定位、扫码、支付、打开原生页面等能力统一收敛成宿主能力网关。小程序只调用标准能力，宿主负责权限判断和能力实现。
示意代码如下：
class HostApiDispatcher {
fun dispatch(
appId: String,
apiName: String,
params: Map<String, Any?>,
callback: HostApiCallback
) {
if (!PermissionCenter.check(appId, apiName)) {
callback.fail(code = 403, message = "permission denied")
return
}
when (apiName) {
"getUserInfo" -> runCatching { UserInfoApi.handle(params, callback) }
"scanCode" -> runCatching { ScanCodeApi.handle(params, callback) }
"chooseImage" -> runCatching { ChooseImageApi.handle(params, callback) }
"openNativePage" -> runCatching { OpenNativePageApi.handle(params, callback) }
else -> {
callback.fail(code = 404, message = "api not found")
return
}
}.onFailure { error ->
callback.fail(code = 500, message = error.message ?: "host api error")
}
}
}
这一步对瘦身也有直接帮助。能力由宿主统一提供，小程序不再各自引入一套依赖；权限也可以集中管控，每个小程序能调用什么API，由宿主和管理平台共同决定。
六、小程序管理平台是瘦身后的控制面
把业务代码移出主包，只完成了第一步。后面更重要的问题是：小程序怎么发布，谁来审核，哪些用户先看到，新版本怎么热更新，出问题怎么回滚，过期活动怎么下架。
FinClip管理平台在这里不只是一个包上传后台，而是瘦身后的业务控制面。
一套完整的小程序发布链路通常是：
业务代码构建
→ 上传小程序包
→ 审核与安全检查
→ 配置发布内容
→ 灰度发布
→ 热更新生效
→ 数据观察
→ 全量 / 回滚 / 下架
这里的“发布内容”不只是代码包本身，还包括小程序版本、入口路径、适配宿主版本、权限范围、灰度策略、回滚版本和上下架状态。否则业务虽然从主包里拆出去了，但上线治理仍然会变成新的混乱点。
| 发布对象 | 管理内容 |
|---|---|
| 小程序包 | appId、版本号、包地址、签名、校验信息 |
| 页面入口 | 首页路径、业务入口、启动参数、fallback |
| 适配范围 | 宿主APP版本、系统版本、端类型 |
| 权限范围 | 宿主API、用户信息、设备能力、网络能力 |
| 发布策略 | 全量、灰度、指定地区、指定用户群 |
| 回滚策略 | 上一稳定版本、强制回滚、下架处理 |
灰度发布是迁移期最重要的能力。比如积分商城从原生模块迁成小程序后，不建议第一天就全量切换。可以先让内部用户或1%用户命中新版本，观察打开成功率、首开耗时、接口错误率和业务转化，再逐步放量。
灰度配置示例：
{
"appId": "points-mall",
"version": "2.3.0",
"releaseType": "gray",
"grayRules": {
"percentage": 10,
"regions": ["shanghai", "shenzhen"],
"minHostVersion": "5.6.0"
},
"fallbackVersion": "2.2.1"
}
热更新解决的是“业务更新如何到达用户设备”。宿主APP集成FinClip运行时后，用户打开某个小程序时，运行时可以向管理平台检查版本策略。如果当前缓存版本不是最新命中版本，就下载新的小程序包，完成签名与完整性校验后再切换。整个过程不需要用户重新安装宿主APP。
热更新链路至少要包含版本检查、包下载、签名校验、本地缓存、下次启动切换和异常回退。这里最重要的是校验和回退。小程序包来自远端下发，必须确保来源可信、内容未被篡改；新版本一旦打开失败，也要能回到上一稳定版本，而不是把用户卡在白屏里。
上下架管理也容易被低估。很多导致APP变重的业务，本质上都是“临时业务长期留存”：活动结束了，资源还在；工具页没人用了，入口还在；某个地区的试点结束了，代码还在。迁到FinClip管理平台后，过期业务可以直接下架，入口和代码包都从线上策略里移除，不再污染主包。
七、首开体验：预加载要克制，离线包要少用
业务拆成小程序后，主包会明显变小，但也会带来一个新的体验问题：用户第一次打开某个小程序时，需要下载代码包。
项目里按业务频率分层处理：
| 业务类型 | 加载策略 |
|---|---|
| 高频业务 | 首页空闲后预加载 |
| 中频业务 | 点击时加载，展示轻量加载态 |
| 低频业务 | 完全按需加载 |
| 弱网关键业务 | 少量配置离线包 |
预加载不要贪多。主包瘦下来以后，如果把所有小程序都预加载、都离线内置，等于又把包体和资源压力加回来了。实际只给客服、预约、积分商城这类高频或体验敏感业务做预加载。
object MiniAppPreloadManager {
private val preloadList = listOf(
"points-mall",
"customer-service"
)
fun preloadAfterHomeReady() {
if (!NetworkStatus.isWifiOr5G()) return
preloadList.forEach { appId ->
FinClipRuntime.preload(appId)
}
}
}
离线包也一样，只适合少量关键场景。比如客服入口、紧急服务、弱网办事入口可以考虑离线预置；活动页、问卷、临时工具页更适合远程按需加载。
包体从80MB+降到15MB，通常不是靠一个技巧完成的，而是几类动作叠加：非核心业务迁到FinClip小程序，主包移除大量业务代码和资源；宿主能力统一开放，避免业务线重复接SDK；活动资源远程化，清掉assets里的长期沉淀资源；离线包克制使用，避免反向撑大主包；CI包体门禁，防止后续版本重新膨胀。
收益也不只是安装包变小。主工程变轻后，构建速度、测试范围、发版风险都会下降；业务小程序独立发布后，活动页、工具页、客服页这类模块不需要再等待宿主APP发版；灰度、热更新、回滚和上下架放到FinClip管理平台后，线上风险也更容易被平台化管理。
APP瘦身拼的不是压缩工具，而是业务边界。核心能力留在宿主，变化快、低频、独立的业务交给FinClip小程序容器和管理平台承载，主包才有机会长期保持在一个可控状态。
感兴趣的话可以在Gitee上详细了解：Gitee 代码地址
