APP瘦身实战：从80MB+砍到15MB——基于小程序容器技术剥离APP非核心业务的实践分享

如何在不牺牲业务能力的前提下，把一个已经膨胀到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管理平台在这里不只是一个包上传后台，而是瘦身后的业务控制面。

一套完整的小程序发布链路通常是：

业务代码构建
  → 上传小程序包
  → 审核与安全检查
  → 配置发布内容
  → 灰度发布
  → 热更新生效
  → 数据观察
  → 全量 / 回滚 / 下架

这里的“发布内容”不只是代码包本身，还包括小程序版本、入口路径、适配宿主版本、权限范围、灰度策略、回滚版本和上下架状态。否则业务虽然从主包里拆出去了，但上线治理仍然会变成新的混乱点。

灰度发布是迁移期最重要的能力。比如积分商城从原生模块迁成小程序后，不建议第一天就全量切换。可以先让内部用户或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 代码地址