Flutter热更新与热加载 - 好文

之前偶然从Flutter官方文档 <https://github.com/flutter/flutter/wiki/Roadmap>
上看到了支持热更新，当然这是从2019年才开始的

Dynamic updates
The Dart Platform, on which Flutter is built, provides unique abilities for
us to push code to your applications without redeploying the app.
Dynamic patching on Android, allowing for code updates to deployed to Flutter
applications running on Android directly from a servers.
Dynamic extension loading to allow lazy loading of occasionally used parts of
your application

这里的Dynamic patching on Android指的是热更新，Dynamic extension loading
指的是热加载，emmm，开始学起来。

2019年6月13日修改：
今天有位博友告诉我，flutter停止对热更新的支持了，我去看了一下确实如此，请参考上面的Flutter官方链接

Changes
Dropped support for Dynamic updates in 2019. See this bug for details.

原因的话是考虑安全性和需要提供托管服务器影响其他功能开发，参照下面的声明

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.

热门工具换一换