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

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

做者｜趙祥輝（華泰證券互聯網前端團隊）
編輯｜覃雲
近年來，移動互聯網應用有着爆發式的增加，同質化 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 有着先天的侷限性，前端框架只是從架構設計、算法層面對性能進行優化，仍然沒法解決根本問題：

• 首次渲染效率及白屏問題；
• 單線程的狀態分發機制，沒法知足複雜用戶交互場景（滑動，拖動手勢）。
• 首次建立 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 的繪製框架。
  
  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 版本的穩定性（近期 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 引發的性能問題並最大可能下降了系統平臺的差別。
  
  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 開發；場景比較單1、樣式頻繁變動、交互簡單的需求頁面則使用 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 容器加強、業務插件化、虛擬運行環境等技術框架的不斷深耕、雕琢也都在推動大前端技術朝着一個統一的方向前進 -- 多端融合。咱們只能經過不斷的技術積累、輸出，才能追遇上大前端變革的浪潮，讓業務更好地依託技術爲用戶提供更優質的產品體驗。