如何将多个部门的小程序集中运行在一个 APP 中，建设统一的移动政务门户
每个省市都有自己政务APP门户化建设的需求，核心还是希望让市民需要一个入口，就能办完各个部门的事情。
但现实情况是，市民希望入口集中，不用在小程序、公众号和H5页面之间来回切换、反复登录；而各个业务部门那边却各有各的现实，服务由不同供应商开发，迭代节奏也不一样，有的事项一年只改几次，有的专区每周都在调整。如果把几十项服务全部收进 APP 主工程，所有部门的页面变更都得排队等客户端版本，改一个表单字段也要等发版窗口。
难的不只是APP开发，更需要关注如何资源整合
如果只是客户端开发，做一个政务 APP 并不难。难的是建成以后，怎么长期容纳多个部门的服务而不失控。
通过原生方式集成，各部门的业务代码会持续汇入主工程。一方面APP包会越来越大，但更麻烦的在协作上：任何部门改一个页面，都要经过主工程的合并、构建和回归测试，再走应用市场上架；一个部门的服务延期，可能拖累整个版本；某次更新出了问题，受影响的也不止那一家。
同时供应商关系也会遇到管理问题，统一身份是一家单位建的，事项系统来自另一家厂商，部门小程序还有各自的服务商在维护。谁能提交代码，谁负责审核，线上跑的是哪一版，出故障怎么快速停掉——这些事如果靠群聊和发文件来对齐，服务一多肯定乱。
所以门户项目要同时解决两个问题：服务以什么形态进 APP，多部门的版本和发布又归什么规则管。前者是技术选型，后者是治理设计，缺一个都转不长。
通过小程序容器来实现APP解耦
门户APP做宿主，承载各部门都要用的公共能力，比如统一实名认证、服务目录和消息中心，外加系统权限和设备能力。这一层求稳，不跟着单个部门的服务调整频繁发版。
小程序容器集成在门户里，负责把各部门的小程序跑起来。小程序运行依赖逻辑层和视图层两套线程，JS 引擎执行业务脚本，WebView 渲染页面，代码包加载、路由和生命周期调度都归容器管。用户从服务目录点开某项服务，宿主把小程序标识和页面参数交给容器，剩下的运行在 APP 内完成。
管理平台在服务端，管小程序资产和版本。一个小程序归哪个部门，线上跑的是哪一版，谁提交过、谁审核过，平台都记着。治理的细节放到下一节说。
各部门原有的业务系统继续管权威数据。预约成没成功、办件流转到哪一步，仍由对应事项系统判断。门户建设不用复制一套业务后台，这一条对控制项目规模很实在。
已有小程序如何进行复用已有资源
现在各个部门都有自己的H5、小程序页面，是门户APP应该利用起来的存量资产，其实这些内容，开发层面并不复杂，主要是数据积累和接口对接需要大量的时间和人力成本。
而FinClip的解决方案比较现实，就是兼容微信小程序的语法，只要微信APP中能够运行的小程序，都可以运行在自有的APP中，能够大幅度减少二次开发的成本。
解决了前期的接入工作后，更需要关注的是如何长期的运维，这部分主要是依靠云端的管理平台。
平台上要为门户 APP 创建宿主应用并绑定 Bundle ID，关联后下发的 SDK Key 和 SDK Secret 会在 SDK 初始化时校验。小程序必须完成与宿主应用的关联才能在 APP 里打开，没授权的应用跑不了这些服务。门户里有哪些服务、来自哪里，因此是受控的。
版本流转走固定流程。部门用开发者工具上传代码包，先设成体验版本，让指定成员扫码验证；再提交审核版本走内部审核；通过后上架为线上版本，也可以设置审核通过后自动上架。每次提交和审核都会留下历史记录，事后查得到。
新版本上线前可以先灰度。平台按“规则配置加发布计划”的方式实现：规则条件可以按机型和网络这类属性圈定范围，也可以按基础库或 SDK 版本区分，先让小范围用户接触新版本，验证符合预期再扩大。有个前提要注意，灰度的小程序得有一个通过审核但暂未上架的版本，而且版本号不能低于当前线上版本。
万一新版本有问题，退路也是现成的。线上版本可以直接下架，用户立刻打不开；也可以回退到最近发布或已回退过的历史版本，目前最多支持回退 5 个，回退本身不需要重新审核。加载速度敏感的高频服务，还能导出离线包随 APP 打包，用户首次打开直接从本地加载。
这几条加起来，效果是这样的：部门保留自己的提交和迭代动作，门户运营方握着审核、发布范围和止损手段。权责分得开，出了问题也收得住。
如何实现上线发布的统一管理
集中运行之后，更新分两条通道。
部门服务的业务更新，比如事项规则调整、专区页面上线，走小程序版本的审核和发布，不占 APP 的发版窗口，部门之间也不用互相等。
门户自身的变更，比如升级容器 SDK、新增系统权限，仍然进客户端版本流程。
通道分开是这套结构能长期运转的前提。业务更新不再挤进主工程排队，客户端团队也不用为页面调整反复集成发版。反过来，部门同样没法借小程序通道绕过宿主侧的变更管理，边界对双方都成立。
更核心的还是实现运营层面的优化提升
市民只装一个 APP，各部门的服务都在里面，实名一次、消息一处，办事不再需要在小程序、公众号和 H5 页面之间来回找入口。
部门保留了原来的开发方式。小程序该怎么写还怎么写，版本该怎么发还怎么发，只是运行位置从微信换到了门户，发布动作从各自为政变成走统一的审核流程。业务更新不再排队等 APP 发版，一个专区页面今天提审，明天就能上线。
门户运营方拿到的是完整的管理手段：哪些服务能进来，每个版本发到什么范围，出了问题怎么退，都有明确的操作和记录。对整个项目来说，更实在的收益是建设账好算了，已有的微信小程序大量复用，新增服务按统一规范接入，重复建设的空间一点点被挤掉。
入口统一了，部门的迭代节奏还在，治理也收得住。这就是小程序容器对移动政务门户的价值。
