赵帅起

如果原生APP已经有了成熟的账号体系、导航和业务接口，前端团队又交付了一套 React 或 Vue 页面。现在希望把这些页面接进APP，并让后续页面改动独立发布，今天分享一下Ionic Portals 和 FinClip的技术差异对比～ 迁移时，可以沿着一个页面的执行过程往下看：Web 产物放在哪里，原生端怎样打开它，JavaScript 怎样调用宿主，下载新资源后又在什么时候切换。今天基于安卓端的系统，来分享一下这些接口分别落在哪一层。 保留现有 Web 页面，可以直接比较两种 H5 接入路径 Portals 基于 Capacitor，为原生 APP 提供增强 WebView。一个 Portal 对应一组 Web 资源和运行配置，页面仍由 Web 框架渲染，也不要求界面必须使用 Ionic Framework。 FinClip 除了运行小程序，也支持将现有

今天分享一下保险APP接入小程序的一种做法。APP已经用了Flutter，保单列表、客户登录和个人中心也都已经有了，现在准备增加一项保单服务预约。客户可以从某张保单进入，选择服务网点和时间，填写想咨询的问题，提交后还能在APP里查看预约记录。 如果继续按原来的方式开发，这项服务可以直接写进Flutter工程。不过，预约页面后续还会增加咨询类型、补充表单字段，调整办理提示。每次改页面，客户端团队都要跟着开发、测试和发版，这些业务调整就会一直占用主工程的排期。 其实，Flutter工程也可以接入FinClip小程序。沿用现有APP，让小程序来承接新增预约服务，再接好登录和导航，就可以利用已有的客户端能力增加服务入口。这样一来，Flutter继续负责APP主界面，FinClip负责小程序运行，预约团队维护自己的业务页面，三者可以在同一个APP里配合工作。 沿用Flutter主工程，新增服务按小程序交付 当客户打开保险APP，看到的首页、保单卡片和底部导航仍然由Flutter实现。点击“保单服务预约”后，APP可以通过FinClip的Flutter SDK打开小程序，再通过启动参数，

某省级政务服务APP准备增加鸿蒙客户端，面临最大的问题不是如何从零开发一个鸿蒙APP，而是如何复用已有的资源，类似于社保、医保、税务、企业服务、办事预约、材料提交、预约这些业务在iOS和安卓端已经运行，页面和业务接口也经历过多轮调整，如果全部重新开发，技术层面是一方面，更麻烦的是还需要重新对接一边，需要花费大量的时间调试成本。 例如办事预约来说，用户无论是iOS、安卓还是鸿蒙APP，都是要选择事项、查看可预约时间、填写信息，再拿到预约结果。事项规则和办理流程没有跟着操作系统改变。如果能够把已有业务继续用起来，那鸿蒙开发团队的精力都可以放在新客户端打磨体验上。 今天分享一个新的技术路径：借助FinClip复用已有的小程序、H5页面：鸿蒙APP接入小程序运行能力，业务团队沿用已有页面与逻辑，再把登录、导航等客户端能力接好，无需二次开发就能快速完成APP的上架工作。 复用已有页面与接口，减少鸿蒙端重复开发 预约页面上的事项名称、办理地点、日期选择和表单校验，已经承载了不少业务积累。比如某个大厅周末不开放、某类事项需要补充联系人，这些规则散落在页面逻辑和后台配置里。重新做一套鸿蒙原生

在不少团队里，一个功能从开发完成到用户用上，要经历客户端联调、整包构建、回归测试、签名和应用市场审核等环节。功能本身可能只是改个活动页、增加一张表单，发布链路却要和登录、支付、导航这些主工程能力一起走完。 当业务模块和客户端版本绑在一起，团队花在“等版本”的时间会越来越多。iOS、Android、鸿蒙各有构建和验证流程，同一项业务的页面调整要跟着多端重复走一遍。单纯压缩构建时间能解决一部分问题，更影响上线节奏的，常常是业务改动必须经过宿主 APP 的整条发布链路。 要改变这条链路，先要分清哪些变化必须进入客户端，哪些业务可以独立交付。小程序容器提供了一种拆分方式：宿主 APP 提供稳定的运行环境和公共能力，变化较频繁的业务以小程序模块运行，再由管理平台控制版本和发布。页面和业务逻辑可以脱离主工程独立更新，宿主能力变化仍按客户端版本发布。 发版时间通常花在依赖关系上 客户端版本慢，原因往往不在编译器。一个看似独立的活动页面，如果直接写进 APP 主工程，就会与宿主的页面路由、公共组件、登录态、埋点和构建流程形成依赖。页面更新时，客户端团队要确认兼容范围；涉及公共模块时，相关

虽然很多城市已经暂停了APP开发的项目，当对于已有的资源开始无法得到充分的利用，每个部门前期开发了一批小程序、H5页面，包括社保、公积金、医保、停车、文旅、教育等服务都有，当有的来自微信小程序，有的是部门早年建设的 H5 页面，还有一些业务已经做成原生页面，却没有被纳入统一的服务目录。 今天分享一下如何将这些已有的资源服务，整合为一个政务APP，通过一个入口就能够实现访问所有的服务。不同部门的服务由不同团队维护，后台系统和发布节奏也各不相同。如果只是把链接堆到首页，用户依旧会反复登录、来回跳转；如果把所有页面重新写进 APP 主工程，后续每次政策调整和页面修改都要等待客户端发版，原本分散的问题会变成一套更大的协作问题。 统一移动政务门户需要解决的，是服务资源如何共存、用户身份如何贯通、不同技术形态如何保持一致，以及上线以后由谁管理这些服务。小程序容器可以承担其中的运行层，但它要和宿主 APP、H5 接入层、小程序管理平台以及原有业务系统一起设计，单独集成一个 SDK 并不能自动解决门户建设的问题。 统一门户先统一入口和身份 门户 APP 的职责不应该是重新实现所有部门业务。它

员工用 AI 起草了一份采购申请，材料整理得更快了，接下来却仍要打开采购系统填表，到预算系统查额度，再把附件发给负责人确认。如果字段不一致、材料不齐，还得在群里来回补充。个人处理文档的时间缩短了，一项工作从发起到办完，依然可能卡在系统切换和部门交接上。 企业推进 AI 应用时，很容易先从写作、检索、总结等个人工具入手。这些能力有直接的使用价值，但一项工作通常需要多个人、多个系统共同完成。员工各自拥有 AI 助手以后，谁把整理好的信息送进业务系统，谁接收下一步任务，处理结果又回到哪里，仍然需要协同办公平台承接。 企业需要升级的，是能够让 AI 参与业务办理的协同能力。已有办公 APP 可以继续使用，OA、ERP、财务和人力系统也可以保留，在原有入口中增加 AI 交互、业务调用和结果反馈。判断是否需要建设新的工具，应该看现有平台能否接住这些能力，以及能否让各部门持续提供可复用的服务。 从个人效率延伸到业务流程效率 个人使用 AI 时，

公司已经做好的会员服务小程序，能不能同时放进 iOS、安卓和鸿蒙 APP？对业务团队来说，页面、接口和办理流程已经有了，新增一个客户端，当然希望继续使用原来的成果。按三个平台分别重写页面，后续每次修改活动规则、增加表单字段，还要再跟着维护三遍。 借助小程序容器，可以把业务页面和逻辑保留在同一套小程序代码中，由三个 APP 分别嵌入对应的小程序 SDK，提供加载和运行环境。客户端团队完成宿主接入，业务团队继续开发小程序，管理平台负责版本上传和发布。同一项业务就能进入不同系统的 APP，后续更新也有了统一的管理入口。 以 FinClip 为例，可以让三个 APP 打开同一个测试小程序，再逐步接入登录、支付等业务能力。接入示例使用官方 SDK 接口，并补充项目侧状态判断和错误处理；尖括号中的版本、凭据和服务地址需要替换成项目配置。代码放入已有宿主工程，省略工程结构及部分导入声明。 小程序与三个客户端的运行关系 小程序代码包含页面结构、样式、业务脚本和资源文件。容器在 APP 内加载代码包，

一个报销功能，从手机扩展到电脑以后，业务规则其实没有变：填写费用、上传凭证、选择审批人，再提交申请。但如果各端分别开发，表单、校验和附件处理就要在 iOS、安卓、鸿蒙、Mac 和 Windows 客户端各做一次。以后增加一个费用类型，几支客户端团队还要同步修改，功能越多，重复维护的工作越明显。 小程序容器把业务开发与系统适配分开了。业务团队用小程序编写页面、交互和数据处理逻辑，各端 APP 集成对应的容器 SDK，为同一套业务代码提供运行环境。手机与电脑之间的窗口、文件、权限和原生接口差异，由容器与宿主适配层集中处理，业务模块就能持续复用。 以 FinClip 为例，其小程序运行能力覆盖 iOS、Android、鸿蒙，以及 macOS、Windows 等桌面环境。跨端的共同部分是小程序代码与开发接口，各系统使用各自的 SDK 集成。理解这层关系，

市民办理一项业务，可能先在公众号里阅读办事指南，进入某个部门的小程序预约，再到另一个网页查询结果。每个服务单独都能用，连起来却要记住好几个入口。政务 APP 如果能够把已有服务接过来，用户就可以围绕“要办什么事”找功能，不必先弄清楚服务由哪个部门建设、运行在哪个平台。 对门户建设团队来说，各部门已经积累了不少可用的页面和业务系统。预约、查询、申报等功能，有些做成了微信小程序，有些是 H5 页面，背后还有不同供应商持续维护。把它们重新开发成原生页面，既要重复实现已有功能，也会把后续更新集中到 APP 主工程。保留存量服务，让门户具备共同的接入、运行和管理能力，更容易把建设投入用在统一体验与持续运营上。 小程序容器提供了这样的整合方式。以 FinClip 为例，在自有 APP 内集成容器 SDK，可以加载业务小程序，也能承载 H5 应用；服务端管理平台负责应用信息、版本和发布。各部门继续维护业务，门户团队集中建设服务入口与公共能力，已有资源便有了共同的运行载体。

今年，很多APP运营团队都有降本增效的需求：希望把企业自己的部分业务转成独立小程序，放进自有 APP 里运行。内部服务运营起来以后，再引入外部小程序，让合作方入驻并持续维护自己的服务。 对企业来说，内部业务拆分与外部生态接入可以采用同一套技术架构。活动、会员、商城等业务先从主工程中独立出来，拥有各自的开发和发布节奏；合作方加入后，也按相同规范提供小程序。APP 团队维护公共能力，业务团队维护功能，运营人员通过后台管理上线与分发，服务增加时不必反复调整整套客户端工程。 FinClip 通过小程序容器 SDK、开发者工具和小程序管理平台，把开发、运行与运营管理连接起来，支持企业从自有业务的小程序化，逐步扩展到多团队、多来源服务共同运营的超级 APP。 业务小程序化与主工程解耦 企业可以把活动专区、会员权益、在线商城、预约报名等业务封装成独立小程序。每个小程序有自己的页面、交互逻辑和代码包，原有业务系统继续提供数据和接口。客户端集成 FinClip 小程序容器后，就具备了加载和运行这些业务模块的能力。 以活动专区为例，活动列表、详情、报名表单和结果页面可以由一个小程序承接。活动团

员工准备出差时，可能需要先到制度库确认差旅标准，再打开 OA 填写申请，等审批通过后进入另一个系统处理预订与报销。集团已经有门户，也汇集了各系统入口，但具体办事时，员工仍要判断该用哪个系统，把姓名、部门、项目和出行信息重复填进去。 在门户里加入 AI 助理，可以让员工直接描述要办的事。不过，从“帮我查一下差旅制度”到“帮我提交出差申请”，中间还隔着业务接口、身份权限、表单确认和审批流程。企业内部 AI+超级 APP 的建设，需要把这些操作接起来，同时保留员工熟悉的页面和原有业务系统的处理规则。 借助 FinClip，可以用小程序承载门户内的业务页面，让手机 APP、PC 桌面及适配的信创终端复用业务服务。AI 助理负责理解需求、组织查询与办理步骤，小程序提供表单、详情和操作界面，业务系统继续执行审批和数据处理。员工可以通过菜单打开服务，也可以从对话进入同一项业务。 统一门户与业务服务组织 集团门户通常需要同时容纳新闻通知、制度资料、

一个部门准备把预约服务接入政务 APP，供应商交来了页面和接口，门户团队却还需要逐项确认：登录接哪套账号，服务放在哪个栏目，谁验收，谁发布，后续换了维护单位又由谁接手。接入过程中商定的规则，如果只留在会议纪要和联调群里，下一家供应商进场时，往往还要重新问一遍。 门户持续增加服务后，客户端团队很容易变成所有部门的集成窗口。即使页面已经开发完成，也得等人安排联调、配置入口、核对版本。建设开放平台，就是把反复发生的接入动作整理成固定的交付规范和线上流程，让部门、供应商、门户运营方能够在各自的权限内完成工作。 政务 APP 的开放平台面向经过授权的建设单位和服务提供方。允许供应商提交小程序，并不代表向其开放全部政务数据，也不代表获得了直接上线的权限。服务能够接进来，责任和操作范围也要跟着确定下来。 部门归属与供应商授权 一个供应商可能同时维护多个部门的服务，一个部门也可能有几家供应商参与建设。如果只按公司创建账号，再把小程序都放到公司的名下，合同结束时，服务资产、代码版本和历史记录就容易跟着供应商走。 平台应分别记录业务归属部门、技术维护单位和具体操作人员。部门确认服务内容及办理规

设计小程序容器 SDK，可以沿着一次启动请求拆解：宿主传入小程序标识，容器选择兼容版本、校验代码包、创建执行上下文和页面，再把脚本调用转发给原生能力。跨端复用能否成立，取决于各端对包格式、组件、API 和生命周期是否遵守一致的约定。只做到 JavaScript 能执行、页面能显示，还不足以支撑同一业务在多个客户端稳定运行。 以逻辑层与视图层分离的架构为例，工程设计可以围绕包加载、消息通信、隔离边界和平台适配展开。具体采用什么引擎、如何划分线程和进程，可以不同；接口行为与资源归属需要明确，不能依赖某个终端的默认实现。 代码包加载与版本一致性 启动时不能只按小程序标识取最新包，还要匹配运行时、基础库和宿主扩展能力。业务包调用了新增接口，旧客户端即使能解析页面，也可能在操作中途失败。包元数据应记录最低运行要求，加载器在执行脚本前完成检查，不兼容时选择仍被允许使用的旧版本，或返回明确的升级提示。 下载后的资源应先进入暂存目录，完成签名验证、内容摘要比对和解包检查，再切换为可用版本。摘要用于发现内容变化，来源可信还要依赖受信任的签名或分发机制。解包需要限制展开后的体积，并检查规范化路径

今天分享一下，如何借助小程序多端运行框架，来进行团队运营赋能，降低开发成本，提高运营效率。 典型的场景是：APP里的会员活动完成页面开发后，运营还要确认客户端什么时候发版，测试还要检查旧版用户能不能参加，遇到活动规则临时调整，又得找开发补一次修改。只维护一个客户端时，几个人沟通一下也能推进；同时覆盖 iOS、安卓和鸿蒙以后，同样的问题就得分头确认。 拿一场周五上线的活动来说，周四验收完页面，周五能不能开，取决于入口是否准备好、用户手机上的版本是否支持，以及领取接口有没有一起就绪。任何一处没跟上，运营都得回头协调。时间花在了等确认、补测试和核对版本上。 借助小程序多端框架，团队可以把适合复用的活动页面和交互逻辑做成独立小程序，由各端的容器加载，再通过管理后台安排发布和日常调整。活动仍然要开发、测试和审核，但不必每改一次页面，都重新组织一轮客户端发版。 多端复用与业务独立更新 企业自己的 APP 集成小程序容器后，就有了加载小程序页面、样式、脚本和配置的运行环境，用户点开会员活动，看到的仍然是 APP 内的业务页面。 采用多端方案，客户端团队要先在各端接入受支持的容器，把登录

金融和政务类APP 接入第三方服务时，最核心需要关注的就是如何保证APP的安全稳定：业务方希望尽快把合作伙伴的服务接进来，安全团队拿到手的是一个编译好的代码包和一份对方出具的承诺函，翻遍自己的审查清单，发现没有一条适用。 代码是人家的，跑在自己的APP 里，出了问题算谁的。安全团队手里有标准，但标准在这类场景里失效了：要源码审计，第三方不可能给；做漏洞扫描，对方的服务每周都在更新，这周审完的内容下周就变了样。审查一个持续迭代的黑盒，用静态的手段永远追不上。 今天分享一种基于沙箱的解决方案，看看小程序多端框架的安全沙箱，是怎么把审查对象从"别人的全部代码"收敛成"暴露出来的接口边界"的。 两种接入方式都缺一道清楚的边界 按照传统的接入方式，第三方服务进 APP 通常有两条路，两条路在安全评审上都走得艰难。 首先是SDK 集成，第三方的代码直接编译进 APP 主工程，拿到的是和自有代码同级的系统权限，安全团队要审的实质上是对方的全部实现，而对方出于商业考虑往往只给文档不给源码，评审只能靠对方填表。 然后是H5页面的方式，审查负担小了，但管控也基本放弃了，页面加载什么内容、请求

原生鸿蒙的用户越来越多，如何开发鸿蒙APP，成了很多移动开发团队摆在桌面上的问题。iOS和安卓的工程已经很成熟，形成了稳定的运营方案，现在凭空多出一个端，ArkTS要学、工程要新建、应用市场要单独上架，第一件事自然是想"怎么把鸿蒙版本做出来"。 但和团队实际聊下来会发现，开发只是眼前这关，后续如何长期维护才是大家反复提到的问题。 鸿蒙版本做出来之后，它就和 iOS、安卓、微信小程序一样，变成一个需要持续维护的端：功能要同步迭代，bug 要同步修，发版要同步走。多数团队的解法还是堆人，四个客户端四套代码四个节奏，功能对齐全靠项目管理硬扛。业务跑得越久，维护的包袱越重。 今天分享一套基于小程序多端框架的解法，看看怎么把"为鸿蒙单独立项"变成"一份代码四端运行"，同时把长期维护的成本也一并压下来。 新增一个鸿蒙端，需要增加多少运营压力 按照传统的原生开发方式，在 iOS、安卓、微信小程序之外再补一个鸿蒙端，通常需要考虑三个方面。 首先是人力按端翻倍，每个端一套语言一套工程，iOS 用 Swift，安卓用 Kotlin，

在政务移动门户的项目里，永远会遇到一个非技术，但需要技术来解决的问题：单纯的 APP 开发没有太多的技术门槛，原生页面、接口联调、上架发版，这些事任何一家成熟的开发团队都能做，但需要花费大量的时间去做跨部门、跨供应商的对接工作。 一个政务移动门户APP要整合十几个甚至几十个部门的服务。这些服务可能由不同供应商建设，形态也不一样：有的是微信小程序，有的是 H5 页面，有的还挂在公众号菜单里。对接的成本大头不在写代码，更重要的是对齐：排期要对齐，接口规范要对齐，账号体系要对齐，验收标准也要对齐。每接进来一个部门，都要重新走一遍流程。/ 今天分享一套基于小程序运行底座的解法，将"逐个对接"怎么变成"统一接入"。 对接成本主要有哪些 按照传统的开发方式，如果需要引入一个部门的服务进入APP，通常需要考虑三个部分： 首先是逐家联调，每家供应商一套接口风格、一套鉴权方式，门户团队要分别做技术评估、安全审查和联调测试，再各自走一轮验收。部门越多，这部分工作量越是线性上涨。 然后是形态不一，小程序、H5、原生页面混在一个 APP

每个省市都有自己政务APP门户化建设的需求，核心还是希望让市民需要一个入口，就能办完各个部门的事情。 但现实情况是，市民希望入口集中，不用在小程序、公众号和H5页面之间来回切换、反复登录；而各个业务部门那边却各有各的现实，服务由不同供应商开发，迭代节奏也不一样，有的事项一年只改几次，有的专区每周都在调整。如果把几十项服务全部收进 APP 主工程，所有部门的页面变更都得排队等客户端版本，改一个表单字段也要等发版窗口。 难的不只是APP开发，更需要关注如何资源整合 如果只是客户端开发，做一个政务 APP 并不难。难的是建成以后，怎么长期容纳多个部门的服务而不失控。 通过原生方式集成，各部门的业务代码会持续汇入主工程。一方面APP包会越来越大，但更麻烦的在协作上：任何部门改一个页面，都要经过主工程的合并、构建和回归测试，再走应用市场上架；一个部门的服务延期，可能拖累整个版本；某次更新出了问题，受影响的也不止那一家。 同时供应商关系也会遇到管理问题，统一身份是一家单位建的，事项系统来自另一家厂商，部门小程序还有各自的服务商在维护。谁能提交代码，谁负责审核，线上跑的是哪一版，出故障怎

其实国内不少地方的政务服务，最早一批入口其实建在微信、支付宝的小程序里面的，预约取号、事项查询、材料预审、缴费、办件进度，这些服务在微信端跑了几年，页面和接口都经过多轮打磨，业务部门和建设单位对这套开发、提审、发布的节奏也已经熟悉。 等到要建设或者升级自有政务 APP，这些已有服务怎么处理，就摆上了桌面。常见的做法是把清单逐项排进客户端需求池，页面按原生重写一遍，接口重新联调，再跟着 APP 版本走测试和上架。几十项服务排下来，工期和预算都很可观，而且微信小程序那边还得继续维护，同一项服务从此有了两套实现。 今日分享另一种解决方案，是否可以复用这些小程序代码，因为这些小程序代码本身就是一份成熟的业务资产。如果自有 APP 也能提供小程序的运行环境，存量代码就有机会直接复用，二次开发集中在少数绕不开的差异上。 小程序为什么一定要在微信上运行 一个微信小程序工程，拆开看是 WXML 页面结构、WXSS 样式、JavaScript 业务逻辑和 JSON 配置。这些文件自己并不会运行，它们能变成用户看到的服务，靠的是微信客户端在背后提供的运行环境。 以小程序容器技术的一般实现来看，

过去几年，企业建设 APP 的逻辑很明确：把更多业务、更多服务和更多用户场景放进同一个入口。银行 APP 从账户查询延伸到理财、信用卡、贷款、缴费和生活服务；城市服务 APP 从信息查询扩展到预约、办事、支付和公共服务；企业级 APP 也在不断整合内部工具、业务流程和第三方服务。 能力变多以后，另一个问题也随之出现：用户知道自己要办什么事，却未必知道对应的入口在哪。首页宫格、频道页、搜索框、运营位和多级菜单能承载大量功能，但用户仍要先理解产品如何分类，再沿着页面路径找到服务。功能规模小的时候，这种方式足够直接；当业务模块越来越多，找入口本身就成了任务的一部分。 AI 带来的变化，是让用户可以先表达需求。例如，用户说“帮我查一下本月账单”“我想预约明天的业务办理”，APP 先理解这句话，再把用户带到可继续操作的服务页面或卡片中。AI 不替代原有业务系统，业务办理、权限校验和交易确认仍由原有流程承担；它增加的是一个更接近用户意图的服务入口。

已有微信小程序，想在自有 APP 里继续使用，通常不需要把所有页面重新做成原生页面。迁移的重点不在于“把代码包上传一次”，而在于把原来依赖微信环境的能力梳理清楚，再接入宿主 APP 和小程序管理平台。 FinClip 在其中承担两部分工作：小程序容器负责让小程序在 APP 内加载和运行；小程序管理平台负责版本上传、体验测试、审核、发布、灰度和下架。原有的订单、会员、内容等业务系统仍然沿用，不需要重建。 整套流程可以按七步推进。 第一步：确定迁移范围 先确定首个迁移版本要覆盖哪些业务，不要一开始把全部页面都纳入范围。通常优先选择访问频率高、业务流程相对完整、对微信专属能力依赖较少的模块，例如服务查询、内容浏览、预约提交或会员服务。 准备材料时，至少要有： * 当前稳定的小程序代码分支和构建配置； * 页面清单，标出首页、登录页、提交页、结果页和异常页； * 微信侧能力使用清单，例如登录、支付、分享、订阅消息、扫码、

自己的APP想要引入AI能力，不知道该如何去引入？达到什么样的效果，先看看微信是怎么做的： 今年 6 月，微信“小微”开启小范围内测，用户可以用语音或文字提出需求，由 AI 调起小程序完成挂号、购买咖啡等生活服务，用户不用先翻菜单，先把想办的事说出来。 其实现在很多App已经碰到相同的问题。服务一年年增加，首页却没有无限的空间。预约、账单、订单、发票、权益、活动、客服、内容专区都要有入口，用户要办一件事，要去一层层菜单去找到自己的需求，熟悉App 的人还好，低频服务一多，很多人连入口是否存在都不确定。 微信里的小微值得借鉴的是：它把对话接到了后面的服务上。用户说“帮我预约明天的服务”之后，AI 能把服务接着办下去。对企业 App 而言，已经上线的小程序、H5 页面、原生功能和合作方服务，同样可以被组织成可调用的服务网络。AI

一个运行多年的 APP，很少还保持着最初那套干净的页面结构。首页和交易流程可能是原生页面，活动专区、帮助中心和部分业务办理已经放进 WebView，消息、搜索、扫码和外部链接又分别维护着自己的跳转规则。新功能能持续上线，背后通常也积累了不少兼容逻辑。 准备引入小程序容器时，SDK 通常接得进去，团队更担心 APP 里从此多了一种页面类型。原生、H5、小程序各有路由和生命周期，如果登录、支付、返回、错误提示、埋点仍由业务团队分别处理，页面越多，线上问题越难判断由谁负责。 这种担心有道理。小程序容器只是提供一套新的业务运行环境，它不会自动整理存量 APP 里已经分散的公共能力。改造的重点也因此落在公共层：三种承载方式怎样分工，以及它们怎样共用同一套路由、身份、能力和监控规则。 存量APP的复杂度通常早已存在 很多项目在引入小程序之前，原生和 H5 已经各自形成了一套连接宿主的方式。某个 H5 页面通过 URL 参数拿登录信息，另一个页面通过 JavaScript

很多APP第一次接入合作伙伴时，SDK 往往是最省事的选择。对方已经准备好 iOS 和安卓版本，客户端团队照着文档加依赖、申请权限、处理登录和回调，联调完成后跟随下一个 APP 版本上线。一两项能力这样做，通常推进得很顺。 但是随着会员权益、内容频道、短剧、营销活动、生活服务陆续进入APP，每家合作方都带着自己的依赖、初始化方式和升级节奏。单独看，每个 SDK 都能正常运行；放进同一个主工程里，依赖冲突、权限变化、包体增长和兼容测试开始互相影响。合作方只改了一个业务页面，APP 团队仍可能要重新打包、回归和上架。 为什么APP会越做越大？ SDK 的优势很明确。地图导航、音视频、设备连接、崩溃监控等功能需要深入调用操作系统能力，放在原生环境里更合适，性能和生命周期也更容易控制。 同样因为接得深，后续成本会留在客户端工程中。每增加一家 SDK，主工程里可能就会多出一组依赖库、编译配置、权限声明、初始化逻辑和回调。

很多APP在引入第三方服务的早期，处理方式都很直接：新接入一项权益、内容或生活服务，就在首页增加一个图标；合作方希望获得更多曝光，再补一个轮播图或频道入口。当服务只有几项时，用户还能顺着首页找到，但随着接入数量增加后，首页会越来越长，频道越分越细，运营人员也开始争抢有限的入口位置。 小程序容器的技术架构让第三方服务进入APP变得更灵活，合作方可以按小程序方式交付业务页面，APP 不必为每项服务分别集成一套原生 SDK，页面更新也不必总跟着客户端主包发版。服务接得更快以后，入口很快就跟不上了：几十项服务已经在线，用户应该去哪里找？ 继续增加图标只能暂时解决曝光，APP 需要从“页面入口管理”转向“服务发现”，让首页、分类、搜索、最近使用和用户权限共同决定服务怎样出现。 小程序容器如何让第三方服务运行在自有APP中 简单来说，小程序容器是集成在宿主APP 内的一套运行环境。iOS、安卓或鸿蒙客户端接入对应的小程序 SDK后，运行时负责获取和加载小程序代码包，处理页面渲染、路由、生命周期、缓存，以及小程序与宿主能力之间的交互。用户看到的页面直接运行在自有APP内，无需跳到微信或其他