移動(dòng)前端開(kāi)發(fā)和Web前端開(kāi)發(fā)的區(qū)別是什么？

作者：阿里云開(kāi)發(fā)者 2020-09-24 17:15:11

前端這門(mén)技術(shù)，從誕生發(fā)展至今不過(guò)寥寥十余年。如果說(shuō)前十年是 PC 前端的時(shí)代，那后十年一定是屬于移動(dòng)前端的時(shí)代。今天來(lái)和大家分享一下我對(duì)「移動(dòng)前端開(kāi)發(fā)和 Web 前端開(kāi)發(fā)」的理解。

前端這門(mén)技術(shù)，從誕生發(fā)展至今不過(guò)寥寥十余年。如果說(shuō)前十年是 PC 前端的時(shí)代，那后十年一定是屬于移動(dòng)前端的時(shí)代。特別是隨著網(wǎng)絡(luò)制式的發(fā)展，移動(dòng)設(shè)備在全球范圍內(nèi)得到了空前的普及，在前端領(lǐng)域，Hybird Web、React Native、Weex、Flutter 等等一系列新的移動(dòng)前端技術(shù)也如同雨后春筍般冒出來(lái)，今天來(lái)和大家分享一下我對(duì)「移動(dòng)前端開(kāi)發(fā)和 Web 前端開(kāi)發(fā)」的理解。

回顧：前端發(fā)展史

▐ 階段一：刀耕火種

十多年前的前端，開(kāi)發(fā)者還在為兼容 IE6 而頭疼，框架上 jQuery 是老大，有追求的前端開(kāi)發(fā)可能會(huì)使用 Zepto.js 以減少網(wǎng)頁(yè)體積。這個(gè)時(shí)候，前端頁(yè)面主要還是以 PC 為主，這個(gè)時(shí)候根本沒(méi)有移動(dòng)前端的概念，在小小的手機(jī)屏幕上流量的頁(yè)面則是以純文本為主。

▐ 階段二：工程化

在 2011 ~ 2014 年之間的歷史階段里，模塊化的思路占為主導(dǎo)。當(dāng)時(shí)為了進(jìn)行 Assets 資源加載器的設(shè)計(jì)，就制定了模塊化的協(xié)議規(guī)范。當(dāng)時(shí)比較流行的模塊化協(xié)議就是 AMD（RequireJS）、CMD（Seajs 為代表）、KMD（Kissy 為代表）。在淘寶、天貓，Kissy 應(yīng)用的很火，所以 KMD 主導(dǎo)天下；在支付寶及外部社區(qū)，Seajs 應(yīng)用的很火，所以 CMD 主導(dǎo)天下，玉伯大大的名氣和威望也在前端圈里特別高；而 AMD 在國(guó)外比較流行，但漸漸也被后來(lái)出現(xiàn)的 CommonJS 規(guī)范削弱了氣勢(shì)。

▐ 階段三：移動(dòng)化

隨著 3G、4G 的發(fā)展和 iOS 和 Android 手機(jī)在市場(chǎng)的普及量大增，PC 業(yè)務(wù)主戰(zhàn)場(chǎng)也逐漸過(guò)渡到移動(dòng)端。前端的思維模式由 PC 轉(zhuǎn)向了移動(dòng)端，并向 App 的用戶體驗(yàn)看齊。移動(dòng)端的 HTML5 協(xié)議支持不完善，前端的生產(chǎn)配套不全，Android 的屏幕碎片化，所以那個(gè)時(shí)候的前端開(kāi)發(fā)移動(dòng)端頁(yè)面適配的痛苦要遠(yuǎn)遠(yuǎn)超過(guò) PC 時(shí)代。

[[343761]]

▐ 階段四：框架化

在前端社區(qū)，Angular、React、Vue、RN （React Native）這樣的 MV* 框架一個(gè)接著一個(gè)出現(xiàn)，讓前端接受了數(shù)據(jù)驅(qū)動(dòng)思想的洗禮之外，還借助 RN 完成了移動(dòng)端的體驗(yàn)升級(jí)，包括后來(lái)的 Weex、Flutter。

在這個(gè)階段，前端開(kāi)始有了終端的底層架構(gòu)組，開(kāi)始構(gòu)思前端頁(yè)面在移動(dòng)終端上的加載性能和用戶體驗(yàn)表現(xiàn)。在阿里巴巴內(nèi)部，為了解決多端復(fù)用的問(wèn)題，Rax 借助 VDOM 打通 WebView 和 Weex 兩端，一套代碼跑天下。

▐ 階段五：垂直化

隨著初代 iPhone 的發(fā)布，大屏幕手機(jī)逐漸變成了主流，移動(dòng)端的需求開(kāi)始爆發(fā)。在淘寶天貓，每年雙十一的移動(dòng)端成交額逐年攀升，并逐漸占領(lǐng)絕對(duì)領(lǐng)先地位。前端的領(lǐng)域也隨著這種趨勢(shì)逐漸細(xì)分，按照?qǐng)鼍翱梢院?jiǎn)單分為移動(dòng)(無(wú)線)前端開(kāi)發(fā)和中后臺(tái)前端開(kāi)發(fā)。

移動(dòng)前端開(kāi)發(fā)面向的是消費(fèi)者端的 Web 與輕 App 業(yè)務(wù)場(chǎng)景，在這個(gè)場(chǎng)景下，淘系經(jīng)過(guò)多年的營(yíng)銷活動(dòng)沉淀，逐漸形成了移動(dòng)端獨(dú)特的、輕量級(jí)的解決方案，以及模塊維度的、面向運(yùn)營(yíng)的頁(yè)面搭建系統(tǒng)。

中后臺(tái)前端則是面向企業(yè) ERP、CRM 、OA 等偏后的業(yè)務(wù)場(chǎng)景，如商家后臺(tái)等系統(tǒng)。在這個(gè)場(chǎng)景下，借助飛冰、Fusion Design 等中后臺(tái)物料，形成可視化的中后臺(tái)搭建解決方案，為業(yè)務(wù)的前端、開(kāi)發(fā)或產(chǎn)品角色提供一站式中后臺(tái)生產(chǎn)解決方案。

移動(dòng)前端：混合技術(shù)的前世今生

曾幾何時(shí)，移動(dòng)客戶端開(kāi)發(fā)和前端開(kāi)發(fā)是兩條沒(méi)有交集的平行線，但現(xiàn)在我們?cè)絹?lái)越擁抱兩者的合作產(chǎn)物：混合式(Hybird)應(yīng)用開(kāi)發(fā)，或者用最近比較火的一個(gè)概念 -- 大前端技術(shù)。

從技術(shù)的表現(xiàn)形式思考，本質(zhì)上客戶端開(kāi)發(fā)與前端開(kāi)發(fā)都是終端技術(shù)，它的特點(diǎn)是直接面向用戶 UI 編程。

▐ 同是 UI 編程，我們面對(duì)的痛點(diǎn)是什么？

傳統(tǒng) Web 前端技術(shù)的技術(shù)局限性

1、資源加載：HTML、JS、CSS、圖片等靜態(tài)資源存放于遠(yuǎn)端的服務(wù)器，需要?jiǎng)討B(tài)的異步拉取，再拉取數(shù)據(jù)進(jìn)行展示，初始化效率上比 Native 慢的多

2、渲染機(jī)制：在瀏覽器的設(shè)計(jì)中，JS 的執(zhí)行和頁(yè)面的布局、Paint 都在同一個(gè)主線程，無(wú)法并行化，再加上 JS 的性能趕不上 AOT 語(yǔ)言，執(zhí)行復(fù)雜邏輯時(shí)導(dǎo)致的卡頓通常會(huì)阻塞 UI，再加上冗長(zhǎng)的渲染管線，導(dǎo)致瀏覽器的渲染體驗(yàn)在等量對(duì)比 Native 時(shí)并不占優(yōu)勢(shì)。

3、頁(yè)面切換：在瀏覽器中并不存在路由的概念，這導(dǎo)致頁(yè)面間的切換體驗(yàn)完全依賴于瀏覽器 Shell 提供的能力，在頁(yè)面切換的時(shí)候會(huì)反復(fù)加載。當(dāng)然前端社區(qū)中也出現(xiàn)了單頁(yè)面應(yīng)用的概念，但是多個(gè)頁(yè)面的資源也顯著增加了 JSBundle 的體積，也使頁(yè)面的開(kāi)發(fā)更加復(fù)雜化了。

4、API 能力：瀏覽器的安全機(jī)制是基于同源策略的沙箱機(jī)制，這套沙箱機(jī)制阻止了前端開(kāi)發(fā)者使用原生系統(tǒng)能力，你只能使用 W3C 標(biāo)準(zhǔn)定義的功能，而且考慮到終端碎片化的問(wèn)題，這些接口往往不能直接使用。這在 PC 端的場(chǎng)景中是沒(méi)有什么問(wèn)題的，但是在移動(dòng)端則相反，開(kāi)發(fā)者希望有能力調(diào)用系統(tǒng)接口實(shí)現(xiàn)一些更富交互的場(chǎng)景。

5、交互性能：瀏覽器的實(shí)時(shí)交互性能體驗(yàn)差，在復(fù)雜交互場(chǎng)景中大規(guī)模的重排限制了 UI 幀率，這種限制在中低端移動(dòng)設(shè)備中尤為嚴(yán)重。

6、腳本語(yǔ)言，動(dòng)態(tài)解析執(zhí)行

JS 是一門(mén) JIT 語(yǔ)言，也就是需要?jiǎng)討B(tài)解析執(zhí)行，對(duì)比預(yù)先編譯機(jī)器碼的 AOT 語(yǔ)言的執(zhí)行性能就差得多了。

傳統(tǒng)客戶端技術(shù)的局限性？

1、動(dòng)態(tài)性：客戶端開(kāi)發(fā)通常是有固定的版本發(fā)布計(jì)劃，而且受制于 Apple 的 App Store 審核規(guī)則，版本發(fā)布的不確定性還會(huì)受到政策影響，Android 在國(guó)內(nèi)的渠道眾多，每次發(fā)版都要反復(fù)檢查渠道，一旦發(fā)現(xiàn)線上問(wèn)題需要依賴再次發(fā)版，容錯(cuò)成本非常高，這也大大增加了對(duì)業(yè)務(wù)的局限性。

2、開(kāi)發(fā)成本：客戶端的開(kāi)發(fā)成本高，然而生態(tài)還不如 Web 豐富，npm 社區(qū)的幾萬(wàn)開(kāi)源包，加上更活躍的開(kāi)發(fā)者社區(qū)，導(dǎo)致對(duì)企業(yè)來(lái)講客戶端的研發(fā)成本是高于 Web 開(kāi)發(fā)的。

3、跨端一致性：傳統(tǒng)客戶端開(kāi)發(fā)一套業(yè)務(wù)，是需要實(shí)現(xiàn) Android + iOS 兩套代碼的，而且由于 Android 和 iOS 的操作系統(tǒng)能力差異，同樣的需求往往會(huì)用不同的視覺(jué)和交互來(lái)實(shí)現(xiàn)，這也導(dǎo)致了業(yè)務(wù)成本居高不下。

▐ 混合式前端開(kāi)發(fā)

為什么會(huì)出現(xiàn)混合式前端開(kāi)發(fā)？

隨著 iOS + Android 確立了移動(dòng)操作系統(tǒng)的統(tǒng)治地位，前端開(kāi)發(fā)者也在尋找使用操作系統(tǒng)提供的能力進(jìn)行業(yè)務(wù)開(kāi)發(fā)的模式。Web 的開(kāi)發(fā)方式遠(yuǎn)比 iOS 和 Android 更加方便和高效，Web 上層出不窮的各種庫(kù)和框架也遠(yuǎn)比 Android 和 iOS 的各種庫(kù)和框架方便的多。Web 上我們可以方便的使用各種前端框架，及時(shí)預(yù)覽效果（想想大型 Android/iOS 工程的編譯時(shí)間）。

從阿里巴巴的角度來(lái)看，隨著中臺(tái)化的理念逐漸被接受：業(yè)務(wù)需要追求快速發(fā)展，前臺(tái)的 UI 和需求會(huì)隨著商業(yè)決策快速迭代，前端和客戶端不同的崗位也形成了分工化的研發(fā)模式。

前端向上，前置作為業(yè)務(wù)方的唯一接口，逐漸演變?yōu)榇笄岸说臉I(yè)務(wù)層。在這一層，它的職責(zé)是負(fù)責(zé)定義規(guī)范，通過(guò)框架規(guī)范業(yè)務(wù)的開(kāi)發(fā)過(guò)程，同時(shí)封裝統(tǒng)一的解決方案和工程化能力，將重復(fù)的工作抽離。

客戶端向下扎，解耦業(yè)務(wù)需求，轉(zhuǎn)為大前端的架構(gòu)層，給上層的業(yè)務(wù)開(kāi)發(fā)者提供能力支持。通過(guò)將客戶端的系統(tǒng)級(jí) API 以及宿主應(yīng)用的能力暴露給上層前端，提高前端頁(yè)面對(duì)更多富交互場(chǎng)景的承載能力。

在這樣的大背景下，各種混合開(kāi)發(fā)技術(shù)層出不窮，在這里我們簡(jiǎn)單的把混合式應(yīng)用的發(fā)展定義為三個(gè)階段：

▐ 階段一：JSBridge

在這個(gè)階段，主要還是以 WebView 為主，并配合 JSBridge 提供了 Naive 與 JS 之間的通信鏈路，基于這個(gè)通信基礎(chǔ)，Native可以暴露出一些標(biāo)準(zhǔn)服務(wù) API 提供給 JS 調(diào)用，同樣的 JS 也可以以此封裝一些基礎(chǔ)API給 Native 調(diào)用。前端開(kāi)發(fā)者使用傳統(tǒng)的 JS + HTML + CSS 進(jìn)行頁(yè)面的開(kāi)發(fā)，并且調(diào)用 JSBridge API 驅(qū)動(dòng)客戶端能力。在這個(gè)階段，Apache Cordova 是業(yè)內(nèi)的佼佼者，大多互聯(lián)網(wǎng)公司內(nèi)部也有自己的 JSBridge 框架實(shí)現(xiàn)，可以說(shuō) JSBridge 第一次給了前端開(kāi)發(fā)者調(diào)用 Native 的能力。

但是 JSBridge 方案的主要缺點(diǎn)在于性能方面及高級(jí)組件擴(kuò)展能力缺失，流暢性始終無(wú)法與 Native 媲美。

▐ 階段二：原生 UI

雖然 Web 的動(dòng)態(tài)性和高效的開(kāi)發(fā)效率，是原生開(kāi)發(fā)望塵莫及的，但是瀏覽器技術(shù)的瓶頸也非常明顯：

1、W3C 作為開(kāi)放的技術(shù)標(biāo)準(zhǔn)，歷史悠久，包袱多，顯著拖慢了瀏覽器的性能。

2、WebView 渲染引擎設(shè)計(jì)的上的缺陷，渲染流水線非常長(zhǎng)，導(dǎo)致瀏覽器對(duì)合成器動(dòng)畫(huà)和非合成器動(dòng)畫(huà)區(qū)別對(duì)待，非合成動(dòng)畫(huà)性能不好。

3、單線程模型，無(wú)法發(fā)揮現(xiàn)代硬件架構(gòu)特別是 ARM 架構(gòu)多核心的性能。

4、異步光柵化的設(shè)計(jì)，在進(jìn)行長(zhǎng)列表滾動(dòng)時(shí)，不可避免出現(xiàn)白屏的現(xiàn)象。

**有沒(méi)有一種兩全其美的方式?

React Native/Weex 的出現(xiàn)給前端開(kāi)發(fā)者帶來(lái)了一道曙光。**

React Native/Weex 利用 JS 引擎來(lái)調(diào)用 Native 端的組件，從而實(shí)現(xiàn)相應(yīng)的功能。React Native 和 Weex 都允許前端開(kāi)發(fā)者使用 JS 進(jìn)行業(yè)務(wù)邏輯開(kāi)發(fā)，使用 VDOM 來(lái)描述文檔結(jié)構(gòu)，并配合 CSS 的子集來(lái)定制樣式，樣式和模板分離。

Weex 體系中， JS 的執(zhí)行在 JS Thread，Layout 執(zhí)行在獨(dú)立的 Layout Thread ，渲染執(zhí)行在系統(tǒng)的 MainThread ，三個(gè)線程相互獨(dú)立，并行執(zhí)行。

在 WebView 的體系中 JS 的執(zhí)行、 Layout 、 Paint 都在 MainThread ，相互影響，在進(jìn)行復(fù)雜任務(wù)時(shí)會(huì)導(dǎo)致界面卡頓。

這種方案的優(yōu)勢(shì)在于最大化的復(fù)用前端的生態(tài)和 Native 的生態(tài)體系。

在阿里巴巴，Weex 的大規(guī)模應(yīng)用，甚至支撐起了雙十一億級(jí)的流量。

▐ 階段三：自繪引擎

什么是自繪引擎？

所謂自繪引擎，就是不依賴操作系統(tǒng)提供的布局、原生組件能力，直接調(diào)用 GPU 或者底層抽象層進(jìn)行繪制的渲染引擎。

在上一個(gè)階段，前端開(kāi)發(fā)者已經(jīng)可以使用 JS 引擎驅(qū)動(dòng)原生 UI 了，為什么還需要自繪引擎？

React Native/Weex 充分將 Native 的 View 體系輸出到前端體系中，在進(jìn)行 Android/iOS Native View 的封裝過(guò)程中，存在不少難以逾越的障礙。如：難以抹平的雙端一致性問(wèn)題、復(fù)雜樣式能力難以實(shí)現(xiàn)、 Layout 動(dòng)畫(huà)需要執(zhí)行兩次（WeexCore Layout 和 Android Native 本身的 Layout ）。組件的封裝成本隨著復(fù)雜度增加也越來(lái)越高，難以逾越 Native View 限制提供更細(xì)致的 W3C 標(biāo)準(zhǔn)能力。

2018 年 Flutter 誕生，通過(guò) Dart 語(yǔ)言構(gòu)建一套跨平臺(tái)的開(kāi)發(fā)組件，所有組件基于 Skia 引擎自繪，在性能上和 Native 平臺(tái)的 View 相媲美，同時(shí)解決了上一代架構(gòu)難以解決的雙端一致性等問(wèn)題。引起大家廣泛關(guān)注，充分驗(yàn)證了通過(guò)繪制構(gòu)建組件做到 Native View 媲美的 UI 渲染引擎的可行性。

但是 Flutter 本身是缺乏動(dòng)態(tài)更新特性的，社區(qū)上也有一些項(xiàng)目在探索 Flutter 的動(dòng)態(tài)化特性，我們團(tuán)隊(duì)內(nèi)部也在實(shí)現(xiàn)面向前端的動(dòng)態(tài)化 Flutter 引擎：Kraken，與其它方案不同的是 Kraken 并沒(méi)有基于 Flutter 自帶的 Widgets 框架進(jìn)行擴(kuò)展，而是從底層擴(kuò)展了 W3C 標(biāo)準(zhǔn)的 API，這使得它更像一個(gè)瀏覽器，也讓 Flutter 面向 Web 開(kāi)發(fā)者的使用門(mén)檻大大降低。

未來(lái)：回歸本源

天下大勢(shì)，分久必合，合久必分。移動(dòng)前端開(kāi)發(fā)本質(zhì)上還是終端開(kāi)發(fā)的一種形態(tài)，不管容器、框架、語(yǔ)言怎么變，在前端開(kāi)發(fā)者中只有 W3C 的標(biāo)準(zhǔn)是永遠(yuǎn)不變的。筆者認(rèn)為，隨著 Web 的發(fā)展，在解決一系列性能、體驗(yàn)問(wèn)題之后，瀏覽器技術(shù)會(huì)成為更通用的 UI 編程標(biāo)準(zhǔn)。

▐ PWA

早先年，Google 就已經(jīng)在這一領(lǐng)域內(nèi)努力，推出了 PWA (Progress Web Application) 的概念。

PWA 通過(guò)在移動(dòng)端瀏覽器提供標(biāo)準(zhǔn)化框架，在 Web App 中實(shí)現(xiàn)和 Native App 接近的用戶體驗(yàn)。它的特性其實(shí)是一系列 W3C 標(biāo)準(zhǔn)和私有標(biāo)準(zhǔn)集合，簡(jiǎn)單的說(shuō) PWA 支持：

離線加載：通過(guò) Service Worker 等提供的緩存機(jī)制，允許用戶在斷網(wǎng)或者弱網(wǎng)的情況下直接讀取離線資源。
后臺(tái)駐留進(jìn)程：正常情況下，瀏覽器的頁(yè)面關(guān)閉后它的整個(gè)生命周期就結(jié)束了，內(nèi)存也得到了釋放。Service Worker 允許頁(yè)面在關(guān)閉的情況下繼續(xù)運(yùn)行，這保證了類似于離線緩存、主動(dòng)推送等。
消息通知：允許 Web 開(kāi)發(fā)者實(shí)現(xiàn)類似 App 的主動(dòng)推送機(jī)制。
其它移動(dòng) App 的功能特性，如直接保存圖標(biāo)到桌面，允許用戶像正常使用 App 一樣打開(kāi) PWA 應(yīng)用；可以隱藏 UI 中的默認(rèn)瀏覽器元素，讓 Web 內(nèi)容全屏展示，從視覺(jué)上看讓 Web 應(yīng)用更像一個(gè)原生應(yīng)用，有時(shí)候你根本無(wú)法分辨到底是 Web 應(yīng)用還是原生應(yīng)用。

▐ PHA

當(dāng)然在標(biāo)準(zhǔn)能力不完善，業(yè)務(wù)又需要定制化能力的當(dāng)下，混合式應(yīng)用還會(huì)繼續(xù)發(fā)展。

PHA (Progress Hybird Application) 的概念應(yīng)用而生，PHA 是一種漸進(jìn)式的混合應(yīng)用增強(qiáng)策略，提供端測(cè)的輔助能力，提升 WebView 的渲染性能與體驗(yàn)。廣義地說(shuō)，當(dāng)下比較火的小程序、快應(yīng)用都是 PHA 的一種實(shí)現(xiàn)。

在淘系內(nèi)部，我們也在實(shí)現(xiàn)一套輕量級(jí)的 PHA 方案，并且在大促中也取得了不錯(cuò)的效果，我想后面單獨(dú)出一篇關(guān)于 PHA 的文章來(lái)闡述。

關(guān)于未來(lái)，隨著技術(shù)方案的多樣化、以及端邊界的擴(kuò)展，我們認(rèn)為最重要的就是效率與性能的問(wèn)題。