github.com/flutter/flu…
简单翻译一下：
感想
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上先搞起来？官方提到的那些安全问题对我的a
pp影响会有多大，类似的安全问题在H5上遇到过没？我又没有什么办法能避免此类安全问题？至于补丁发布系统，都是互联网厂家，自己搞一个应该没什么问题吧。
之前已经看到咸鱼已经在搞一套支持iOS和Android的Flutter热更新方案，性能基本上没有什么损失，而且也是在做了一些取舍之后实现的适合自身业务的方案，希望后续能了解到更多技术细节。
希望
聊完了感想，关于Flutter热更新，我们再说说希望吧。
可能实现的希望： 从上面那个issue里也可以看出，Flutter团队对于第三方自己开发热更新是持开放态度的。iOS上的热更新就不指望了。但至少在Android平台上能出现靠谱的开源热更新解决方案。毕竟之前的插件化技术受到越来越多的限制。希望这样的热更新解决方案至少在Android平台上能让大家体验到像H5那样部署方便快捷同时又有性能媲美原生的运行体验。
不切实际的希望： Flutter官方能尽快重新把热更新功能提上日程。毕竟，来自官方的支持是最好的支持。
异想天开的希望： 虽然可能性微乎其微，但还是希望Apple能赋予Flutter平台级的热更新能力，共同来为新的app开发/发布模式添砖加瓦。
ter平台级的热更新能力，共同来为新的app开发/发布模式添砖加瓦。
