簡介： 前端這門技術，從誕生髮展至今不過寥寥十餘年。如果說前十年是 PC 前端的時代，那後十年一定是屬於移動前端的時代。特別是隨著網路制式的發展，移動裝置在全球範圍內得到了空前的普及，在前端領域，Hybird Web、React Native、Weex、Flutter 等等一系列新的移動前端技術也如同雨後春筍般冒出來，今天來和大家分享一下我對「移動前端開發和 Web 前端開發」的理解。
前端這門技術，從誕生髮展至今不過寥寥十餘年。如果說前十年是 PC 前端的時代，那後十年一定是屬於移動前端的時代。特別是隨著網路制式的發展，移動裝置在全球範圍內得到了空前的普及，在前端領域，Hybird Web、React Native、Weex、Flutter 等等一系列新的移動前端技術也如同雨後春筍般冒出來，今天來和大家分享一下我對「移動前端開發和 Web 前端開發」的理解。
回顧：前端發展史
▐ 階段一：刀耕火種
十多年前的前端，開發者還在為相容 IE6 而頭疼，框架上 jQuery 是老大，有追求的前端開發可能會使用 Zepto.js 以減少網頁體積。這個時候，前端頁面主要還是以 PC 為主，這個時候根本沒有移動前端的概念，在小小的手機螢幕上流量的頁面則是以純文字為主。
▐ 階段二：工程化
在 2011 ~ 2014 年之間的歷史階段裡，模組化的思路佔為主導。當時為了進行 Assets 資源載入器的設計，就制定了模組化的協議規範。當時比較流行的模組化協議就是 AMD（RequireJS）、CMD（Seajs 為代表）、KMD（Kissy 為代表）。在淘寶、天貓，Kissy 應用的很火，所以 KMD 主導天下；在支付寶及外部社群，Seajs 應用的很火，所以 CMD 主導天下，玉伯大大的名氣和威望也在前端圈裡特別高；而 AMD 在國外比較流行，但漸漸也被後來出現的 CommonJS 規範削弱了氣勢。
▐ 階段三：移動化
隨著 3G、4G 的發展和 iOS 和 Android 手機在市場的普及量大增，PC 業務主戰場也逐漸過渡到移動端。前端的思維模式由 PC 轉向了移動端，並向 App 的使用者體驗看齊。移動端的 HTML5 協議支援不完善，前端的生產配套不全，Android 的螢幕碎片化，所以那個時候的前端開發移動端頁面適配的痛苦要遠遠超過 PC 時代。
▐ 階段四：框架化
在前端社群，Angular、React、Vue、RN （React Native） 這樣的 MV* 框架一個接著一個出現，讓前端接受了資料驅動思想的洗禮之外，還藉助 RN 完成了移動端的體驗升級，包括後來的 Weex、Flutter。
在這個階段，前端開始有了終端的底層架構組，開始構思前端頁面在移動終端上的載入效能和使用者體驗表現。在阿里巴巴內部，為了解決多端複用的問題，Rax 藉助 VDOM 打通 WebView 和 Weex 兩端，一套程式碼跑天下。
▐ 階段五：垂直化
隨著初代 iPhone 的釋出，大螢幕手機逐漸變成了主流，移動端的需求開始爆發。在淘寶天貓，每年雙十一的移動端成交額逐年攀升，並逐漸佔領絕對領先地位。前端的領域也隨著這種趨勢逐漸細分，按照場景可以簡單分為移動(無線)前端開發和中後臺前端開發。
移動前端開發面向的是消費者端的 Web 與 輕 App 業務場景，在這個場景下，淘系經過多年的營銷活動沉澱，逐漸形成了移動端獨特的、輕量級的解決方案，以及模組維度的、面向運營的頁面搭建系統。
中後臺前端則是面向企業 ERP、CRM 、OA 等偏後的業務場景，如商家後臺等系統。在這個場景下，藉助飛冰、Fusion Design 等中後臺物料，形成視覺化的中後臺搭建解決方案，為業務的前端、開發或產品角色提供一站式中後臺生產解決方案。
移動前端：混合技術的前世今生
曾幾何時，移動客戶端開發和前端開發是兩條沒有交集的平行線，但現在我們越來越擁抱兩者的合作產物：混合式(Hybird)應用開發，或者用最近比較火的一個概念 -- 大前端技術。
從技術的表現形式思考，本質上客戶端開發與前端開發都是終端技術，它的特點是直接面向使用者 UI 程式設計。
▐ 同是 UI 程式設計，我們面對的痛點是什麼？
傳統 Web 前端技術的技術侷限性
1、資源載入：HTML、JS、CSS、圖片等靜態資源存放於遠端的伺服器，需要動態的非同步拉取，再拉取資料進行展示，初始化效率上比 Native 慢的多
2、渲染機制：在瀏覽器的設計中，JS 的執行和頁面的佈局、Paint 都在同一個主執行緒，無法並行化，再加上 JS 的效能趕不上 AOT 語言，執行復雜邏輯時導致的卡頓通常會阻塞 UI，再加上冗長的渲染管線，導致瀏覽器的渲染體驗在等量對比 Native 時並不佔優勢。
3、頁面切換：在瀏覽器中並不存在路由的概念，這導致頁面間的切換體驗完全依賴於瀏覽器 Shell 提供的能力，在頁面切換的時候會反覆載入。當然前端社群中也出現了單頁面應用的概念，但是多個頁面的資源也顯著增加了 JSBundle 的體積，也使頁面的開發更加複雜化了。
4、API 能力：瀏覽器的安全機制是基於同源策略的沙箱機制，這套沙箱機制阻止了前端開發者使用原生系統能力，你只能使用 W3C 標準定義的功能，而且考慮到終端碎片化的問題，這些介面往往不能直接使用。這在 PC 端的場景中是沒有什麼問題的，但是在移動端則相反，開發者希望有能力呼叫系統介面實現一些更富互動的場景。
5、互動效能：瀏覽器的實時互動效能體驗差，在複雜互動場景中大規模的重排限制了 UI 幀率，這種限制在中低端移動裝置中尤為嚴重。
6、指令碼語言，動態解析執行
JS 是一門 JIT 語言，也就是需要動態解析執行，對比預先編譯機器碼的 AOT 語言的執行效能就差得多了。
傳統客戶端技術的侷限性？
1、動態性：客戶端開發通常是有固定的版本釋出計劃，而且受制於 Apple 的 App Store 稽核規則，版本釋出的不確定性還會受到政策影響，Android 在國內的渠道眾多，每次發版都要反覆檢查渠道，一旦發現線上問題需要依賴再次發版，容錯成本非常高，這也大大增加了對業務的侷限性。
2、開發成本：客戶端的開發成本高，然而生態還不如 Web 豐富，npm 社群的幾萬開源包，加上更活躍的開發者社群，導致對企業來講客戶端的研發成本是高於 Web 開發的。
3、跨端一致性：傳統客戶端開發一套業務，是需要實現 Android + iOS 兩套程式碼的，而且由於 Android 和 iOS 的作業系統能力差異，同樣的需求往往會用不同的視覺和互動來實現，這也導致了業務成本居高不下。
▐ 混合式前端開發
為什麼會出現混合式前端開發？
隨著 iOS + Android 確立了移動作業系統的統治地位，前端開發者也在尋找使用作業系統提供的能力進行業務開發的模式。Web 的開發方式遠比 iOS 和 Android 更加方便和高效，Web 上層出不窮的各種庫和框架也遠比 Android 和 iOS 的各種庫和框架方便的多。Web 上我們可以方便的使用各種前端框架，及時預覽效果（想想大型 Android/iOS 工程的編譯時間）。
從阿里巴巴的角度來看，隨著中臺化的理念逐漸被接受：業務需要追求快速發展，前臺的 UI 和需求會隨著商業決策快速迭代，前端和客戶端不同的崗位也形成了分工化的研發模式。
前端向上，前置作為業務方的唯一介面，逐漸演變為大前端的業務層。在這一層，它的職責是負責定義規範，通過框架規範業務的開發過程，同時封裝統一的解決方案和工程化能力，將重複的工作抽離。
客戶端向下扎，解耦業務需求，轉為大前端的架構層，給上層的業務開發者提供能力支援。通過將客戶端的系統級 API 以及宿主應用的能力暴露給上層前端，提高前端頁面對更多富互動場景的承載能力。
在這樣的大背景下，各種混合開發技術層出不窮，在這裡我們簡單的把混合式應用的發展定義為三個階段：
▐ 階段一：JSBridge
在這個階段，主要還是以 WebView 為主，並配合 JSBridge 提供了 Naive 與 JS 之間的通訊鏈路，基於這個通訊基礎，Native可以暴露出一些標準服務 API 提供給 JS 呼叫，同樣的 JS 也可以以此封裝一些基礎API給 Native 呼叫。前端開發者使用傳統的 JS + HTML + CSS 進行頁面的開發，並且呼叫 JSBridge API 驅動客戶端能力。在這個階段，Apache Cordova 是業內的佼佼者，大多網際網路公司內部也有自己的 JSBridge 框架實現，可以說 JSBridge 第一次給了前端開發者呼叫 Native 的能力。
但是 JSBridge 方案的主要缺點在於效能方面及高階元件擴充套件能力缺失，流暢性始終無法與 Native 媲美。
▐ 階段二：原生 UI
雖然 Web 的動態性和高效的開發效率，是原生開發望塵莫及的，但是瀏覽器技術的瓶頸也非常明顯：
1、W3C 作為開放的技術標準，歷史悠久，包袱多，顯著拖慢了瀏覽器的效能。
2、WebView 渲染引擎設計的上的缺陷，渲染流水線非常長，導致瀏覽器對合成器動畫和非合成器動畫區別對待，非合成動畫效能不好。
3、單執行緒模型，無法發揮現代硬體架構特別是 ARM 架構多核心的效能。
4、非同步光柵化的設計，在進行長列表滾動時，不可避免出現白屏的現象。
**有沒有一種兩全其美的方式?
React Native/Weex 的出現給前端開發者帶來了一道曙光。**
React Native/Weex 利用 JS 引擎來呼叫 Native 端的元件，從而實現相應的功能。React Native 和 Weex 都允許前端開發者使用 JS 進行業務邏輯開發，使用 VDOM 來描述文件結構，並配合 CSS 的子集來定製樣式，樣式和模板分離。
Weex 體系中， JS 的執行在 JS Thread，Layout 執行在獨立的 Layout Thread ，渲染執行在系統的 MainThread ，三個執行緒相互獨立，並行執行。
在 WebView 的體系中 JS 的執行、 Layout 、 Paint 都在 MainThread ，相互影響，在進行復雜任務時會導致介面卡頓。
這種方案的優勢在於最大化的複用前端的生態和 Native 的生態體系。
在阿里巴巴，Weex 的大規模應用，甚至支撐起了雙十一億級的流量。
▐ 階段三：自繪引擎
什麼是自繪引擎？
所謂自繪引擎，就是不依賴作業系統提供的佈局、原生元件能力，直接呼叫 GPU 或者底層抽象層進行繪製的渲染引擎。
在上一個階段，前端開發者已經可以使用 JS 引擎驅動原生 UI 了，為什麼還需要自繪引擎？
React Native/Weex 充分將 Native 的 View 體系輸出到前端體系中，在進行 Android/iOS Native View 的封裝過程中，存在不少難以逾越的障礙。如：難以抹平的雙端一致性問題、複雜樣式能力難以實現、 Layout 動畫需要執行兩次（WeexCore Layout 和 Android Native 本身的 Layout ）。元件的封裝成本隨著複雜度增加也越來越高，難以逾越 Native View 限制提供更細緻的 W3C 標準能力。
2018 年 Flutter 誕生，通過 Dart 語言構建一套跨平臺的開發元件，所有元件基於 Skia 引擎自繪，在效能上和 Native 平臺的 View 相媲美，同時解決了上一代架構難以解決的雙端一致性等問題。引起大家廣泛關注，充分驗證了通過繪製構建元件做到 Native View 媲美的 UI 渲染引擎的可行性。
但是 Flutter 本身是缺乏動態更新特性的，社群上也有一些專案在探索 Flutter 的動態化特性，我們團隊內部也在實現面向前端的動態化 Flutter 引擎：Kraken，與其它方案不同的是 Kraken 並沒有基於 Flutter 自帶的 Widgets 框架進行擴充套件，而是從底層擴充套件了 W3C 標準的 API，這使得它更像一個瀏覽器，也讓 Flutter 面向 Web 開發者的使用門檻大大降低。
未來：迴歸本源
天下大勢，分久必合，合久必分。移動前端開發本質上還是終端開發的一種形態，不管容器、框架、語言怎麼變，在前端開發者中只有 W3C 的標準是永遠不變的。筆者認為，隨著 Web 的發展，在解決一系列效能、體驗問題之後，瀏覽器技術會成為更通用的 UI 程式設計標準。
▐ PWA
早先年，Google 就已經在這一領域內努力，推出了 PWA (Progress Web Application) 的概念。
PWA 通過在移動端瀏覽器提供標準化框架，在 Web App 中實現和 Native App 接近的使用者體驗。它的特性其實是一系列 W3C 標準和私有標準集合，簡單的說 PWA 支援：
- 離線載入：通過 Service Worker 等提供的快取機制，允許使用者在斷網或者弱網的情況下直接讀取離線資源。
- 後臺駐留程式：正常情況下，瀏覽器的頁面關閉後它的整個生命週期就結束了，記憶體也得到了釋放。Service Worker 允許頁面在關閉的情況下繼續執行，這保證了類似於離線快取、主動推送等。
- 訊息通知：允許 Web 開發者實現類似 App 的主動推送機制。
- 其它移動 App 的功能特性，如直接儲存圖示到桌面，允許使用者像正常使用 App 一樣開啟 PWA 應用；可以隱藏 UI 中的預設瀏覽器元素，讓 Web 內容全屏展示，從視覺上看讓 Web 應用更像一個原生應用，有時候你根本無法分辨到底是 Web 應用還是原生應用。
▐ PHA
當然在標準能力不完善，業務又需要定製化能力的當下，混合式應用還會繼續發展。
PHA (Progress Hybird Application) 的概念應用而生，PHA 是一種漸進式的混合應用增強策略， 提供端測的輔助能力，提升 WebView 的渲染效能與體驗。廣義地說，當下比較火的小程式、快應用都是 PHA 的一種實現。
在淘系內部，我們也在實現一套輕量級的 PHA 方案，並且在大促中也取得了不錯的效果，我想後面單獨出一篇關於 PHA 的文章來闡述。
關於未來，隨著技術方案的多樣化、以及端邊界的擴充套件，我們認為最重要的就是效率與效能的問題。
基於大資料的機器學習能力，移動端上會擁有更高效的 UI 編排能力，最終能讓 UI 渲染實現實時個性化。
基於最近比較熱的 WebAssembly 能力，讓瀏覽器突破 JavaScript 的限制，能擁有更大的想象空間。
作者|卓凌
編輯|橙子君
出品|阿里巴巴新零售淘系技術部
One More Thing
我們是 Rax、飛冰(ICE)、GCanvas 等炙手可熱開源專案的開山鼻祖，是你在阿里寫前端時繞不開的愛恨糾纏。想不想為集團的前端架構夯實地基讓百米高樓更加堅若磐石？想不想讓自己的程式碼造福社群引人膜拜？想不想窺探窺探下一代渲染引擎（Kraken）和下一代手淘應用容器（PHA）的花容月貌？那麼，你現在看到的就是唯一的正確答案。
無聊的程式碼千篇一律，有趣的崗位萬里挑一，終端架構的未來如此廣闊，需要各位鼎力相助，歡迎加入阿里淘系前端架構團隊！
我們是阿里巴巴淘系技術部 - 大前端技術架構團隊，誠邀各路小夥伴的加入，一起做大事！
簡歷可郵件投遞至zhuoling.lcl@alibaba-inc.com ，期待你的聯絡。
1、大比拼 | 下一代高效能跨平臺UI渲染引擎
2、Flutter 動態化方案探索
3、最火移動端跨平臺方案盤點：React Native、weex、Flutter
4、淺談 Hybrid App
5、其它一些無法被引用的內外部資源