原生鸿蒙的用户越来越多，如何开发鸿蒙APP，成了很多移动开发团队摆在桌面上的问题。iOS和安卓的工程已经很成熟，形成了稳定的运营方案，现在凭空多出一个端，ArkTS要学、工程要新建、应用市场要单独上架，第一件事自然是想"怎么把鸿蒙版本做出来"。
但和团队实际聊下来会发现，开发只是眼前这关，后续如何长期维护才是大家反复提到的问题。
鸿蒙版本做出来之后，它就和 iOS、安卓、微信小程序一样，变成一个需要持续维护的端：功能要同步迭代，bug 要同步修，发版要同步走。多数团队的解法还是堆人，四个客户端四套代码四个节奏，功能对齐全靠项目管理硬扛。业务跑得越久，维护的包袱越重。
今天分享一套基于小程序多端框架的解法，看看怎么把"为鸿蒙单独立项"变成"一份代码四端运行"，同时把长期维护的成本也一并压下来。
新增一个鸿蒙端，需要增加多少运营压力
按照传统的原生开发方式，在 iOS、安卓、微信小程序之外再补一个鸿蒙端，通常需要考虑三个方面。
首先是人力按端翻倍，每个端一套语言一套工程，iOS 用 Swift，安卓用 Kotlin，鸿蒙要用 ArkTS 从头再写一套，同一个登录页要写四遍，人自然也要配四套。
然后是四端之间的对齐，功能要对齐，体验要对齐，发版节奏也要对齐。四端各自提审各自发版，iOS 审核慢一天，安卓渠道包晚两天，鸿蒙市场的规则又不一样，活动上线时间就得按最慢的那个端来算，用户看到的版本永远差着半拍。
最后是维护期的重复劳动，这也是鸿蒙端最容易被低估的一笔。一个接口字段调整，四个端各改一次、各测一轮，改的是同一个业务逻辑，工作量却按端数往上翻，而且这笔账在 APP 的整个生命周期里每个月都在发生。
其实单独看鸿蒙端的开发，找一家供应商或者自己组个小团队都能做出来。真正难的是往后三年五年，四个端要一直齐头并进，如何降低四个平台的持续运营成本，也成了需要考虑的事情。
借助多端框架，实现一套代码多端运行
可行的做法，是让业务代码只存在一份，鸿蒙端不再是一个独立的工程项目。
以 FinClip的技术方案为例，它提供的是一套小程序多端框架：业务的页面和逻辑按小程序语法写一次，iOS、安卓、鸿蒙的 APP 各自集成对应平台的 FinClip SDK 之后，这份代码就能直接在三个客户端里运行；同一份代码还可以发布到微信平台，作为微信小程序上线。鸿蒙端从"新建一个工程"变成"在已有 APP 或新建的壳工程里集成一个 SDK"。
一份代码之所以能跑四端，靠的是小程序架构本身的特点。小程序是双线程结构，逻辑层跑在 JSCore 里，渲染层交给 WebView，业务代码从头到尾不直接碰操作系统。系统之间的差异被 SDK 这一层吃掉了，上层的小程序代码在每个端看到的 API 和组件完全一致。FinClip 又一直保持和微信小程序语法的对齐，不自己发明新的语法和框架，所以这份代码放进微信的环境里照样能跑。
对团队来说，这意味着不用为鸿蒙单独学一套 ArkTS，也不用把已经上线的微信小程序重写成原生页面，原来怎么写小程序，现在还怎么写。
手里已经有微信小程序的团队，如何快速迁移
多数团队面对的不是白纸，微信小程序已经跑了一两年，业务和体验都经过验证，重写的沉没成本没有人愿意再付一次。
FinClip 兼容微信小程序语法，开发文档按微信的 API 和组件清单逐项标注支持状态，已支持的接口连 wx. 前缀都不用换。把小程序代码包拿过来，用开发者工具跑一遍兼容性检查，确认支持的部分直接运行，少数暂不支持的能力逐项处理就行。多数业务涉及的都是表单、查询这类常规页面，复用空间很大。
如果某个业务连自有 APP 都还没有，还可以更进一步，开发者工具支持把小程序直接导出为 iOS、安卓和鸿蒙的项目工程，生成可以上架应用市场的壳应用，业务实现全部放在小程序里，后续的更新升级也通过小程序完成，不需要重新打包发版。
开发做完只是第一关，长期维护怎么管
前面解决的是"怎么做出来"，接下来分享一下如何降低长期开发成本。
多端统一之后，版本管理的重心从客户端工程挪到了云端管理平台。
版本流转有固定流程，开发完成后用开发者工具上传代码包，先设成体验版让指定人员验证，再提交审核，通过后上架为线上版本，每次提交和审核都有记录，事后查得到。
发布环节留了缓冲，新版本可以先灰度，按机型、网络这类属性圈定小范围用户验证，确认符合预期再扩大范围。出了问题也有退路，线上版本可以直接下架，或者回退到最近的历史版本，最多支持回退 5 个，回退操作不需要重新审核。
热更新则让迭代快了不少，小程序的页面样式和代码逻辑更新不需要走应用商店的审核周期，iOS、安卓、鸿蒙三端同步生效，用户打开就是新版本。微信端走微信自己的发布流程，但代码仍然是同一份，大幅度降低多端协同维护的成本。
如果有需要维护多端APP的团队，可以考虑一下借助FinClip来实现开发层面的降本增效：
人力上，业务开发从四组人收敛成一组写小程序的人，各端只留少量维护宿主 APP 的人力，鸿蒙从"要专门建团队"变成"集成一个 SDK"。
节奏上，功能上线不再等最慢的那个端，小程序过审上架即全端生效，热更新把迭代周期从应用商店的审核周期里解放出来。
维护上，业务逻辑只存在一份，接口调整、页面改版、问题修复都只需要改一次，四个客户端同步受益，鸿蒙端不再是那个需要单独排期、单独测试、单独盯进度的特殊对象。
存量上，跑了几年的微信小程序直接变成自有 APP 和鸿蒙端的首批内容，四端之间不再存在重复建设，一份代码的每一次迭代都在四个客户端上同时产生价值。
对正在考虑鸿蒙的团队来说，小程序多端框架把问题从"怎么再养一个端"变成了"怎么让一份代码服务所有端"，开发省一道，往后的每一次迭代都跟着省。
