大前端的下一站何去何從？

近年來，移動互聯網應用有著爆發式的增長，同質化 APP 層出不窮，人們對于產品體驗的要求越來越高，渲染遲緩、交互卡頓的單體 Web APP 已經無法滿足現有用戶苛刻的使用標準；與此同時，井噴式的業務需求迫使 iOS、Android 兩個移動平臺不斷提升迭代開發速度，縮短版本發布周期；如何既能利用 Web 門檻低、輕量級、跨平臺開發的優勢，又能盡可能最大化屏蔽其現存缺點成了大前端融合領域攻克的重點。

本文借用主流移動跨平臺開發方案，向大家介紹移動平臺開發的演變之路。

Hybrid-App 的天下

移動應用開發領域發展至今已基本被 Android、iOS 兩大平臺統治，每個平臺仍在不斷發展完善、壯大自己的生態系統；對開發者而言每個平臺更像是一個巨大的 SDK，為我們抹平了設備硬件、系統內核所帶來的差異，統一了平臺設計、開發方式。

Figure 1 移動開發平臺概覽

為了追求極致的開發效率、降低研發成本，早期的開發者不斷嘗試利用新技術突破平臺所帶來的約束，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。

Figure 2 基于 PhoneGap 開發的移動 APP

伴隨業務規模的發展，人們發現這種方式雖然高效，但是用戶體驗卻是一團糟；雖然實現了跨平臺開發，但又被有限的插件資源所限制；移動開發領域初期，系統平臺眾多，一系兼容處理讓整個框架變得臃腫，這令原本就性能堪憂的框架更是捉襟見肘。隨著前端技術的進步，開發者們也在不斷打磨 Cordova 框架：提升整體加載性能、增強插件擴展靈活性，從大刀闊斧到精雕細琢，Cordova 生態系統逐漸完善， 眾多公司也紛紛開始圍繞 Cordova 及一些主流的前端框架打造自己的專屬移動開發平臺，Hybrid-App 也從青澀步入成熟。

Figure 3 基于 Cordova Plugins 的主流 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 年 非死book 發布 React Native 框架買下了伏筆。

一心想統一移動端開發的 非死book 在 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 的繪制框架。

Figure 4 React Native 跨平臺開發框架

由于使用了原生 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 版本的穩定性（近期 非死book 又在對 RN 進行大規模重構）

• RN 社區開源庫質量參差不齊，很容易跳進坑里

• 很多基礎框架的庫還是不支持 RN，需要自己封裝

• 學習成本高，為了輸出一個穩定的版本既要熟悉 iOS 平臺特性又要兼顧 Android 平臺兼容性

• 啟動時間長，向單一 JSC 中注入一段龐大的 js 插件仍然需要很長時間，即便只是注入基礎插件庫

• RN 框架每一次版本升級所帶來的接口向下兼容問題

• JS 是單線程的解釋性語言，手勢、動畫仍然是無法解決的痛點

• Android 9.0 已經開始著手對插件進行主動封堵，這也會給各種形式 Hybrid 帶來一定影響

非死book 起初正是考慮到不同瀏覽器 WebKit 內核的差異性以及 web view 所造成的內存、性能損耗，所以才決定僅僅基于 JS VM，只使用單一的 JavaScript 語言來完成跨平臺開發的統一，卻忽視了不同平臺系統、版本所帶來的差異；還有就是 JS 解釋性語言先天的單線程執行所帶來的硬傷，始終無法屏蔽 JS VM 的效率損耗；有沒有哪種框架可以避免這種硬傷，又能滿足跨平臺開發的需求呢？攪局者 Flutter 出現了。

攪局者

Google 這種以創新為本的公司當然不滿足于 RN 這種帶有瑕疵的框架，Google 開啟了 Flutter 框架的開發，至今已發布 1.0 Release 版本。Flutter 從設計初期就選用可編譯成機器碼的 Dart 語言開發并且決定將 UI 組件和渲染器從平臺移動到應用層中，直接避免了由 JavaScript Bridge 引起的性能問題并最大可能降低了系統平臺的差異。

Figure 5 Flutter 跨平臺開發框架

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 容器增強、業務插件化、虛擬運行環境等技術框架的不斷深耕、雕琢也都在推進大前端技術朝著一個統一的方向前進 – 多端融合。我們只能通過不斷的技術積累、輸出，才能追趕上大前端變革的浪潮，讓業務更好地依托技術為用戶提供更優質的產品體驗。

 

來自： https://www.infoq.cn/article/9*CZfjFghPVqZJlc7ScM