摘要：年初的時候看到年的增加了對熱更新的支持還著實高興了一陣子，然而前一陣子去看相關的時候卻發現了這個令人失望的消息官方暫時不會開發熱更新了。但大概不會是在今年。不切實際的希望官方能盡快重新把熱更新功能提上日程。

自從接觸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功能。

目前我們更愿意把資源投入到其他問題上。我們會持續驗證這個功能，而且說不定將來哪一天再次決定真的要把Code push搞起來 （例如，我們有可能需要給PC端Flutter app做更新解決方案）。但大概不會是在今年。

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上先搞起來？官方提到的那些安全問題對我的app影響會有多大，類似的安全問題在H5上遇到過沒？我又沒有什么辦法能避免此類安全問題？至于補丁發布系統，都是互聯網廠家，自己搞一個應該沒什么問題吧。

之前已經看到咸魚已經在搞一套支持iOS和Android的Flutter熱更新方案，性能基本上沒有什么損失，而且也是在做了一些取舍之后實現的適合自身業務的方案，希望后續能了解到更多技術細節。

聊完了感想，關于Flutter熱更新，我們再說說希望吧。

可能實現的希望： 從上面那個issue里也可以看出，Flutter團隊對于第三方自己開發熱更新是持開放態度的。iOS上的熱更新就不指望了。但至少在Android平臺上能出現靠譜的開源熱更新解決方案。畢竟之前的插件化技術受到越來越多的限制。希望這樣的熱更新解決方案至少在Android平臺上能讓大家體驗到像H5那樣部署方便快捷同時又有性能媲美原生的運行體驗。

不切實際的希望： Flutter官方能盡快重新把熱更新功能提上日程。畢竟，來自官方的支持是最好的支持。

異想天開的希望： 雖然可能性微乎其微，但還是希望Apple能賦予Flutter平臺級的熱更新能力，共同來為新的app開發/發布模式添磚加瓦。

大家伙對官方的這個表態有什么想說的可以發布到評論里大家一起討論。