壞消息：Flutter官方暫時不會開發熱更新（Code push）了。

壞消息

自從接觸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開發/發佈模式添磚加瓦。

你們夥對官方的這個表態有什麼想說的能夠發佈到評論裏你們一塊兒討論。