近年來，移動互聯網應用有着爆發式的增長，同質化APP層出不窮，人們對於產品體驗的要求越來越高，渲染遲緩、交互卡頓的單體 Web APP 已經無法滿足現有用戶苛刻的使用標準；與此同時，井噴式的業務需求迫使 iOS、Android 兩個移動平臺不斷提升迭代開發速度，縮短版本發佈週期；如何既能利用 Web 門檻低、輕量級、跨平臺開發的優勢，又能儘可能最大化屏蔽其現存缺點成了大前端融合領域攻克的重點。
本文借用主流移動跨平臺開發方案，向大家介紹移動平臺開發的演變之路。
Hybrid-App 的天下
移動應用開發領域發展至今已基本被 Android、iOS 兩大平臺統治，每個平臺仍在不斷髮展完善、壯大自己的生態系統；對開發者而言每個平臺更像是一個巨大的 SDK，爲我們抹平了設備硬件、系統內核所帶來的差異，統一了平臺設計、開發方式。
爲了追求極致的開發效率、降低研發成本，早期的開發者不斷嘗試利用新技術突破平臺所帶來的約束，PhoneGap 技術(旨在讓早期的Web-App Written once, run everywhere )的出現讓開發者們看到了 Hybrid-App 的雛形。
PhoneGap 技術基於WebView引擎中的 JS Core 解釋器，其核心是 Cordova JavaScript類庫，這層JavaScript Plugin抹平了不同平臺間的差異，爲Web 與 Native 交互提供了統一的抽象接口及完善的調用機制，其本質是將不同平臺打造爲一個接口統一的Web殼資源平臺：UI渲染依賴平臺 Web Render 處理，統一使用 HTML+CSS 繪製；交互邏輯使用JS Core這種方式在早期大大降低了開發成本、同時也緩解了早期特定移動平臺開發人員稀缺的問題，早期定義的 Hybrid-App 更像是基於移動平臺開發的 Web App。
伴隨業務規模的發展，人們發現這種方式雖然高效，但是用戶體驗卻是一團糟；雖然實現了跨平臺開發，但又被有限的插件資源所限制；移動開發領域初期，系統平臺衆多，一系兼容處理讓整個框架變得臃腫，這令原本就性能堪憂的框架更是捉襟見肘。隨着前端技術的進步，開發者們也在不斷打磨Cordova框架：提升整體加載性能、增強插件擴展靈活性，從大刀闊斧到精雕細琢，Cordova生態系統逐漸完善， 衆多公司也紛紛開始圍繞 Cordova 及一些主流的前端框架打造自己的專屬移動開發平臺，Hybrid-App也從青澀步入成熟。
這裏不得不提到影響了近幾年前端設計思想的UI框架React.js，其設計初衷是優化web在移動端的渲染性能、改變傳統的UI開發方式：
組件的概念 - React基於UI組件構建視圖，每個組件負責維護自己的（State）展示狀態，利用簡單的UI組件創建複雜的UI；利用組件組合後形成的單向數據流，根據 State 的變化來刷新UI展示；同時推出了更便於組件化開發的 JSX(JS 語法糖) 語言。
Visual DOM - React一個顛覆性的創新就是引入了二進制 Visual DOM 樹，其本質可以理解爲在 JS 和 DOM 之間做了一個緩衝層用於保存 Virtual DOM 樹，UI狀態變化時只比較新舊 Visual DOM，通過 Diff 算法找出節點差異，然後進行真實 DOM 操作。因爲操作HTML DOM 是非常耗費系統資源的，通過這種方式可以保證以最小代價刷新UI。
輕量級的UI框架 - 可以和其他前端框架結合使用，React.js只是單純的UI框架，也就是常說的 MVC 框架中的 View 層，它借用了響應編程模式的特點來簡化Web視圖的創建過程；Model層 和 Controller層的缺失催生出了 Flux 和 Redux（Redux可以視爲 Flux 框架的精簡版） 框架。
這裏僅以使用比較廣泛、知名度更高的 Redux 框架來介紹，Redux框架的核心理念是嚴格的單向數據流，只能通過 dispatch(Action) 的方式修改Store數據(Store的概念源自MVCS框架，Store 不僅僅是 Model 的概念，理解爲前端中的DB形式更爲貼切)，其流程可以簡單描述爲：View -> Action -> Reducer(logic process) -> Store(change/write/delete state)。
Redux的設計理念是不是看上去和React.js不謀而合？再加上 Redux 社區還基於異步流擴展了很多 Extensions 插件（redux-trunk、redux-promise、redux-saga、redux-observable 等），所以很多廠商紛紛選用 React+Redux 作爲自己的 Web 支撐框架。
至此，也就形成了業內主流的Hybrid-App 框架 Cordova+React+Redux，但是由於Web有着先天的侷限性，前端框架只是從架構設計、算法層面對性能進行優化，仍然無法解決根本問題：
-
首次渲染效率及白屏問題
-
單線程的狀態分發機制，無法滿足複雜用戶交互場景（滑動，拖動手勢）
-
伴隨着業務規模持續增長的 js plugin，基於單Web頁面的注入機制，無法有效控制內存增長
React.js 這種依託於算法優化渲染效率前端框架，也有着無法迴避的缺陷： -
首次創建 Virtual DOM 樹的耗時相當於延遲了首屏渲染時間
-
每次 State 變化都會生產全量 Virtual DOM 樹，和上一次結果做diff，這其實是一次算法執行時間與Real DOM 操作時間的博弈
-
需要編寫大量的閉包函數（Redux 也有同樣的缺陷）
隨着業務爆發式的增長、交互複雜度提升、數據請求不斷增多，如果要 Redux 承載整個App或大部分關聯Web的數據處理已經非常困難：
-
Store中存放的冗餘數據越來越多，維護了多個 Web 頁面的組件狀態
-
直接在 reducer 中操作View 與 Model，幾層 reducer 之後很難明確 Model 已經被加工成何種形式
-
一直會有下一個基於 Redux 的改良封裝 Extensions
-
異步、同步相互依賴場景，複雜UI交互，恐怕大部分精力都在考慮 reducers 怎麼拆分了
不可否定的是，React 和 Redux 是偉大的框架，他們設計思想、核心理念對後續移動領域的發展有着深刻的影響；移動互聯網技術的發展反而放大了它們的先天缺陷，這也加快了 Hybrid-App 的進化速度。
不甘平庸的產物
在W3C制定HTML5標準之初，FB的創始人扎克伯格就曾口出狂言要用HTML5技術統一移動端，無奈宣告最終押注失敗，隨後 React、Redux Web框架的相繼推出表明了他們並未真正放棄，這也爲2015年FaceBook發佈 React Native 框架買下了伏筆。
一心想統一移動端開發的FaceBook在2015年宣佈了只用 JS 語言開發 Native 應用的框架 React Native（後文稱：RN），並提出了新的口號：Learn once write anywhere，新框架強調的是UI繪製、交互邏輯思想、開發方式的統一，與 Cordova 不同的是 RN 將 JS 中定義的組件標籤都轉義成了原生對應的 UI組件，直接拋棄了 WebKit 中渲染、繪製功能，全部使用 Native 資源，其核心思想是基於JavaScript 虛擬機將 JSX 編寫的組件映射爲Native UI組件。由於RN技術天生就引用了自家的 React.js 技術框架又有整合了Native平臺UI組件，在發佈之初讓廣大前端開發者看到了新的希望。
不同平臺的 JS 虛擬機爲 RN 提供運行時 JS Context 環境，其中注入了 RN 轉義 Native UI組件的接口，相較於傳統的 Cordova 形式的 Hybrid-APP，不深究細節的話，可以認爲 RN 使用了原生 UI 組件完美替換了Web Core中的 H5 + CSS 的繪製框架。
由於使用了原生UI組件，其渲染速度和UI流暢度有了質的飛越，前期很多 Web 頁面無法支持的效果也可以使用 RN 來實現；只使用 JS/JSX 開發，兼容Web React.js、Redux.js 等主流框架，RN自身也實現了大部分UI組件的集成工作，再借助活躍的社區，開發效率相比於原有的 Native+Web 形式的 Hybrid-App 有了顯著提升。
雖然RN在發佈早期備受關注，甚至一些互聯網企業已經發布了RN的商業化平臺，但是業內仍然出現了“RN - 由入門到放棄”的聲音，究其原因，主要可以歸結爲以下幾類：
-
無法完全抹平跨平臺JS Engine的差異性，JavaScript Core 的不一致性，RN 的 Android版本仍然不支持 ES6 的 JSC
-
發佈快四年之久，仍爲 0.x 版本，還不能滿足 1.0 版本的穩定性（近期Facebook又在對RN進行大規模重構）
-
RN社區開源庫質量參差不齊，很容易跳進坑裏
-
很多基礎框架的庫還是不支持 RN，需要自己封裝
-
學習成本高，爲了輸出一個穩定的版本既要熟悉iOS平臺特性又要兼顧Android平臺兼容性
-
啓動時間長，向單一 JSC 中注入一段龐大的 js 插件仍然需要很長時間，即便只是注入基礎插件庫
-
RN框架每一次版本升級所帶來的接口向下兼容問題
-
JS是單線程的解釋性語言，手勢、動畫仍然是無法解決的痛點
-
Android 9.0 已經開始着手對插件進行主動封堵，這也會給各種形式 Hybrid 帶來一定影響
Facebook起初正是考慮到不同瀏覽器 WebKit 內核的差異性以及web view 所造成的內存、性能損耗，所以才決定僅僅基於JS VM，只使用單一的 JavaScript語言來完成跨平臺開發的統一，卻忽視了不同平臺系統、版本所帶來的差異；還有就是JS解釋性語言先天的單線程執行所帶來的硬傷，始終無法屏蔽 JS VM 的效率損耗；有沒有哪種框架可以避免這種硬傷，又能滿足跨平臺開發的需求呢？攪局者 Flutter 出現了。
攪局者
Google這種以創新爲本的公司當然不滿足於RN這種帶有瑕疵的框架，Google開啓了 Flutter 框架的開發，至今已發佈 1.0 Release 版本。Flutter從設計初期就選用可編譯成機器碼的Dart語言開發並且決定將UI組件和渲染器從平臺移動到應用層中，直接避免了由 JavaScript Bridge 引起的性能問題並最大可能降低了系統平臺的差異。
Flutter實際上是在已有移動平臺中搭建了一套獨立的開發系統，它也是至今爲止唯一提供響應式視圖而不需要橋接器的移動SDK，Flutter唯一要求是系統提供的 Canvas 、訪問事件（觸摸、定時器等）和服務（位置、相機等）。其整體架構設計可以總結爲一下幾點：
1.一切皆爲Widget，這與React中一切皆爲組件類似，不過 Widget 承載的定義更廣泛一些；
2.使用 Google 自家的 Dart 語言開發 Flutter Widget，Dart語言的主要特性就是可編譯爲機器碼，無需依賴橋接器；
3.Flutter框架在設計上引入了分層結構，每一層都簡歷在前一層之上，並且開源全部框架代碼（個人認爲在Preview版本全部開源並不利於生態發展）；
4.Flutter直接基於 GPU引擎繪製，拋棄系統 UI 組件（原文引用：藉助可移植的 GPU 加速的渲染引擎以及高性能本地 ARM 代碼運行時以達到跨設備跨平臺的高質量用戶體驗）；
5.Debug Mode支持 hot reload，減少開發階段編譯、調試時間。
Flutter 框架因爲直接基於 Canvas 開發，這也顯著降低了在舊版本操作系統上進行兼容性測試的需求；Dart 也擁有和 NPM 類似的軟件包倉庫，這些軟件包也可以擴展當前應用的能力。想爲開發者打造一套獨立的開發框架，當然你也會猜測到，Flutter框架不會太完美：
-
Dart 語言的嵌套地獄
-
由於 Dart 編譯器使用了tree shaking 等技術，也因而在Flutter中禁止了Dart支持的反射特性
-
Flutter無法使用 iOS、Android 自帶的設計樣式
-
將 Flutter 開發框架植入現有iOS、Android開發工程要做很多適配工作
-
完全開源的 preview 框架讓人擔憂其框架生態的健康發展
漲樂現有 Web 容器方案
漲樂APP（華泰證券旗下的應用）受限於現有架構和業務需求，對於RN、Flutter等框架保持謹慎的態度。我們當前採用 Hybrid 形式進行開發，交互複雜、安全要求較高、內存資源佔用高的業務（如：行情、交易、活體檢測、雙向視頻等）均由Native開發；場景比較單一、樣式頻繁變更、交互簡單的需求頁面則使用 Web 開發。
漲樂APP中現有的Web框架並未採用 jsBridge 注入的方式，而是仿造 Spring 的設計思路，將現有 Native APP 打造爲了一個 Local Server 平臺，將Native功能打造爲一個個獨立的 Service 組件，仿造 Rest 接口統一 Native -> Service、Web -> Service 調用協議；Web 開發人員基於 Ajax 調用不同的 Service 組件，LocalServer負責分發不同的 Service。
漲樂APP基於平臺優勢，攔截了現有 Web 資源加載、請求協議，擴展了 Web 資源的能力及生命週期，避免了傳輸重複資源耗時；也正是因爲有了 Web 攔截機制，漲樂APP可以在 Web容器 初始化的同時進行資源下載操作，這樣有效縮短了先初始化容器再下載資源的時間損耗。
相比如 Cordova 方式的優點：
-
利用現有移動平臺特點，犧牲Service調用分發時間換取對內存空間，儘可能減少注入 js插件體積
-
仿Spring框架打造的 Local Server 平臺，基於 Service 打造 Native 支撐
-
Web 資源加載協議攔截機制，避免冗餘資源文件傳輸，加速
總結
本文借用幾個主流框架簡單介紹了大前端跨端技術框架的發展線路，隨着移動應用開發技術的不斷髮展、成熟，最終會形成一套穩定、統一的跨平臺開發體系； 開發者對於web容器增強、業務插件化、虛擬運行環境等技術框架的不斷深耕、雕琢也都在推進大前端技術朝着一個統一的方向前進 – 多端融合。我們只能通過不斷的技術積累、輸出，才能追趕上大前端變革的浪潮，讓業務更好地依託技術爲用戶提供更優質的產品體驗。
更多內容請關注前端之巔（ID：frontshow）
