Flutter热更新与热加载

之前偶然从Flutter官方文档上看到了支持热更新，当然这是从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.