Flutter 发布模式下 Dart 会被 AOT 编译进 libapp.so,不像 RN 那样能直接换 JS Bundle。所以“动态化”不是加个 SDK 就行,而是要在不碰商店审核的前提下,把那层已经编译死的 Dart 逻辑重新“撬开一条缝”。目前工程上最常被拿来做对比的两套方案,是 Shorebird 和腾讯 Shiply 的 Conch-Flutter。它们解决的是同一个痛点,但撬动的方式完全不一样。
Shorebird 的思路是“改运行时”。它分叉了 Dart VM / Flutter 引擎,在包里塞进一个定制运行时。发基准包用 shorebird release,修 Bug 用 shorebird patch 生成 Dart 层二进制差量,传到它家 CDN;App 启动时间询补丁,命中后让补丁里的 Dart 代码覆盖原 AOT 片段执行。Android 侧基本走原生路径,iOS 侧因为苹果限制要用自研解释器跑补丁区,所以补得越多解释执行占比越高。
Shiply Conch 的思路是“改编译链 + 自研解释器”。它不改你日常写的 Flutter 代码,而是在 Dart 编译器层面动手,配套一套自研 Dart 解释器和运行时服务体系。补丁按“模块”粒度制作和下发,支持函数级修复、页面级动态化、整包级动态化三种粒度;资源走 Flutter 原生资源热更,Image.asset 这类不用改写法。
一句话类比:
适合:海外业务、Dart-only 热修、小团队想最快跑起来。
典型场景:支付页算错金额、空指针崩溃、文案逻辑写反——纯 Dart 层事故,几行修复不想等审核。
优势
init / release / patch 一套命令,和现有 Flutter 工程侵入小;硬伤
Info.plist、AndroidManifest、原生资源全都不归它管,动了就得走商店;适合:国内中大型 App、多业务线并行、要和资源/配置/原生热修打通、有发布合规要求。
优势
代价
runAppWrapper 包一层、打基准包留符号文件、在 Shiply 建模块和发布任务;如果你做的是国内 C 端业务,选 Conch 而不是 Shorebird,核心不是“谁技术更炫”,而是三件事:
1. 发版不是个人行为,是组织行为
Shorebird 控制台再好用,也只是“补丁分发”。Conch 绑的是 Shiply 的发布体系:模块负责人、审核人、体验名单、灰度时长、平滑放量、紧急撤回——这些恰好对应国内 App 出事时真要走的流程。Dart 补丁写错一行,能靠“模块级回滚 + 体验名单复验”兜住,而不是全量推了再看崩溃曲线。
2. 动态化不止 Dart 代码
线上问题经常是“Dart 逻辑错了 + 配图错了 + 复制文案错了”。Conch 把代码补丁和资源热更放在同一条管道里,避免你 Shorebird 修代码、再自己搭 CDN 修资源、再用 Remote Config 改开关——三套系统对账对到崩。
3. 合规和审计在国内是硬指标
补丁签名、下发审计、谁批的、推给哪批设备、什么时候撤的,Conch 在平台侧有完整记录。对外沟通时,这比“补丁传在第三方 SaaS 上”好解释得多。
Shorebird 不是不好,它在海外、独立产品、纯 Dart 热修场景里非常省心。但一旦你关心“多业务线怎么隔离”“出事怎么追责”“资源和代码怎么一起发”“国内合规怎么交差”,Conch 的端云一体模型就更贴地。
结论:海外轻量热修用 Shorebird 最省事;国内业务要长期跑、多团队协同、和资源发布/合规绑在一起,Shiply Conch 是更稳的那条路。动态化不是“能不能发补丁”,而是“出事时你敢不敢在十分钟里推、五分钟里撤、事后能拿出完整链路复盘”。
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。