坏消息：Flutter官方暂时不会开发热更新（Code push）了。

摘要：年初的时候看到年的增加了对热更新的支持还着实高兴了一阵子，然而前一阵子去看相关的时候却发现了这个令人失望的消息官方暂时不会开发热更新了。但大概不会是在今年。不切实际的希望官方能尽快重新把热更新功能提上日程。

自从接触Flutter以来一直就觉得热更新/动态化是一个关键的点，也是很多互联网厂家是否选择Flutter的重要因素甚至是首要因素，之前参加Google北京办公室举办的和Flutter工程师面对面的活动，来自各个厂家的程序员们提的最多的问题就是Flutter对热更新的支持。年初的时候看到2019年的Roadmap增加了对热更新的支持还着实高兴了一阵子，然而前一阵子去看相关的issue时候却发现了这个令人失望的消息：Flutter官方暂时不会开发热更新（Code push）了。

原文如下:

This was previously on our roadmap for 2019. After investigating this in greater detail, we have decided not to proceed with this work for now.

There were several factors that led us to this decision:

To comply with our understanding of store policies on Android and iOS, any solution would be limited to JIT code on Android and interpreted code on iOS. We are not confident that the performance characteristics of such a solution on iOS would reach the quality that we demand of our product. (In other words, "it would be too slow".)

There are some serious security concerns. Since these patches would essentially allow arbitrary code execution, they would be extremely attractive malware vectors. We could mitigate this by requiring that patches be signed using the same key as the original package, but this is error prone and any mistake would have serious consequences. This is, fundamentally, the same problem that has plagued platforms that allow execution of code from third-party sources. This problem could be mitigated by integrating with a platform update mechanism, but this defeats the purpose of an out-of-band patching mechanism.

There is currently no out-of-the-box open source hosting solution for patching applications, so we would either have to rely on people configuring their Web servers accordingly, or we would have to create integrations for proprietary third-party services, or we would have to create our own bespoke solution. Hosting patches is a space we are not eager to enter. Having people configure their own server leaves them open to making mistakes with potentially serious implications as explained in the previous point about security. Depending on third-party services puts Flutter in an awkward position of having to pick winners and exposes us to the risk of those projects themselves making policy changes that would affect this feature.

We prefer to spend our engineering effort on other issues for now. We expect to keep experimenting in this space and will probably become serious about this again in the future (for example, we will probably need an update solution for desktop applications), but probably not this year.

github.com/flutter/flu…

简单翻译一下：

这个功能(code push)原本在Flutter的2019年路线图里。但是在仔细研究了相关细节以后我们决定目前先不搞了。

我们做这个决定有这么几个原因：

根据我们所理解的Android和iOS应用商店的规定。要实现Code push，在Android平台上会被限制在JIT代码。在iOS平台上会被限制在解释执行的代码。我们对于这样的限制下的解决方案在iOS平台上的性能表现能否达到我们的预期没有信心。（换句话说，“跑起来会慢的吓人吧”）。

其次就是安全方面的考虑。因为补丁会允许任意代码的执行。这会让补丁变成极具吸引力的流氓软件载体。通过强制补丁必须使用和app相同的key做签名可以缓解这一风险，但这样做也容易出错，而且一点出错有可能会导致严重的后果。这也是给一些允许执行第三方代码的平台造成困扰的根本问题。这一问题可以通过在平台里内置更新机制来缓解，但这也违背了我们想提供一个和平台无关的补丁机制的目标。

目前没有可以开箱即用的用于发放补丁的开源解决方案。所以要么我们把这个问题扔给用户，让用户在自己的Web服务器上去配置，或者我们不得不集成第三方私有服务，亦或者我们自己去创建这样的解决方案。然而我们自己并不想搞，客户自己去配置呢，他们有可能会犯上述安全方面的错误。依赖第三方服务则会把Flutter置于一个尴尬的位置。我们不得不从众多第三方服务中选择一个，并且存在第三方服务有可能自行制定相关规则从而影响Flutter的Code push功能。

目前我们更愿意把资源投入到其他问题上。我们会持续验证这个功能，而且说不定将来哪一天再次决定真的要把Code push搞起来 （例如，我们有可能需要给PC端Flutter app做更新解决方案）。但大概不会是在今年。

Flutter的面世确实惊艳，一次编写，多端运行（Android/iOS/PC/浏览器）。可以媲美原生的运行体验。然而，我认为缺少热更新的Flutter是不完整的，也称不上是革命性的。只有对现有移动端开发范式/生态有颠覆性的改变，才能称得上是革命性的。

为什么这么说呢？app也罢，H5也罢，对用户，对互联网厂家来讲，其本质是服务，用户可以通过各种方式使用互联网厂家的服务，可以在app里访问，可以在浏览器里访问，甚至可以通过语音交互来访问（比如市面上的各种智能音箱）。对用户来讲哪种方式最方便，哪种方式体验最好就用哪种。对互联网厂商来讲，能快速便捷的为用户提供稳定安全的个性化服务是其追求的目标。服务能不能快速高效的触达用户？目前app这种形式，新的服务，新的需求都需要通过新版本app发布到市场，市场审核通过，用户升级之后才能触达。

这里面有两个问题，一个是时间上的成本，拿app store来讲，虽然现在审核很快但是也是按天来计。另一个是被拒的风险。相信很多开发者都经历过app审核不通过的状况。这对互联网厂商来讲，有一种失控的感觉。那么对互联网厂商来讲比较理想的模式是什么样的呢？那就是类似H5的模式，服务从发布到触达用户都掌握在自己手里。这些年一度流行的插件化方案一定程度上就是反映了互联网厂商的这种需求。

如果Flutter能支持热更新的话，这就给改变现有的app开发发布模式打开了一扇窗户，从开始的类似热补丁这样的小范围线上问题修复的应用进化到像H5那样快速部署新服务瞬间触达用户，并且完全可控。同时又能达到媲美原生的性能。这才是对现有模式的颠覆，这才是革命性的。

然而从前面那个issue里面提到的三个原因来讲，支持Code push确实是困难重重。性能问题（主要是iOS），安全问题和补丁发布系统都不是短期之内能解决或者不适合由官方出面解决。从Flutter团队的角度来考量，不解决以上问题是无法提供标准低一些的热更新方案的，毕竟是要有官方背书的。然而我觉得对于各家互联网厂商的Flutter开发者来讲这也是一个值得研究的技术方向，相对于通用的高标准的热更新方案，开发者可以自己权衡技术风险和技术收益，做一些权衡来实现自己的Flutter热更新方案，比如iOS没法弄，是不是可以在Android上先搞起来？官方提到的那些安全问题对我的app影响会有多大，类似的安全问题在H5上遇到过没？我又没有什么办法能避免此类安全问题？至于补丁发布系统，都是互联网厂家，自己搞一个应该没什么问题吧。

之前已经看到咸鱼已经在搞一套支持iOS和Android的Flutter热更新方案，性能基本上没有什么损失，而且也是在做了一些取舍之后实现的适合自身业务的方案，希望后续能了解到更多技术细节。

聊完了感想，关于Flutter热更新，我们再说说希望吧。

可能实现的希望： 从上面那个issue里也可以看出，Flutter团队对于第三方自己开发热更新是持开放态度的。iOS上的热更新就不指望了。但至少在Android平台上能出现靠谱的开源热更新解决方案。毕竟之前的插件化技术受到越来越多的限制。希望这样的热更新解决方案至少在Android平台上能让大家体验到像H5那样部署方便快捷同时又有性能媲美原生的运行体验。

不切实际的希望： Flutter官方能尽快重新把热更新功能提上日程。毕竟，来自官方的支持是最好的支持。

异想天开的希望： 虽然可能性微乎其微，但还是希望Apple能赋予Flutter平台级的热更新能力，共同来为新的app开发/发布模式添砖加瓦。

大家伙对官方的这个表态有什么想说的可以发布到评论里大家一起讨论。