摘要：接下來，我將從原理優(yōu)缺點(diǎn)等方面為大家分享跨平臺技術(shù)演進(jìn)。小程序年是微信小程序飛速發(fā)展的一年，年，各大廠商快速跟進(jìn)，已經(jīng)有了很大的影響力。下面，我們以微信小程序?yàn)槔治鲂〕绦虻募夹g(shù)架構(gòu)。

大家好，我是simbawu ，@BooheeFE Team Leader，關(guān)于這篇文章，有問題歡迎來這里討論。

隨著移動(dòng)互聯(lián)網(wǎng)的普及和快速發(fā)展，手機(jī)成了互聯(lián)網(wǎng)行業(yè)最大的流量分發(fā)入口。以及隨著5G的快速發(fā)展，未來越來越多的“端”也會如雨后春筍般快速興起。而“快”作為互聯(lián)網(wǎng)的生存之道，為了占領(lǐng)市場，企業(yè)也會積極跟進(jìn)，快速布局。同一個(gè)應(yīng)用，各個(gè)“端”獨(dú)立開發(fā)，不僅開發(fā)周期長，而且人員成本高。同時(shí)，作為技術(shù)人員，也不應(yīng)該滿足于這種重復(fù)、低能的工作狀態(tài)。在這樣的形勢下，跨平臺的技術(shù)方案也受到越來越多人和企業(yè)的關(guān)注。接下來，我將從原理、優(yōu)缺點(diǎn)等方面為大家分享《跨平臺技術(shù)演進(jìn)》。

說到跨平臺，沒人不知道H5。不管是在Mac、Windows、Linux、iOS、Android還是其他平臺，只要給一個(gè)瀏覽器，連“月球”上它都能跑。

下面，我們來看看讓H5如此橫行霸道的瀏覽器的架構(gòu)：

User Interface 用戶界面：提供用戶與瀏覽器交互

Browser Engine 瀏覽器引擎：控制渲染引擎與JS解釋器

Rendering Engine 渲染引擎：負(fù)責(zé)頁面渲染

JavaScript Interpreter JS解釋器：執(zhí)行JS代碼，輸出結(jié)果給渲染引擎

Networking 網(wǎng)絡(luò)工作組：處理網(wǎng)絡(luò)請求

UI Backend UI后端：繪制窗口小部件

Data Storage 數(shù)據(jù)存儲：管理用戶數(shù)據(jù)

瀏覽器由以上7個(gè)部分組成，而“渲染引擎”是性能優(yōu)化的重中之重，一起了解其中的渲染原理。

不同的瀏覽器內(nèi)核不同，渲染過程會不太一樣，但主要流程還是一致的。

分為下面6步驟：

HTML解析出DOM Tree

CSS解析出CSSOM

DOM Tree與CSSOM關(guān)聯(lián)生成Render Tree

Layout 根據(jù)Render Tree計(jì)算每個(gè)節(jié)點(diǎn)的尺寸、位置

Painting 根據(jù)計(jì)算好的信息繪制整個(gè)頁面的像素信息

Composite 將多個(gè)復(fù)合圖層發(fā)送給GPU，GPU會將各層合成，然后顯示在屏幕上。

從以上6步，我們可以總結(jié)渲染優(yōu)化的要點(diǎn)：

Layout在瀏覽器渲染過程中比較耗時(shí)，應(yīng)盡可能避免重排的產(chǎn)生

復(fù)合圖層占用內(nèi)存比重非常高，可采用減小復(fù)合圖層進(jìn)行優(yōu)化

以上就是瀏覽器端的內(nèi)容。但H5作為跨平臺技術(shù)的載體，是如何與不同平臺的App進(jìn)行交互的呢？這時(shí)候JSBridge就該出場了。

JSBridge，顧名思義，是JS和Native之間的橋梁，用來進(jìn)行JS和Native之間的通信。

通信分為以下兩個(gè)維度：

JavaScript 調(diào)用 Native，有兩種方式：

攔截URL Scheme：URL Scheme是一種類似于url的鏈接（boohee://goods/876898）,當(dāng)web前端發(fā)送URL Scheme請求之后，Native 攔截到請求并根據(jù)URL Scheme進(jìn)行相關(guān)操作。

注入API：通過 WebView 提供的接口，向 JavaScript 的 Context（window）中注入對象或者方法，讓 JavaScript 調(diào)用時(shí)，直接執(zhí)行相應(yīng)的 Native 代碼邏輯，達(dá)到 JavaScript 調(diào)用 Native 的目的。

Native 調(diào)用 JavaScript：
JavaScript暴露一個(gè)對象如JSBridge給window，讓Native能直接訪問。

那么App內(nèi)加載H5的過程是什么樣的呢？

打開H5分為4個(gè)階段：

交互無反饋

打開頁面 白屏

請求API，處于loading狀態(tài)

出現(xiàn)數(shù)據(jù)，正常展現(xiàn)

這四步，對應(yīng)的過程如上圖所以，我們可以針對性的做性能優(yōu)化。

下面，我們進(jìn)行H5的優(yōu)缺點(diǎn)分析：

優(yōu)點(diǎn)

跨平臺：只要有瀏覽器，任何平臺都可以訪問

開發(fā)成本低：生態(tài)成熟，學(xué)習(xí)成本低，調(diào)試方便

迭代速度快：無需審核，及時(shí)響應(yīng)，用戶可毫無感知使用最新版

缺點(diǎn)

性能問題：在反應(yīng)速度、流暢度、動(dòng)畫方面遠(yuǎn)不及原生

功能問題：對攝像頭、陀螺儀、麥克風(fēng)等硬件支持較差

雖然H5目前還存在不足，但隨著PWA、WebAssembly等技術(shù)的進(jìn)步，相信H5在未來能夠得到越來也好的發(fā)展。

2018年是微信小程序飛速發(fā)展的一年，19年，各大廠商快速跟進(jìn)，已經(jīng)有了很大的影響力。下面，我們以微信小程序?yàn)槔治鲂〕绦虻募夹g(shù)架構(gòu)。

小程序跟H5一樣，也是基于Webview實(shí)現(xiàn)。但它包含View視圖層、App Service邏輯層兩部分，分別獨(dú)立運(yùn)行在各自的WebView線程中。

可以理解為h5的頁面，提供UI渲染。由WAWebview.js來提供底層的功能,具體如下：

消息通信封裝為WeixinJSBridge

日志組件Reporter封裝

wx api（UI相關(guān)）

小程序組件實(shí)現(xiàn)和注冊

VirtualDOM，Diff和Render UI實(shí)現(xiàn)

頁面事件觸發(fā)

每個(gè)窗口都有一個(gè)獨(dú)立的WebView進(jìn)程，因此微信限制不能打開超過5個(gè)層級的頁面來保障用戶體驗(yàn)。

提供邏輯處理、數(shù)據(jù)請求、接口調(diào)用。由WAService.js來提供底層的功能,具體如下：

日志組件Reporter封裝

wx api

App,Page,getApp,getCurrentPages等全局方法

AMD模塊規(guī)范的實(shí)現(xiàn)

運(yùn)行環(huán)境：

iOS：JavaScriptCore

Andriod：X5內(nèi)核，基于Mobile Chrome 53/57

DevTool：nwjs Chrome 內(nèi)核

僅有一個(gè)WebView進(jìn)程

視圖層和邏輯層通過系統(tǒng)層的JSBridage進(jìn)行通信，邏輯層把數(shù)據(jù)變化通知到視圖層，觸發(fā)視圖層頁面更新，視圖層將觸發(fā)的事件通知到邏輯層進(jìn)行業(yè)務(wù)處理。

優(yōu)點(diǎn)

預(yù)加載WebView，準(zhǔn)備新頁面渲染

View層和邏輯層分離，通過數(shù)據(jù)驅(qū)動(dòng)，不直接操作DOM

使用Virtual DOM，進(jìn)行局部更新

組件化開發(fā)

缺點(diǎn)

仍使用WebView渲染，并非原生渲染，體驗(yàn)不佳

不能運(yùn)行在非微信環(huán)境內(nèi)

沒有window、document對象，不能使用基于瀏覽器的JS庫

不能靈活操作 DOM，無法實(shí)現(xiàn)較為復(fù)雜的效果

頁面大小、打開頁面數(shù)量都受到限制

既然WebView性能不佳，那有沒有更好的方案呢？下面我們看看React Native。

RN的理念是在不同平臺上編寫基于React的代碼，實(shí)現(xiàn)Learn once, write anywhere。

Virtual DOM在內(nèi)存中，可以通過不同的渲染引擎生成不同平臺下的UI，JS和Native之間通過Bridge通信

在 React 框架中，JSX 源碼通過 React 框架最終渲染到了瀏覽器的真實(shí) DOM 中，而在 React Native 框架中，JSX 源碼通過 React Native 框架編譯后，與Native原生的UI組件進(jìn)行映射，用原生代替DOM元素來渲染，在UI渲染上非常接近Native App。

### React Native 與Native平臺通信

React Native用JavaScriptCore作為JS的解析引擎，在Android上，需要應(yīng)用自己附帶JavaScriptCore，iOS上JavaScriptCore屬于系統(tǒng)的一部分，不需要應(yīng)用附帶。

用Bridge將JS和原生Native Code連接起來。Native和 JavaScript 兩端都保存了一份配置表，里面標(biāo)記了所有Native暴露給 JavaScript 的模塊和方法。交互通過傳遞 ModuleId、MethodId 和 Arguments 進(jìn)行。

優(yōu)點(diǎn)

垮平臺開發(fā)：相比原生的ios 和 android app各自維護(hù)一套業(yè)務(wù)邏輯大同小異的代碼，React Native 只需要同一套javascript 代碼就可以運(yùn)行于ios 和 android 兩個(gè)平臺，在開發(fā)、測試和維護(hù)的成本上要低很多。

快速編譯：相比Xcode中原生代碼需要較長時(shí)間的編譯，React Native 采用熱加載的即時(shí)編譯方式，使得App UI的開發(fā)體驗(yàn)得到改善，幾乎做到了和網(wǎng)頁開發(fā)一樣隨時(shí)更改，隨時(shí)可見的效果。

快速發(fā)布：React Native 可以通過 JSBundle 即時(shí)更新 App。相比原來冗長的審核和上傳過程，發(fā)布和測試新功能的效率大幅提高。

渲染和布局更高效：React Native擺脫了WebView的交互和性能問題，同時(shí)可以直接套用網(wǎng)頁開發(fā)中的css布局機(jī)制。脫了 autolayout 和 frame 布局中繁瑣的數(shù)學(xué)計(jì)算，更加直接簡便。

缺點(diǎn)

動(dòng)畫性能差：React Native 在動(dòng)畫效率和性能的支持還存在一些問題，性能上不如原生Api。

不能完全屏蔽原生平臺：就目前的React Native 官方文檔中可以發(fā)現(xiàn)仍有部分組件和API都區(qū)分了Android 和 IOS 版本,即便是共享組件,也會有平臺獨(dú)享的函數(shù)。也就是說仍不能真正實(shí)現(xiàn)嚴(yán)格意義上的“一套代碼，多平臺使用”。另外，因?yàn)槿詫os 和android的原生細(xì)節(jié)有所依賴，所以需要開發(fā)者若不了解原生平臺，可能會遇到一些坑。

生態(tài)不完善：缺乏很多基本控件，第三方開源質(zhì)量良莠不齊

雖然RN還存在不足，但RN新版本已經(jīng)做了如下改進(jìn)，并且RN團(tuán)隊(duì)也在積極準(zhǔn)備大版本重構(gòu)，能否成為開發(fā)者們所信賴的跨平臺方案，讓我們拭目以待。

改變線程模式。UI 更新不再同時(shí)需要在三個(gè)不同的線程上觸發(fā)執(zhí)行，而是可以在任意線程上同步調(diào)用 JavaScript 進(jìn)行優(yōu)先更新，同時(shí)將低優(yōu)先級工作推出主線程，以便保持對 UI 的響應(yīng)。

引入異步渲染能力。允許多個(gè)渲染并簡化異步數(shù)據(jù)處理。

簡化 JSBridge，讓它更快、更輕量。

既然React Native在渲染方面還擺脫不了原生，那有沒有一種方案是直接操控GPU，自制引擎渲染呢，我們終于迎來了Flutter！

Flutter是Google開發(fā)的一套全新的跨平臺、開源UI框架，支持iOS、Android系統(tǒng)開發(fā)，并且是未來新操作系統(tǒng)Fuchsia的默認(rèn)開發(fā)套件。渲染引擎依靠跨平臺的Skia圖形庫來實(shí)現(xiàn)，依賴系統(tǒng)的只有圖形繪制相關(guān)的接口，可以在最大程度上保證不同平臺、不同設(shè)備的體驗(yàn)一致性，邏輯處理使用支持AOT的Dart語言，執(zhí)行效率也比JavaScript高得多。

Framework：由Dart實(shí)現(xiàn)，包括Material Design風(fēng)格的Widget,Cupertino(針對iOS)風(fēng)格的Widgets，文本/圖片/按鈕等基礎(chǔ)Widgets，渲染，動(dòng)畫，手勢等。此部分的核心代碼是:flutter倉庫下的flutter package，以及sky_engine倉庫下的io,async,ui(dart:ui庫提供了Flutter框架和引擎之間的接口)等package。

Engine：由C++實(shí)現(xiàn)，主要包括:Skia,Dart和Text。

Skia是開源的二維圖形庫，提供了適用于多種軟硬件平臺的通用API。其已作為Google Chrome，Chrome OS，Android, Mozilla Firefox, Firefox OS等其他眾多產(chǎn)品的圖形引擎，支持平臺還包括Windows7+,macOS 10.10.5+,iOS8+,Android4.1+,Ubuntu14.04+等。Skia作為渲染/GPU后端，在Android和Fuchsia上使用FreeType渲染，在iOS上使用CoreGraphics來渲染字體。

Dart部分主要包括:Dart Runtime，Garbage Collection(GC)，如果是Debug模式的話，還包括JIT(Just In Time)支持。Release和Profile模式下，是AOT(Ahead Of Time)編譯成了原生的arm代碼，并不存在JIT部分。

Text即文本渲染，其渲染層次如下:衍生自minikin的libtxt庫(用于字體選擇，分隔行)。HartBuzz用于字形選擇和成型。

Embedder：是一個(gè)嵌入層，即把Flutter嵌入到各個(gè)平臺上去，這里做的主要工作包括渲染Surface設(shè)置,線程設(shè)置，以及插件等。從這里可以看出，F(xiàn)lutter的平臺相關(guān)層很低，平臺(如iOS)只是提供一個(gè)畫布，剩余的所有渲染相關(guān)的邏輯都在Flutter內(nèi)部，這就使得它具有了很好的跨端一致性。

很多人會好奇，為什么Flutter要用Dart，而不是用JavaScript開發(fā)，這里列下Dart的優(yōu)勢

Dart 的性能更好。Dart在 JIT模式下，速度與 JavaScript基本持平。但是 Dart支持 AOT，當(dāng)以 AOT模式運(yùn)行時(shí)，JavaScript便遠(yuǎn)遠(yuǎn)追不上了。速度的提升對高幀率下的視圖數(shù)據(jù)計(jì)算很有幫助。

Native Binding。在 Android上，v8的 Native Binding可以很好地實(shí)現(xiàn)，但是 iOS上的 JavaScriptCore不可以，所以如果使用 JavaScript，F(xiàn)lutter 基礎(chǔ)框架的代碼模式就很難統(tǒng)一了。而 Dart的 Native Binding可以很好地通過 Dart Lib實(shí)現(xiàn)。

Fuchsia OS。Fuchsia OS內(nèi)置的應(yīng)用瀏覽器就是使用 Dart語言作為 App的開發(fā)語言。

優(yōu)點(diǎn)

性能強(qiáng)大：在兩個(gè)平臺上重寫了各自的UIKit，對接到平臺底層，減少UI層的多層轉(zhuǎn)換，UI性能可以比肩原生

優(yōu)秀的語言特性：參考上面Dart優(yōu)勢分析

路由設(shè)計(jì)優(yōu)秀：Flutter的路由傳值非常方便，push一個(gè)路由，會返回一個(gè)Future對象（也就是Promise對象），使用await或者.then就可以在目標(biāo)路由pop，回到當(dāng)前頁面時(shí)收到返回值。

缺點(diǎn)

優(yōu)點(diǎn)即缺點(diǎn)，Dart 語言的生態(tài)小，精通成本比較高

UI控件API設(shè)計(jì)不佳

與原生融合障礙很多，不利于漸進(jìn)式升級

移動(dòng)互聯(lián)網(wǎng)的普及和快速發(fā)展，跨平臺技術(shù)風(fēng)起云涌，這也是技術(shù)發(fā)展過程中的必經(jīng)之路，等浪潮退去，才知道誰在裸泳。我個(gè)人更看好H5或類H5方案，給它一個(gè)瀏覽器，連“月球”都能跑，這才是真正的跨平臺，其他都是浮云。

本文發(fā)布于薄荷前端周刊，歡迎Watch & Star ★，轉(zhuǎn)載請注明出處。