[[400044]]

本文轉載自微信公眾號「業余碼農」，作者Amazing10。轉載本文請聯系業余碼農公眾號。

大家好，我是安醬。有時候需要走出自己的舒適區，了解下別的領域的技術。老是聽說「客三消」，所以不如今天咱們就來隨便聊聊可能會決定客戶端未來的跨端技術吧。

阿里的大佬們曾總結，「一般來說，跨端技術有 4 類場景，分別是跨設備平臺(跨Web端和手機端)、跨操作系統(如跨Android和iOS)、跨App以及跨渲染容器。」

而其中移動端的跨平臺技術一直以來都是很火熱的話題，在現在都不看好客戶端技術天花板的背景下，客戶端的未來似乎在逐漸朝著跨平臺方向傾斜。

跨平臺方案的優勢十分明顯，對于開發者而言，可以做到一次開發，多端復用，一套代碼就能夠運行在不同設備上。這在很大程度上能夠降低研發成本，同時能夠在產品效能上做到快速驗證和快速上線。

但是，移動端的跨平臺技術并不是僅僅考慮一套代碼能夠運行在不同場景即可，還需要解決性能、動態性、研發效率以及一致性的問題。

性能： 如何通過前端和客戶端的結合，實現更優的渲染性能以及交互性能;

動態性： 客戶端怎樣能夠實現更低成本的發版、甚至不發版直接動態更新代碼;研發效率：如何提升不同客戶端的動態調試之類的研發效率;

一致性： 如何實現一份代碼的多端部署，并保證代碼在多個客戶端內展示形態的一致性以及兼容性問題。

如今，也已經出現了如WebView、React Native、Weex、Flutter、小程序等眾多的移動端跨平臺框架。但是行業內一致呈現出群雄爭霸的形勢，并沒有哪一種框架可以真正上說能給完美解決以上的問題，同時博眾人之所長，一超多強。

1 WebView

WebView簡單來說就是用來展示HTML的容器，用官方的話講，叫做：

A View that displays web pages. This class is the basis upon which you can roll your own web browser or simply display some online content within your Activity. It uses the WebKit rendering engine to display web pages and includes methods to navigate forward and backward through a history, zoom in and out, perform text searches and more.

來給大家翻譯一下：

用來顯示網頁的視圖。這是用來運行你自己的Web瀏覽器或只再在應用中顯示一些線上內容的基礎。它使用WebKit渲染引擎顯示網頁，并包括在瀏覽歷史中導航，放大和縮小以及執行文本搜索等方法。

所以簡單來說，WebView就像是一個瀏覽器，能夠在里面加載和渲染各種HTML的頁面。而同時，WebView一般繼承于原生客戶端的UI基類。所以，對于原生應用來說，WebView本身通過加載h5頁面、通過Chromium/WebKit內核解析并進行UI合成，生成客戶端原生的UI類，然后上屏展示。

而html頁面與native的溝通交互則是通過所謂的JSB (JavaScript Bridge)來實現的。客戶端將原生系統級的接口進行封裝，然后通過JSB暴露給WebView中前端頁面進行調用。

本質上這就是原生系統API與前端頁面Javascript的通信。這樣一來，前端開發者也可以很快地實現頁面跨端，通過JSB與原生系統進行溝通，保證跨端應用在整體上的能力打通和相互調用。

只不過，這樣的機制劣勢也很明顯，就是前端頁面與原生系統的通信完全取決于JSB的構造，如果JSB中缺少調用原生能力的接口，那跨段能力也會直接受限。這種情況下依舊需要分別擴充原生應用中的JSB接口，反而降低了開發效率。

此外，WebView對UI的渲染依賴于瀏覽器內核，而瀏覽器內核又獨立于系統組件，所以無法保證跨端UI的原生體驗。原生體驗永遠是跨端技術追求的終極目標。

2 React Native

為了追求上面說過的原生體驗的問題，Facebook在2015年則推出了十分火熱的React Native，簡稱RN。

[[400045]]

RN相較于WebView，最大的區別就是不再使用瀏覽器內核進行UI渲染，而是使用一個叫做Virtual DOM的東西來進行跨端UI渲染的管理。

Virtual DOM和DOM實際上差不多，都是一個樹形結構，在不同節點上記錄了UI的不同元素。只不過Virtual DOM將渲染工作是交給了原生渲染引擎，比如web瀏覽器、iOS、Android，去處理。之后，不同平臺依舊是通過對應的Bridge來創建不同的Native視圖。

這樣以來，體驗有一定的提升。只不過React Native和原生交互依賴的只有一個Bridge，而且JS和Native交互是異步的，所以對需要和Native大量實時交互的功能可能會有性能上的不足，比如動畫效率，性能依舊是不如原生的。

3 Flutter

Flutter是谷歌內部孵化的移動端跨平臺UI框架，它是在RN被飽受質疑的時候提出，算是目前最接近原生體驗的框架。

從底層原理上來說，它既沒有采用WebView與H5混編的形式，也沒有采用JavaScript通過Bridge進行橋接的模式，而是自己實現了一套UI框架，直接在更底層進行UI渲染。不僅如此，它也不再采用JavaScript作為開發語言，而是選擇了Dart。稱Dart語言可以編譯成原生代碼，直接跟原生通信。

之所以選擇Dart，其實Flutter團隊在早期就評估了十多種語言，并選擇了Dart，因為覺得它符合他們構建用戶界面的方式，并且還具有以下優勢：

1 Dart是AOT (Ahead Of Time)編譯的，編譯成快速、可預測的本地代碼，使Flutter幾乎都可以使用Dart編寫。

2 Dart也可以JIT(Just In Time)編譯，開發周期異常快，工作流顛覆常規(包括Flutter流行的亞秒級有狀態熱重載);

3 Dart可以更輕松地創建以60fps運行的流暢動畫和轉場。Dart可以在沒有鎖的情況下進行對象分配和垃圾回收。

4 Dart使Flutter不需要單獨的聲明式布局語言，如JSX或XML，或單獨的可視化界面構建器，因為Dart的聲明式編程布局易于閱讀和可視化。

Flutter與上述Recat Native、WebView容器本質上都是不同的，它沒有使用WebView、JavaScript解釋器或者系統平臺自帶的原生控件，而是有一套自己專屬的Widget，所有組件基于Skia引擎自繪。

Flutter由于是通過自己的引擎進行UI渲染，因此在iOS和Android的效果基本一致。相比之下，RN是將UI控件轉換為對應平臺的原生控件，所以不可避免的會存在一定差異。

從技術角度來看，RN實際上就是在Native容器中提供了JavaScript的運行環境，但是其布局引擎，渲染層都采用的是Native的控件，因此UI交互上仍然存在系統差異。而Flutter方案更徹底一些，連渲染層也換成了基于圖形引擎自繪UI控件，從而保證UI交互的跨端一致性。

4 總結

這三樣跨端技術基本上算是行業內比較熱門的技術，也是在很多大型app中都能見到的技術。特別是在app中，與活動相關的頁面，基本上都是通過跨端技術實現的，畢竟活動本身就意味著高度的動態性。

我感覺跨端技術在實踐中的價值主要是在于能夠減少app的發版周期，不需要走周期十分長的封版、發版、灰度以及全量過程。一旦遇到問題或者需要立刻對app的修改，就可以直接通過跨端技術來實現。非常的好用。

只不過從上面看來，很多跨端中存在的問題也并沒有得到真正的解決。不過要是真解決了，大概脈脈里「客三消」的鍵盤俠們又要沸騰了。

不過只要保持持續學習，就啥都不怕。嘿嘿，如果覺得這篇文章不錯的，還請幫忙點贊分享呀～我是安醬，咱們下回見。