前端這門技術，從誕生發展至今不過寥寥十餘年。如果說前十年是 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）的花容月貌？那麼，你現在看到的就是唯一的正确答案。
無聊的代碼千篇一律，有趣的崗位萬裡挑一，終端架構的未來如此廣闊，需要各位鼎力相助，歡迎加入阿裡淘系前端架構團隊！
我們是阿裡巴巴淘系技術部 - 大前端技術架構團隊，誠邀各路小夥伴的加入，一起做大事！
履歷可郵件投遞至[email protected] ，期待你的聯系。
1、
大比拼 | 下一代高性能跨平台UI渲染引擎2、
Flutter 動态化方案探索3、
最火移動端跨平台方案盤點：React Native、weex、Flutter4、
淺談 Hybrid App5、其它一些無法被引用的内外部資源
關注「淘系技術」微信公衆号，一個有溫度有内容的技術社群~