摘要：接下來，我將從原理優缺點等方面為大家分享跨平臺技術演進。小程序年是微信小程序飛速發展的一年，年，各大廠商快速跟進，已經有了很大的影響力。下面，我們以微信小程序為例，分析小程序的技術架構。

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

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

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

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

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

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

Rendering Engine 渲染引擎：負責頁面渲染

JavaScript Interpreter JS解釋器：執行JS代碼，輸出結果給渲染引擎

Networking 網絡工作組：處理網絡請求

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

Data Storage 數據存儲：管理用戶數據

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

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

分為下面6步驟：

HTML解析出DOM Tree

CSS解析出CSSOM

DOM Tree與CSSOM關聯生成Render Tree

Layout 根據Render Tree計算每個節點的尺寸、位置

Painting 根據計算好的信息繪制整個頁面的像素信息

Composite 將多個復合圖層發送給GPU，GPU會將各層合成，然后顯示在屏幕上。

從以上6步，我們可以總結渲染優化的要點：

Layout在瀏覽器渲染過程中比較耗時，應盡可能避免重排的產生

復合圖層占用內存比重非常高，可采用減小復合圖層進行優化

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

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

通信分為以下兩個維度：

JavaScript 調用 Native，有兩種方式：

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

注入API：通過 WebView 提供的接口，向 JavaScript 的 Context（window）中注入對象或者方法，讓 JavaScript 調用時，直接執行相應的 Native 代碼邏輯，達到 JavaScript 調用 Native 的目的。

Native 調用 JavaScript：
JavaScript暴露一個對象如JSBridge給window，讓Native能直接訪問。

那么App內加載H5的過程是什么樣的呢？

打開H5分為4個階段：

交互無反饋

打開頁面 白屏

請求API，處于loading狀態

出現數據，正常展現

這四步，對應的過程如上圖所以，我們可以針對性的做性能優化。

下面，我們進行H5的優缺點分析：

優點

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

開發成本低：生態成熟，學習成本低，調試方便

迭代速度快：無需審核，及時響應，用戶可毫無感知使用最新版

缺點

性能問題：在反應速度、流暢度、動畫方面遠不及原生

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

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

2018年是微信小程序飛速發展的一年，19年，各大廠商快速跟進，已經有了很大的影響力。下面，我們以微信小程序為例，分析小程序的技術架構。

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

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

消息通信封裝為WeixinJSBridge

日志組件Reporter封裝

wx api（UI相關）

小程序組件實現和注冊

VirtualDOM，Diff和Render UI實現

頁面事件觸發

每個窗口都有一個獨立的WebView進程，因此微信限制不能打開超過5個層級的頁面來保障用戶體驗。

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

日志組件Reporter封裝

wx api

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

AMD模塊規范的實現

運行環境：

iOS：JavaScriptCore

Andriod：X5內核，基于Mobile Chrome 53/57

DevTool：nwjs Chrome 內核

僅有一個WebView進程

視圖層和邏輯層通過系統層的JSBridage進行通信，邏輯層把數據變化通知到視圖層，觸發視圖層頁面更新，視圖層將觸發的事件通知到邏輯層進行業務處理。

優點

預加載WebView，準備新頁面渲染

View層和邏輯層分離，通過數據驅動，不直接操作DOM

使用Virtual DOM，進行局部更新

組件化開發

缺點

仍使用WebView渲染，并非原生渲染，體驗不佳

不能運行在非微信環境內

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

不能靈活操作 DOM，無法實現較為復雜的效果

頁面大小、打開頁面數量都受到限制

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

RN的理念是在不同平臺上編寫基于React的代碼，實現Learn once, write anywhere。

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

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

### React Native 與Native平臺通信

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

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

優點

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

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

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

渲染和布局更高效：React Native擺脫了WebView的交互和性能問題，同時可以直接套用網頁開發中的css布局機制。脫了 autolayout 和 frame 布局中繁瑣的數學計算，更加直接簡便。

缺點

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

不能完全屏蔽原生平臺：就目前的React Native 官方文檔中可以發現仍有部分組件和API都區分了Android 和 IOS 版本,即便是共享組件,也會有平臺獨享的函數。也就是說仍不能真正實現嚴格意義上的“一套代碼，多平臺使用”。另外，因為仍對ios 和android的原生細節有所依賴，所以需要開發者若不了解原生平臺，可能會遇到一些坑。

生態不完善：缺乏很多基本控件，第三方開源質量良莠不齊

雖然RN還存在不足，但RN新版本已經做了如下改進，并且RN團隊也在積極準備大版本重構，能否成為開發者們所信賴的跨平臺方案，讓我們拭目以待。

改變線程模式。UI 更新不再同時需要在三個不同的線程上觸發執行，而是可以在任意線程上同步調用 JavaScript 進行優先更新，同時將低優先級工作推出主線程，以便保持對 UI 的響應。

引入異步渲染能力。允許多個渲染并簡化異步數據處理。

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

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

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

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

Engine：由C++實現，主要包括:Skia,Dart和Text。

Skia是開源的二維圖形庫，提供了適用于多種軟硬件平臺的通用API。其已作為Google Chrome，Chrome OS，Android, Mozilla Firefox, Firefox OS等其他眾多產品的圖形引擎，支持平臺還包括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：是一個嵌入層，即把Flutter嵌入到各個平臺上去，這里做的主要工作包括渲染Surface設置,線程設置，以及插件等。從這里可以看出，Flutter的平臺相關層很低，平臺(如iOS)只是提供一個畫布，剩余的所有渲染相關的邏輯都在Flutter內部，這就使得它具有了很好的跨端一致性。

很多人會好奇，為什么Flutter要用Dart，而不是用JavaScript開發，這里列下Dart的優勢

Dart 的性能更好。Dart在 JIT模式下，速度與 JavaScript基本持平。但是 Dart支持 AOT，當以 AOT模式運行時，JavaScript便遠遠追不上了。速度的提升對高幀率下的視圖數據計算很有幫助。

Native Binding。在 Android上，v8的 Native Binding可以很好地實現，但是 iOS上的 JavaScriptCore不可以，所以如果使用 JavaScript，Flutter 基礎框架的代碼模式就很難統一了。而 Dart的 Native Binding可以很好地通過 Dart Lib實現。

Fuchsia OS。Fuchsia OS內置的應用瀏覽器就是使用 Dart語言作為 App的開發語言。

優點

性能強大：在兩個平臺上重寫了各自的UIKit，對接到平臺底層，減少UI層的多層轉換，UI性能可以比肩原生

優秀的語言特性：參考上面Dart優勢分析

路由設計優秀：Flutter的路由傳值非常方便，push一個路由，會返回一個Future對象（也就是Promise對象），使用await或者.then就可以在目標路由pop，回到當前頁面時收到返回值。

缺點

優點即缺點，Dart 語言的生態小，精通成本比較高

UI控件API設計不佳

與原生融合障礙很多，不利于漸進式升級

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

本文發布于薄荷前端周刊，歡迎Watch & Star ★，轉載請注明出處。