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，开始学起来。
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.