一、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小程序。配置大致如下： ```json { "routes": [{ "bizCode": "points_mall", "mode": "miniapp", "miniAppId": "points-mall", "path": "/pages/home/index", "minAppVersion": "5.6.0", "fallback": "native://points/mall" }] } ``` 宿主侧只关心业务编码，不直接关心最终页面形态，源码中的判断逻辑大致如下： ```kotlin object BusinessRouter { fun open(context: Context, bizCode: String, params: Map = 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以后，建议将账号、定位、扫码、支付、打开原生页面等能力统一收敛成宿主能力网关。小程序只调用标准能力，宿主负责权限判断和能力实现。示意代码如下： ```kotlin class HostApiDispatcher { fun dispatch( appId: String, apiName: String, params: Map, 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%的用户命中新版本，观察打开成功率、首开耗时、接口错误率和业务转化，再逐步放量。 灰度配置示例： ```json { "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管理平台后，过期业务可以直接下架，入口和代码包都从线上策略中移除，不再污染主包。

七、首开体验：预加载要克制，离线包要少用

业务拆分为小程序后，主包体积会明显减小，但也会带来一个体验问题：用户第一次打开某个小程序时，需要下载代码包。 项目里按业务频率分层处理： | 业务类型 | 加载策略 | | :--- | :--- | | 高频业务 | 首页空闲后预加载 | | 中频业务 | 点击时加载，展示轻量加载态 | | 低频业务 | 完全按需加载 | | 弱网关键业务 | 少量配置离线包 | 预加载不要贪多。主包瘦下来以后，如果把所有小程序都预加载、都离线内置，相当于又把包体和资源压力加回来了。实际只给客服、预约、积分商城这类高频或体验敏感业务做预加载。可以这样设计一个预加载管理器： ```kotlin 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小程序容器和管理平台承载，主包才有机会长期保持在一个可控状态。