壞訊息
自從接觸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.
簡單翻譯一下：
這個功能(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開發/釋出模式添磚加瓦。
大傢伙對官方的這個表態有什麼想說的可以釋出到評論裡大家一起討論。