Flutter应用出Bug了，怎么办？打包、签名、提交商店、等审核——这套流程走下来，快则几小时，慢则几天。如果你的用户分散在多个安卓渠道，尤其是审核周期长的市场，这简直是运维噩梦。
Shorebird是目前最成熟的解决方案，但它不是万能药。后端闭源、按补丁安装量付费、CDN节点集中在欧美、核心服务依赖第三方——这些对很多团队是硬伤。有数据驻留合规要求的、产品生命周期长的、用户主要在亚太的、想完全掌控基础设施的，都需要别的选择。
我找不到满意的开源替代品，于是做了flutter_patcher。
先搞懂技术原理。Flutter在发布模式下会把Dart代码预编译成libapp.so，包含VM快照和隔离快照。运行时Flutter引擎加载它启动Dart VM。这意味着几件事：不能像React Native那样传JS源码，只能整个替换libapp.so；一行Dart改动也得全量重编；必须在引擎加载前完成替换，mmap执行后就晚了；补丁必须用和安装应用完全一致的Flutter SDK版本构建。
核心机制很简单：在Application.onCreate之前拦截原生库加载路径，重定向到磁盘上的补丁libapp.so，让Flutter引擎加载补丁版本。
但生产级方案的关键在周边防护。versionCode绑定防止补丁装错版本；MD5加可选Ed25519签名验证，防止被篡改的CDN下发恶意代码；崩溃回滚让坏补丁不会下次启动时搞崩应用；坏补丁黑名单确保已知有问题的补丁不会被重复应用。缺了这些，只是"能用的热更新插件"；有了这些，才是"敢上线生产环境的热更新插件"。
flutter_patcher是个开源Flutter插件，只做安卓。iOS App Store政策禁止动态下发可执行代码，这不是路线图问题，是架构层面的不可行。设计目标就三个：自托管、零外部依赖、协议简单。
补丁格式是标准ZIP，包含libapp.so和manifest.json。manifest指定目标versionCode、Flutter SDK版本、签名哈希。插件启动时检查服务器是否有新版本，验证签名和versionCode匹配，原子化替换到应用私有目录，下次冷启动生效。
服务器端只需要能托管静态文件。可以是S3兼容存储、Nginx、公司内网服务器，甚至GitHub Releases。不需要运行时代码，没有数据库要维护，没有用户数据要处理。
和Shorebird的对比很直接。Shorebird提供托管服务、自动回滚分析、团队仪表盘、多区域CDN优化；flutter_patcher提供完全的数据主权、零持续成本、可审计的完整源码、任意基础设施部署能力。这不是更好的问题，是不同取舍的问题。
项目已经开源。如果你需要的是"设置好就不用管"的托管方案，Shorebird依然是合理选择。但如果你必须自己掌控每一个环节，现在有了选项。
热门跟贴