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

最新推荐文章于 2024-06-25 09:43:29 发布

feifei99_8820

最新推荐文章于 2024-06-25 09:43:29 发布

阅读量998

点赞数 10

分类专栏：程序员文章标签： flutter

本文链接：https://blog.csdn.net/feifei99_8820/article/details/138984525

版权

程序员专栏收录该内容

266 篇文章 0 订阅

订阅专栏

坏消息

自从接触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功能。