Flutter 與 iOS 原生 webView 對比

本文對比的是 UIWebView、WKWebView、flutter_webview_plugin（在iOS中使用的是WKWebView）的加載速度，內(nèi)存使用情況。

創(chuàng)新互聯(lián)專業(yè)為企業(yè)提供阿勒泰網(wǎng)站建設(shè)、阿勒泰做網(wǎng)站、阿勒泰網(wǎng)站設(shè)計、阿勒泰網(wǎng)站制作等企業(yè)網(wǎng)站建設(shè)、網(wǎng)頁設(shè)計與制作、阿勒泰企業(yè)網(wǎng)站模板建站服務(wù)，10年阿勒泰做網(wǎng)站經(jīng)驗，不只是建網(wǎng)站，更提供有價值的思路和整體網(wǎng)絡(luò)服務(wù)。

測試網(wǎng)頁打開的速度，只需要獲取 WebView 在開始加載網(wǎng)頁和網(wǎng)頁加載完成時的時間戳，時間戳的差即為打開網(wǎng)頁的時間

為了使差異更明顯，我們選擇較為復(fù)雜的 新浪首頁 進行加載的對比，為了減小網(wǎng)絡(luò)對加載速度的影響，我們讓手機連接同一個網(wǎng)絡(luò)，分別進行 10 次測試然后取平均值，另外，我們需要關(guān)閉 WebView 的緩存，防止緩存對加載速度產(chǎn)生影響

下面使筆者進行 10 次測試所得到的數(shù)據(jù)

結(jié)果讓我有點驚訝，一直以為 WKWebView 會是個王者。結(jié)果看，速度上 WKWebView 略慢一點，不過總體差異不大（該結(jié)果僅僅是測試新浪的結(jié)果，僅供參考啦）

在這里，筆者又加了一個測試，嘗試記錄從 viewController 的 viewDidLoad 到 webview 的 didFinish 時間，測試了新浪的數(shù)據(jù)，如下：

UIWebViewA ： 4970、3808、3815、4250、3556 avg(4079.8) （加載完所有頁面）

UIWebViewB ： 4103、3124、3070、3256、2835 avg(3277.6)（加載sina完畢）

WKWebView ： 3672、3032、2892、2912、2739 avg(3049.4)

flutter_webView ： 4532、3901、4310、3496、3378 avg(3923.4)

其中可以看到，webView 有兩行，UIWebViewB 的數(shù)據(jù)就是加載 sina 主站的時間；UIWebViewA 的數(shù)據(jù)是因為在加載完 sina 主站之后，新浪又加載了一個 ，所以導(dǎo)致總時間延長，不過即使按照 UIWebViewB 的數(shù)據(jù)來比較，也是 wkWebView 略勝一籌。

此處可以看出 flutter_webView 使用的是 wkwebView，所以它吃虧的主要原因是 flutter 包了一層。

結(jié)論：

速度（didStart - didFinish） UIWebView flutter_webview WKWebView

速度（viewDidLoad - didFinish）WKWebView UIWebView flutter_webview

這里查看內(nèi)存使用的是 xcode 的 debug session 中的 memory。

首先看之前測試時，連續(xù)打開十次新浪的內(nèi)存情況

接著我們在看一下打開淘寶首頁的內(nèi)存情況

從圖上可以看出，WKWebView 在內(nèi)存方面有很大的優(yōu)勢啊，UIWebView 的內(nèi)存是真的傷啊，然后 debug 看了一下 flutter_webView，他使用的就是原生的 webView 。

他相比較原生 WKWebView 的內(nèi)存開銷稍大一點，從測試表現(xiàn)來看，一般大個 30 MB 左右。

結(jié)論：內(nèi)存 WKWebView flutter_webview UIWebView

可以在 html5test 中對瀏覽器的兼容性進行評分，通過測試發(fā)現(xiàn)得分分別如下

因為 flutter 里使用的就是 WK，所以和原生的 WKWebView 一樣都是 444 分，比 UIWebView 的 437 略勝一籌

結(jié)論：兼容性 WKWebView = flutter_webview UIWebView

UIWebView : 速度相比較 WKWebView 稍快一點，但是內(nèi)存是一大硬傷，所以只要條件允許，就不推薦使用了

WKWebView : 速度略慢一點，不過差別不大，總體可以接受。是比UIWebView更好的選擇，推薦使用。

flutter_webView_plugin ：在iOS中使用的就是原生的WKWebView，所以總體和 native WKWebView 表現(xiàn)差不多。如果是混編項目中，因為它被包了一層，所以頁面加載上存在一定的劣勢，所以混編項目中仍然推薦使用 WKWebView。不過如果從多端考慮、以及項目可遷移等，那么使用也未嘗不可，就是維護成本要增加一些，需要維護兩套 webView。這個就需要根據(jù)自己的情況自己取舍了。

Android原生和Flutter使用過程的差異對比（二）

1、常用布局的對比

使用下來其他組件大致還算方便，但是相對布局而言使用便利程度上Android原生完勝，ConstraintLayout內(nèi)部的所有子View可以設(shè)置互相之間的位置依賴關(guān)系。

而Flutter的Stack組件內(nèi)部的Children只能通過外層包裹 Align后 固定位置，比如 Alignment.topLeft、Alignment.bottomRight 等。遇到復(fù)雜的堆疊布局需要通過外層包裹 Positioned 組件后設(shè)置固定的 top 和 left 距離以達到效果，內(nèi)部子組件之間無法設(shè)置位置關(guān)聯(lián)關(guān)系。

2、一些常用屬性設(shè)置上的差異：

Margin外邊距

Android：直接在布局文件對View設(shè)置android:layout_marginStart、android:layout_marginTop

Flutter：需嵌套 Container 組件并在內(nèi)部設(shè)置具體的 margin 值

Padding內(nèi)邊距

Android：TextView、ImageView、各種Layout都可以直接在屬性上設(shè)置android:paddingStart

Flutter：需嵌套 Padding 組件并在內(nèi)部設(shè)置具體的值

組件的可見性

Android：每個view都可以通過setVisibility來設(shè)置可見、隱藏或者隱藏但占位

Flutter：沒有單獨設(shè)置組件是否顯示的api，只能通過 bool 值控制是否添加該組件

事件監(jiān)聽

Android：常規(guī)的setOnClickListener和setOnLongClickListener設(shè)置單擊和長按事件

Flutter：在需要添加事件監(jiān)聽的組件外層嵌套 InkWell 或 GestureDetector 并設(shè)置 onTap 等

3、生命周期

Android：

Activity和Fragment各自有完整的生命周期鏈路onCreate、onStart、onResume、onPause、onDestroy等

Flutter：

萬物皆組件，組件繼承 WidgetsBindingObserver 并重寫 didChangeAppLifecycleState 函數(shù)進行監(jiān)聽

退回桌面依次執(zhí)行inactive 》= paused，此時界面不可見用戶不可操作，從桌面重新進入app執(zhí)行resumed，狀態(tài)較少如需在某些條件下觸發(fā)特定操作可能要找別的方案，比如發(fā)通知之類的

咸魚flutter換成h5了嗎

沒有。

咸魚flutter沒有換成h5，咸魚不僅有flutter的開發(fā)應(yīng)用，還包括h5的開發(fā)應(yīng)用，flutterflutter更偏向客戶端的研發(fā)體系，h5性能穩(wěn)定，因為二者有不同的優(yōu)勢，所以咸魚flutter沒有換成h5，而是兩者共用。

咸魚flutter是一個全新的移動UI框架，它允許使用同一個代碼庫構(gòu)建高性能的Android和iOS應(yīng)用，在此基礎(chǔ)之上，以h5為數(shù)據(jù)分析的系統(tǒng)，進行大數(shù)據(jù)分析，從而二者共同促進咸魚的使用率。

flutter_inappbrowser和h5交互

需求，app中使用webview和h5交互，根據(jù)h5發(fā)過來的消息，在屏幕上展示flutter組件，并且可以發(fā)送消息給h5。

首先使用的組件是flutter_WebView_plugin，這個組件不能嵌套flutter組件,所以放棄這個組件。

flutter_inappbrowser 可以實現(xiàn)組合布局, 所以選用了此庫, GitHub鏈接

[

跨平臺技術(shù)；H5和Flutter誰是未來？

前言

為什么跨平臺是發(fā)展趨勢？

同一個應(yīng)用，各個“端”獨立開發(fā)，不僅開發(fā)周期長，而且人員成本高。同時，作為技術(shù)人員，也不應(yīng)該滿足于這種重復(fù)、低能的工作狀態(tài)。在這樣的形勢下，跨平臺的技術(shù)方案也受到越來越多人和企業(yè)的關(guān)注。

本篇文章我將從原理、優(yōu)缺點等方面為大家分享跨平臺技術(shù)

一. H5

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

1.瀏覽器架構(gòu)

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

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

2.渲染引擎原理

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

分為下面6步驟：

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

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

3.JSBridge原理

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

通信分為以下兩個維度：

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

4.App打開H5過程

打開H5分為4個階段：

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

5.優(yōu)缺點分析

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

優(yōu)點

缺點

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

二.小程序

2018年是微信小程序飛速發(fā)展的一年，19年，各大廠商快速跟進，已經(jīng)有了很大的影響力。下面，我們以微信小程序為例，分析小程序的技術(shù)架構(gòu)。

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

1.View

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

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

2. App Service

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

運行環(huán)境：

僅有一個WebView進程

3.View App Service通信

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

4. 優(yōu)缺點分析

優(yōu)點

缺點

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

三.React Native

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

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

1.React Native 工作原理

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

2.React Native 與Native平臺通信

3.優(yōu)缺點分析

優(yōu)點

缺點

4.RN展望

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

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

四.Flutter

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

1.Flutter架構(gòu)原理

2.Dart優(yōu)勢

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

3.優(yōu)缺點分析

優(yōu)點

缺點

新聞名稱：原生h5和flutter,原生跟h5的區(qū)別
文章位置：http://chinadenli.net/article35/dsehopi.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供網(wǎng)頁設(shè)計公司、品牌網(wǎng)站制作、面包屑導(dǎo)航、網(wǎng)站建設(shè)、營銷型網(wǎng)站建設(shè)、用戶體驗

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時需注明來源： 創(chuàng)新互聯(lián)