今天，我會從跨平臺開發方案的誕生背景、原理和發展歷史的角度，和你聊聊這些常見的開發方案，以及針對不同的場景我們應該如何選擇對應的方案。 ## 淺述跨平臺開發的背景 我們當下所處的移動互聯網時代，以它獨有的變革方式，帶給我們快捷、經濟、安全和方便，改變著生活的方方面面。而對于企業來說，移動應用已然成為各類手機終端上一張必備的產品名片。 在移動互聯網的浪潮下，我們開發的應用要想取勝，開發效率和使用體驗可以說是同等重要。但是，使用原生的方式來開發 App，就要求我們必須針對 iOS 和 Android 這兩個平臺分別開發，這對于中小型團隊來說就是隱患和額外的負擔。 因為這樣的話，我們不僅需要在不同的項目間嘗試用不同的語言去實現同樣的功能，還要承擔由此帶來的維護任務。如果還要繼續向其他平臺（比如 Web、Mac 或 Windows）拓展的話，我們需要付出的成本和時間將成倍增長。而這，顯然是難以接受的。于是，跨平臺開發的概念順勢走進了我們的視野。 所以從本質上講，**跨平臺開發是為了增加業務代碼的復用率，減少因為要適配多個平臺帶來的工作量，從而降低開發成本。**在提高業務專注度的同時，能夠為用戶提供一致的用戶體驗。用一個詞來概括這些好處的話，就是“多快好省”。 “一次編碼，到處運行”。二十多年前 Java 正是以跨平臺特性的口號登場，擊敗了眾多競爭對手。這個口號，意味著 Java 可以在任何平臺上進行開發，然后編譯成一段標準的字節碼后，就可以運行在任何安裝有 Java 虛擬機（JVM）的設備上。雖然現在跨平臺已經不是 Java 的最大優勢（而是它繁榮的生態），但不可否認它當年打著跨平臺旗號橫空出世確實勢不可擋。 而對于移動端開發來講，如果能實現“一套代碼，多端運行”，這樣的技術勢必會引發新的生產力變革，在目前多終端時代的大環境下，可以為企業節省人力資源上，從而帶來直接的經濟效益。 伴隨著移動端的誕生和繁榮，為了滿足人們對開發效率和用戶體驗的不懈追求，各種跨平臺的開發方案也如雨后春筍般涌現。除了 React Native 和 Flutter 之外，這幾年還出現過許多其他的解決方案，接下來我將會為你一一分析這些方案。這樣，你在選擇適合自己的移動開發框架時，也就有章可循了。 在此，我特地強調一下，我在下文提到的跨平臺開發方案，如果沒有特殊說明的話，指的就是跨 iOS 和 Android 開發。 ## 跨平臺開發方案的三個時代 根據實現方式的不同，業內常見的觀點是將主流的跨平臺方案劃分為三個時代。 * Web 容器時代：基于 Web 相關技術通過瀏覽器組件來實現界面及功能，典型的框架包括 Cordova(PhoneGap)、Ionic 和微信小程序。 * 泛 Web 容器時代：采用類 Web 標準進行開發，但在運行時把繪制和渲染交由原生系統接管的技術，代表框架有 React Native、Weex 和快應用，廣義的還包括天貓的 Virtual View 等。 * 自繪引擎時代：自帶渲染引擎，客戶端僅提供一塊畫布即可獲得從業務邏輯到功能呈現的多端高度一致的渲染體驗。Flutter，是為數不多的代表。 接下來，我們先看一下目前使用最廣泛的 Web 容器方案。 ### Web 容器時代 Web 時代的方案，主要采用的是原生應用內嵌瀏覽器控件 WebView（iOS 為 UIWebView 或 WKWebView，Android 為 WebView）的方式進行 HTML5 頁面渲染，并定義 HTML5 與原生代碼交互協議，將部分原生系統能力暴露給 HTML5，從而擴展 HTML5 的邊界。這類交互協議，就是我們通常說的 JS Bridge（橋）。 這種開發模式既有原生應用代碼又有 Web 應用代碼，因此又被稱為 Hybrid 開發模式。由于 HTML5 代碼只需要開發一次，就能同時在多個系統運行，因此大大降低了開發成本。 由于采用了 Web 開發技術，社區和資源非常豐富，開發效率也很高。但，**一個完整 HTML5 頁面的展示要經歷瀏覽器控件的加載、解析和渲染三大過程，性能消耗要比原生開發增加 N 個數量級**。 接下來，我以加載過程為例，和你說明這個過程的復雜性。 1. 瀏覽器控件加載 HTML5 頁面的 HTML 主文檔； 2. 加載過程中遇到外部 CSS 文件，瀏覽器另外發出一個請求，來獲取 CSS 文件； 3. 遇到圖片資源，瀏覽器也會另外發出一個請求，來獲取圖片資源。這是異步請求，并不會影響 HTML 文檔的加載。 4. 加載過程中遇到 JavaScript 文件，由于 JavaScript 代碼可能會修改 DOM 樹，因此 HTML 文檔會掛起渲染（加載解析渲染同步）的線程，直到 JavaScript 文件加載解析并執行完畢，才可以恢復 HTML 文檔的渲染線程。 5. JavaScript 代碼中有用到 CSS 文件中的屬性樣式，于是阻塞，等待 CSS 加載完畢才能恢復執行。 而這，只是完成 HTML5 頁面渲染的最基礎的加載過程。加載、解析和渲染這三個過程在實際運行時又不是完全獨立的，還會有交叉。也就是說，會存在一邊加載，一邊解析，一邊渲染的現象。這，就使得頁面的展示并不像想象中那么容易。 通過上面的分析你可以看出，一個 HTML5 頁面的展示是多么得復雜！這和原生開發通過簡單直接的創建控件，設置屬性后即可完成頁面渲染有非常大的差異。Web 與原生在 UI 渲染與系統功能調用上各司其職，因此這個時代的框架在 Web 與原生系統間還有比較明顯的、甚至肉眼可見的邊界。 :-:  圖 1 Hybrid 開發框架 我也曾碰到過很多人覺得跨平臺開發不靠譜。但其實，Web 容器方案是跨平臺開發歷史上最成功的例子。也正是因為它太成功了，以至于很多人都忽略了它也是跨平臺方案之一。 ### 泛 Web 容器時代 雖然 Web 容器方案具有生態繁榮、開發體驗友好、生產效率高、跨平臺兼容性強等優勢，但它最大的問題在于承載著大量 Web 標準的 Web 容器過于笨重，以至于性能和體驗都達不到與原生同樣的水準，在復雜交互和動畫上較難實現出優良的用戶體驗。 而在實際的產品功能研發中，我們通常只會用到 Web 標準中很小的一部分。面對這樣的現實，我們很快就想到：能否對笨重的 Web 容器進行功能裁剪，在僅保留必要的 Web 標準和渲染能力的基礎上，使得友好的開發體驗與穩定的渲染性能保持一個平衡？ 答案當然是可以。 泛 Web 容器時代的解決方案優化了 Web 容器時代的加載、解析和渲染這三大過程，把影響它們獨立運行的 Web 標準進行了裁剪，以相對簡單的方式支持了構建移動端頁面必要的 Web 標準（如 Flexbox 等），也保證了便捷的前端開發體驗；同時，這個時代的解決方案基本上完全放棄了瀏覽器控件渲染，而是采用原生自帶的 UI 組件實現代替了核心的渲染引擎，僅保持必要的基本控件渲染能力，從而使得渲染過程更加簡化，也保證了良好的渲染性能。 也就是說，在泛 Web 容器時代，我們仍然采用前端友好的 JavaScript 進行開發，整體加載、渲染機制大大簡化，并且由原生接管繪制，即將原生系統作為渲染的后端，為依托于 JavaScript 虛擬機的 JavaScript 代碼提供所需要的 UI 控件的實體。這，也是現在絕大部分跨平臺框架的思路，而 React Native 和 Weex 就是其中的佼佼者。 :-:  圖 2 泛 Web 容器框架 為了追求性能體驗的極致，并進一步維持方案的簡單可擴展性，有些輕量級的跨平臺方案甚至會完全拋棄 Web 標準、放棄 JavaScript 的動態執行能力而自創一套原生 DSL，如天貓的[VirtualView](http://pingguohe.net/2017/12/07/Tangram-2.html)框架。從廣義上來說，這些方案也是泛 Web 容器類方案。 ### 自繪引擎時代 泛 Web 容器時代使用原生控件承載界面渲染，固然解決了不少性能問題，但同時也帶來了新的問題。拋開框架本身需要處理大量平臺相關的邏輯外，隨著系統版本變化和 API 的變化，我們還需要處理不同平臺的原生控件渲染能力差異，修復各類奇奇怪怪的 Bug。始終需要 Follow Native 的思維方式，就使得泛 Web 容器框架的跨平臺特性被大打折扣。 而這一時期的代表 Flutter 則開辟了一種全新的思路，即從頭到尾重寫一套跨平臺的 UI 框架，包括渲染邏輯，甚至是開發語言。 * 渲染引擎依靠跨平臺的 Skia 圖形庫來實現，Skia 引擎會將使用 Dart 構建的抽象的視圖結構數據加工成 GPU 數據，交由 OpenGL 最終提供給 GPU 渲染，至此完成渲染閉環，因此可以在最大程度上保證一款應用在不同平臺、不同設備上的體驗一致性。 * 而開發語言選用的是同時支持 JIT（Just-in-Time，即時編譯）和 AOT（Ahead-of-Time，預編譯）的 Dart，不僅保證了開發效率，更提升了執行效率（比使用 JavaScript 開發的泛 Web 容器方案要高得多）。 :-:  圖 3 自繪引擎開發框架 通過這樣的思路，Flutter 可以盡可能地減少不同平臺之間的差異, 同時保持和原生開發一樣的高性能。所以說，Flutter 成了三類跨平臺移動開發方案中最靈活的那個，也成了目前最受業界關注的框架。 現在，我們已經弄明白了三類跨平臺方案，那么我在開發應用的時候，到底應該如何選擇最適合自己的框架呢？ ## 我該選擇哪一類跨平臺開發方案？ 從不同的角度來看，三個時代的跨平臺框架代表們在開發效率、渲染性能、維護成本和社區生態上各有優劣，如下圖所示： :-:  圖 4 主流跨平臺框架對比 我們在做技術選型時，可以參考以上維度，從開發效率、技術棧、性能表現、維護成本和社區生態來進行綜合考慮。比如，是否必須支持動態化？是只解決 Android、iOS 的跨端問題，還是要包括 Web？對性能要求如何？對多端體驗的絕對一致性和維護成本是否有強訴求？ 從各個維度綜合考量，React Native 和 Flutter 無疑是最均衡的兩種跨平臺開發方案，而其他的方案或多或少都“偏科嚴重”。 * React Native 依托于 Facebook，經過 4 年多的發展已經成長為跨平臺開發方案的實際領導者，并擁有較為豐富的第三方庫和開發社區； * Flutter 以挑戰者姿態出現在我們的面前，可以提供更徹底的跨平臺技術解決方案。雖然 Flutter 推出時間不長，但也有了諸多商用案例，加上清晰的[產品路線圖](https://mp.weixin.qq.com/s/aRhQdMd0R74adph9_V0wgQ)和 Google 的強大號召力，Flutter 未來的發展非常值得期待。 那么問題來了，我究竟應該選擇 React Native 還是 Flutter 呢？ 在這里，我和你說一下我的建議吧。 **對于知識學習來說，**這兩個應用層面的框架最好都學。學習的過程中最重要的是打好基礎，深入理解框架的原理和設計思想，重點思考它們的 API 設計的取舍，發現它們的共性和差異。 Flutter 作為后來者，也從 React Native 社區學習和借鑒了不少的優秀設計，很多概念兩邊都有對應，比如 React Native 的 Component 和 Flutter 的 Widget、Flex 布局思想、狀態管理和函數式編程等等，這類的知識都是兩個框架通用的技術。**未來也許還會出現新的解決方案，老框架也會不斷更新，只有掌握核心原理才能真正立于不敗之地。** **對于實際項目來說，**這兩個框架都已達到了大面積商業應用的標準。綜合成熟度和生態，目前倆看 React Native 略勝 Flutter。因此，如果是中短期項目的話，我建議使用 React Native。但作為技術選型，我們要看得更遠一些。Flutter 的設計理念比較先進，解決方案也相對徹底，在渲染能力的一致性以及性能上，和 React Native 相比優勢非常明顯。 此外，Flutter 的野心不僅僅是移動端。前段時間，Google 團隊已經完成了 Hummingbird，即 Flutter 的 Web 的官方 Demo，在桌面操作系統的探索上也取得了進展，未來大前端技術棧是否會由 Flutter 完成統一，值得期待。 ## 小結 這就是今天分享的全部內容了。 在不同平臺開發和維護同一個產品，所付出的成本一直以來一個令人頭疼的問題，于是各類跨平臺開發方案順應而生。從 Web 容器時代到以 React Native、Weex 為代表的泛 Web 容器時代，最后再到以 Flutter 為代表的自繪引擎時代，這些優秀的跨平臺開發框架們慢慢抹平了各個平臺的差異，使得操作系統的邊界變得越來越模糊。 與此同時，這個時代對開發者的要求也到達了一個新的階段，擁抱大前端的時代已經向我們走來。在這個專欄里，我會假設你有一定的前端（Android、iOS 或 Web）開發基礎。比如，你知道 View 是什么，路由是什么，如何實現一個基本頁面布局等等。我會讓希望迅速掌握 Flutter 開發的愛好者們，通過一種比較熟悉和友好的路徑去學習 Flutter 相關的代碼和程序，以及背后的原理和設計思想。