FinClip Blog / 产品博客

现在一个业务同时覆盖 iOS、安卓、鸿蒙和 PC，已经不算少见。客户查询、内容专区、工单处理、员工服务这些功能，在四类客户端里做的事情差不多，背后连接的也是同一套业务系统，但开发时经常会落进四个工程：移动端各写一套，鸿蒙再做适配，PC 端重新处理窗口和键鼠交互。

一两个模块这样做还能推进。业务多起来以后，同步成本会慢慢显出来。后端调整一个字段，几个客户端都要修改；产品新增一个状态，每一端都要补页面、埋点和异常处理；其中一端排期稍晚，用户看到的功能就会不一致。看起来是在维护四个客户端，团队花掉的时间却有很大一部分是在重复同一项业务改动。

小程序多端框架解决的是这类重复建设。页面、路由、表单、接口调用和业务规则保留在一套小程序工程中，iOS、安卓、鸿蒙和 PC 客户端分别接入自己的小程序运行时。系统权限、窗口、进程和设备能力仍...

其实现在很多团队都有自己的小程序，但这些小程序大部分都是运行在微信上的，今天分享一个新的技术解决方案：借助小程序容器的技术将这些小程序运行在自己的APP里。

特别是商城、预约、会员中心、业务查询，这些服务可能已经在微信里跑了几年，页面和接口都比较成熟，业务人员也已经习惯了小程序的开发和发布方式。

但等企业开始运营自己的APP，就需要看看，如何低成本的把这些服务搬迁到自有的APP中。

一种方案是：直接重写成原生页面，Android和iOS都要投入人力，测试、发版和后续维护也会多出两套工作。换成H5能少写一些界面，但原有小程序的组件、路由、分包和生命周期很难原样搬过来。更麻烦的是，微信小程序还要继续维护。一个需求改动，可能要同时照顾微信、APP原生和H5，业务越多，重复建设越明显。

那还有一个技术方案：...

到了2026年，国内各个行业的APP运营已经从增量市场变成了存量市场，很多APP的用户规模已经逐步稳定下来，从前期的野蛮生长到现在的精细化运行，运营团队也开始会希望加入更多内容和服务：资讯、直播、活动报名、会员权益、票务商城、本地生活、在线预约，甚至合作伙伴提供的专业工具。需求清单很快就能列出几十项，但企业很难把这些服务全部重新开发一遍。

其实不少合作方手里已经有现成的H5页面、微信小程序或原生SDK。单独接入一两个服务时，客户端团队可以逐项处理登录、页面跳转和权限申请，工作量还算可控。但随着接入数量增加后，每家合作方不同的技术栈和上线节奏都会影响宿主APP。一个页面调整可能要重新发版，某个服务出现故障时也缺少统一的关闭和回退手段。

今天方向一个基于小程序技术的解决方案：小程序容器技术可以先在APP内建立统一运行环境，再让...

很多公司原来只维护 iOS 和 Android 两套客户端，团队之间已经形成了比较稳定的协作方式。但随着要开发鸿蒙客户端之后，同一个需求开始出现三份排期：三端分别设计页面、接入接口、处理权限、联调测试，再各自构建和发布。

很多时候一项查询、预约或会员服务，业务流程没有变化，开发工作却被拆成三条线。产品改一个字段，三个工程都要跟进；某一端进度慢几天，功能就很难同步上线。等版本越来越多，团队还要长期处理页面差异、接口差异和历史版本兼容。

现在市面上有很多跨端开发的技术方案，但更偏向于从零开始构建APP的形式，对于存量APP来说：多端 APP 更实用的做法，是先把业务分层，再为每一层选择合适的技术。账号、安全、消息和系统能力保留在原生宿主；变化较慢、与 APP 生命周期绑定较深的页面，可以继续用原生或现有跨端框架；更新频繁、流程...

大部分APP在运行几年后，主包通常都会一点点变重，可能刚开始只是加一个会员中心，后来又陆续接入商城、客服、活动专区、办事工具和合作方服务。每个需求单独看都不算大，但经过几年之后，图片、组件、第三方依赖和初始化任务全都留在主工程里，安装包体积随之上涨。

包体变大还只是表面现象，更麻烦的是更新，可能一次普通的活动改版，业务侧可能只换了几张图片、调整了两处页面逻辑，客户端团队却要重新拉分支、合并代码、构建安装包、跑集成测试，再等待应用市场审核。改动只发生在一个短期活动里，发布流程却把整套 APP 都带了进来。

图片压缩、无用代码清理和原生模块化当然要做，但它们解决不了业务交付仍然绑在主包里的问题。资源压缩完，新业务还会继续加入；工程模块拆开了，发布时依然要打进同一个安装包。要让 APP 长期保持可维护，除了清理资源，还要重新划分...