[[400044]]

本文轉(zhuǎn)載自微信公眾號「業(yè)余碼農(nóng)」，作者Amazing10。轉(zhuǎn)載本文請聯(lián)系業(yè)余碼農(nóng)公眾號。

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

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

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

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

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

性能： 如何通過前端和客戶端的結(jié)合，實(shí)現(xiàn)更優(yōu)的渲染性能以及交互性能;

動態(tài)性： 客戶端怎樣能夠?qū)崿F(xiàn)更低成本的發(fā)版、甚至不發(fā)版直接動態(tài)更新代碼;研發(fā)效率：如何提升不同客戶端的動態(tài)調(diào)試之類的研發(fā)效率;

一致性： 如何實(shí)現(xiàn)一份代碼的多端部署，并保證代碼在多個(gè)客戶端內(nèi)展示形態(tài)的一致性以及兼容性問題。

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

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.

來給大家翻譯一下：

用來顯示網(wǎng)頁的視圖。這是用來運(yùn)行你自己的Web瀏覽器或只再在應(yīng)用中顯示一些線上內(nèi)容的基礎(chǔ)。它使用WebKit渲染引擎顯示網(wǎng)頁，并包括在瀏覽歷史中導(dǎo)航，放大和縮小以及執(zhí)行文本搜索等方法。

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

而html頁面與native的溝通交互則是通過所謂的JSB (JavaScript Bridge)來實(shí)現(xiàn)的?？蛻舳藢⒃到y(tǒng)級的接口進(jìn)行封裝，然后通過JSB暴露給WebView中前端頁面進(jìn)行調(diào)用。

本質(zhì)上這就是原生系統(tǒng)API與前端頁面Javascript的通信。這樣一來，前端開發(fā)者也可以很快地實(shí)現(xiàn)頁面跨端，通過JSB與原生系統(tǒng)進(jìn)行溝通，保證跨端應(yīng)用在整體上的能力打通和相互調(diào)用。

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

此外，WebView對UI的渲染依賴于瀏覽器內(nèi)核，而瀏覽器內(nèi)核又獨(dú)立于系統(tǒng)組件，所以無法保證跨端UI的原生體驗(yàn)。原生體驗(yàn)永遠(yuǎn)是跨端技術(shù)追求的終極目標(biāo)。

2 React Native

為了追求上面說過的原生體驗(yàn)的問題，F(xiàn)acebook在2015年則推出了十分火熱的React Native，簡稱RN。

[[400045]]

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

Virtual DOM和DOM實(shí)際上差不多，都是一個(gè)樹形結(jié)構(gòu)，在不同節(jié)點(diǎn)上記錄了UI的不同元素。只不過Virtual DOM將渲染工作是交給了原生渲染引擎，比如web瀏覽器、iOS、Android，去處理。之后，不同平臺依舊是通過對應(yīng)的Bridge來創(chuàng)建不同的Native視圖。

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

3 Flutter

Flutter是谷歌內(nèi)部孵化的移動端跨平臺UI框架，它是在RN被飽受質(zhì)疑的時(shí)候提出，算是目前最接近原生體驗(yàn)的框架。

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

之所以選擇Dart，其實(shí)Flutter團(tuán)隊(duì)在早期就評估了十多種語言，并選擇了Dart，因?yàn)橛X得它符合他們構(gòu)建用戶界面的方式，并且還具有以下優(yōu)勢：

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

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

3 Dart可以更輕松地創(chuàng)建以60fps運(yùn)行的流暢動畫和轉(zhuǎn)場。Dart可以在沒有鎖的情況下進(jìn)行對象分配和垃圾回收。

4 Dart使Flutter不需要單獨(dú)的聲明式布局語言，如JSX或XML，或單獨(dú)的可視化界面構(gòu)建器，因?yàn)镈art的聲明式編程布局易于閱讀和可視化。

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

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

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

4 總結(jié)

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

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

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

不過只要保持持續(xù)學(xué)習(xí)，就啥都不怕。嘿嘿，如果覺得這篇文章不錯(cuò)的，還請幫忙點(diǎn)贊分享呀～我是安醬，咱們下回見。