Flutter是什麼?Flutter是Google推出的一套開源跨平臺UI框架,能夠快速地在Android、iOS和Web平臺上構建高質量的原生用戶界面。在過去的兩年時間裏,Flutter的更新頻率是至關的快,也有不少的公司開始使用它來進行跨平臺應用開發,能夠說,將Flutter稱爲2019年最流行的跨平臺技術也不爲過。編程
做爲一個移動互聯網的老兵,我前後研究過Hybrid APP、React Native和Weex等跨平臺技術,而且有幸出版過相關的書籍。對於Flutter,給個人感受是,不論是從社羣和社區的活躍來看,仍是從技術的水準上來看,Flutter無疑都是目前最優秀的跨平臺開發方案。小程序
在國內,除了阿里、騰訊、美團等大廠外,國內不少的中小團隊也開始使用Flutter來做爲移動應用開發的首選,而且不少公司在移動招聘方面也要求具備Flutter開發的背景。那麼對於Flutter這個新生事物,Apple的態度是怎樣的呢?之後會不會封殺呢,就像以前的JSPatch等。框架
首先,讓咱們先來認識下RN和Weex。RN 和 Weex 其實使用的是相似的技術方案,即它們都使用JavaScript做爲編程語言,而後經過中間層轉換爲原平生臺的組件後再使用原平生臺的渲染引擎執行渲染操做。而且它們都是指望團隊開發業務的同窗能夠開發一套代碼供多端使用,更多追求的是跨平臺能力,在作這個方案的同時正好也具有了動態化能力。編程語言
關於動態性方面自己具備必定的審覈風險,這裏明確表示是不合規的,參考審覈規則 2.5.2 蘋果動態性審覈條款,只不過 RN 和 Weex 的風險不如當年的 JSPatch 那麼大,因此Apple方面也是睜一隻眼閉一隻眼。post
而當年的JSPatch 等熱修復解決方案則是經過底層操做使得開發者能夠用 JS 語言調用任意原生代碼,這直接致使了用戶 App 在蘋果審覈以後,依然可能作大範圍的改動,這會使得蘋果的審覈機制形同虛設。想象一下,你一個明面上說是新聞類的App,審覈經過後搖身一變變成了其餘類型的App,你說合不合規,既影響 App Store 總體的體驗,更會給蘋果帶來系統性的合規問題,這是一大封殺 JSPatch 的緣由。性能
RN和Weex 蘋果的建議是不提倡、不承諾不封殺,從個人理解是蘋果對於這類相對低風險的方案,秉持的態度是觀望,好比某天發現影響了他們的審覈,就會堅決果斷的封殺;若是在審覈期間,經過這類技術動態改變頁面,頗有可能會被直接拒審。移動應用開發
至於小程序,其實自己是當年 H5 離線包的一個開發語法標準化的衍伸,自己確實也具有了跨平臺和動態化能力,從蘋果目前的態度來看,只要不作的特別過度,目前是能夠的,尤爲是目前各大平臺都出了本身的小程序解決方案與開放平臺的狀況下,總不能把這些 App 都幹掉吧。ip
Flutter 與 RN、Weex、小程序最大的不一樣就是,Flutter是一個跨平臺解決方案,而非一個動態化解決方案。若是你閱讀Flutter相關的介紹,會發現Flutter直接使用skia引擎來渲染視圖,而且Flutter的Widget使用現代響應式框架進行構建,和平臺沒有直接的關係。開發
而從技術實現上來講,Flutter直接經過NDK編譯成本地庫的(libflutter.so),也就是說,Flutter執行是AOT(靜態編譯)執行,而不是JIT(即時編譯),性能上徹底沒問題。而在實際表現中,也優於Android原生下JIT狀態時的效率,本地庫的特性也致使Flutter自身不具有熱更新能力。而JSPatch這類東西,就和Android原生的熱修復框架Tinker之類的相似,是影響編譯效率的,尤爲對啓動速度影響比較大。出於用戶體驗方面的考慮,確定是會被封殺的,這方面Google Play也是同樣作法。get
目前,從Flutter的發展趨勢來講,Google 是想把 Flutter 打形成爲新一代的移動端開發標準,在作任何事情時都會考慮合規問題,因此纔會在考慮了 iOS 上動態化能力時,依然不考慮支持這個特性,由於一旦 Flutter 在 iOS 上具有了這個能力,也就存在了審覈風險,這個審覈風險是系統性的。
蘋果已經明確表示 Flutter 目前沒有合規上的風險,由於它自己就不是一個動態化解決方案,但同樣秉持不提倡、不承諾不封殺,由於 Flutter 的崛起會吃掉蘋果 App 原生開發人員的份額,蘋果不建議使用官方之外提供的 Native 開發方案,蘋果是毫不能容忍開發人員的大面積消失。一旦這種狀況發生,蘋果的生態就會遭人掣肘,這是蘋果爸爸就會出來保護蘋果 App 原生開發人員,這個時候也就是 Flutter 份額下降影響力下降的時刻,蘋果也在不斷推行 Swift 和 SwiftUI 等對原生開發人員更友好的解決方案,力圖抵擋住各跨平臺解決方案對蘋果 App 原生開發人員的蠶食。