跨平臺技術；H5和Flutter誰是未來？

前言

創(chuàng)新互聯(lián)公司，是成都地區(qū)的互聯(lián)網(wǎng)解決方案提供商，用心服務為企業(yè)提供網(wǎng)站建設、成都app軟件開發(fā)、小程序設計、系統(tǒng)定制設計和微信代運營服務。經(jīng)過數(shù)十載的沉淀與積累，沉淀的是技術和服務，讓客戶少走彎路，踏實做事，誠實做人，用情服務，致力做一個負責任、受尊敬的企業(yè)。對客戶負責，就是對自己負責，對企業(yè)負責。

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

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

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

一. H5

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

1.瀏覽器架構

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

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

2.渲染引擎原理

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

分為下面6步驟：

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

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

3.JSBridge原理

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

通信分為以下兩個維度：

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

4.App打開H5過程

打開H5分為4個階段：

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

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

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

優(yōu)點

缺點

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

二.小程序

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

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

1.View

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

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

2. App Service

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

運行環(huán)境：

僅有一個WebView進程

3.View App Service通信

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

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

優(yōu)點

缺點

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

三.React Native

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

Virtual DOM在內存中，可以通過不同的渲染引擎生成不同平臺下的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團隊也在積極準備大版本重構，能否成為開發(fā)者們所信賴的跨平臺方案，讓我們拭目以待。

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

四.Flutter

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

1.Flutter架構原理

2.Dart優(yōu)勢

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

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

優(yōu)點

缺點

Flutter 與 iOS 原生 webView 對比

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

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

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

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

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

在這里，筆者又加了一個測試，嘗試記錄從 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 主站之后，新浪又加載了一個 ，所以導致總時間延長，不過即使按照 UIWebViewB 的數(shù)據(jù)來比較，也是 wkWebView 略勝一籌。

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

結論：

速度（didStart - didFinish） UIWebView flutter_webview WKWebView

速度（viewDidLoad - didFinish）WKWebView UIWebView flutter_webview

這里查看內存使用的是 xcode 的 debug session 中的 memory。

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

接著我們在看一下打開淘寶首頁的內存情況

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

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

結論：內存 WKWebView flutter_webview UIWebView

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

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

結論：兼容性 WKWebView = flutter_webview UIWebView

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

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

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

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

1、常用布局的對比

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

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

2、一些常用屬性設置上的差異：

Margin外邊距

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

Flutter：需嵌套 Container 組件并在內部設置具體的 margin 值

Padding內邊距

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

Flutter：需嵌套 Padding 組件并在內部設置具體的值

組件的可見性

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

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

事件監(jiān)聽

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

Flutter：在需要添加事件監(jiān)聽的組件外層嵌套 InkWell 或 GestureDetector 并設置 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ā)通知之類的

Android原生、ReactNative、Flutter對比

首先從三者不同的設計理念對比，主要有三部分UI顯示流程、狀態(tài)更新機制、編譯流程

Java文件編譯成Class,然后被dex工具編譯成dex最終打包成APK文件,隨后通過adb命令安裝到手機中Java文件發(fā)生変化,上述流程需要重新來一遍,安裝到手機中,才能看到最終效果

為什么除了Flutter之外，我們還需要另一個跨平臺開發(fā)框架？

不久前，谷歌正式推出 Jetpack Compose 1.0 版本。近日，JetBrains 在此基礎上發(fā)布了 Compose Multiplatform Alpha 版本，旨在將 Compose 擴展到桌面和 Web 端。

Compose Multiplatform 由 Compose for Desktop 和 Compose for Web 組成，通過 Kotlin Multiplatform 支持許多不同的平臺。其中，Compose Desktop 采用 Google 的 Skia 圖形庫，來實現(xiàn)在 Windows、macOS 和 Linux 上的 UI 繪制，借此在所有支持的操作系統(tǒng)中提供統(tǒng)一的體驗，類似于 Flutter 的做法。

根據(jù) Kotlin 團隊的說法，相比起 Electron 框架，Compose Multiplatform 在內存消耗、安裝大小和 UI 渲染性能等方面將有更明顯的優(yōu)勢。隨著 Alpha 版本的發(fā)布，Compose Multiplatform 還收獲了新的 Android Studio 插件，包括對在 IDE 中顯示組件預覽的支持以及許多附加功能。

我們希望通過本文幫助大家進一步了解 Compose 的跨平臺能力，以及 JetBrains 將 Compose 從 Android 擴展到這些其他平臺背后的主要驅動力是什么。

基于 Jetpack Compose 1.0

由谷歌打造的 Jetpack Compose 是一款用于在 Android 應用程序之內構建用戶界面的官方框架，上周剛剛發(fā)布 1.0 版本。與此同時，Android Studio 代號“極狐”的首個穩(wěn)定版 2020.3.1 也正式亮相。

盡管才剛迎來 1.0，但谷歌表示“目前 Play Store 中已經(jīng)有超過 2000 款應用程序在使用 Compose——更重要的是，就連 Play Store 這款應用本身也在使用 Compose。”谷歌方面還表示，“我們一直在與一些頂級應用的開發(fā)人員進行合作，他們的反饋和支持幫助我們使 1.0 版本更加強大。”

Jetpack Compose for Android 迎來 1.0 版本

Compose 基于 Kotlin 開發(fā)，而 Kotlin 與 Android Studio（即官方指定的 Android IDE）均來自開發(fā)工具廠商 JetBrains。雖然 Jetpack Compose 專為 Android 打造（與谷歌的 Flutter 框架不同）， 但 JetBrains 公司堅信 Compose 完全能夠獲得跨平臺能力 。

Compose for Desktop: 這只是開始

Compose Multiplatform 可以說是該框架面向 MacOS、Linux、Windows 以及 Web 開設的一個端口，目前剛剛發(fā)布 1.0 Alpha 版本。雖然尚處于早期開發(fā)階段，但 JetBrains 表示，其已經(jīng)“為開發(fā)人員帶來能夠基本安全使用的穩(wěn)定 API”。

TheRegister 就此事詢問了 JetBrains 公司 Compose 項目負責人 Nikolay Igotti，希望了解為什么該公司在擁有了已經(jīng)廣泛應用于 IntelliJ IDEA IDE 及多種豐富變體的桌面應用程序跨平臺 Java 框架之外，還要費力開發(fā) Compose for Desktop。Igotti 的回答是，“舊有 Java 框架基本上就是修改版的 Swing。Swing 屬于默認 JDK UI 框架，Swing 和 AWT（Abstract Windows Toolkit，抽象窗口工具包）。Compose 則完全是另一碼事，當然我們也在設計中考慮到了互操作性需求……Swing 這套框架太陳舊了，最早出現(xiàn)在上世紀九十年代末。多年來人們對于 UI 的設計思路已經(jīng)天翻地覆，Swing 顯然滿足不了要求了。”

JetBrains IDE 中的 Compose for Desktop 項目

Compose 與 Swing 有一個比較大的共同點：與其他使用本機控件的跨平臺框架，比如例如 Java 的 SWT（Standard Widget Toolkit）以及微軟的 Xamarin 有所不同，它們選擇自主繪制控件。Compose 使用的 Skia 開源圖形庫，也在谷歌 Chrome、Flutter 及其他眾多框架當中得到廣泛應用。那這是否意味著 Compose 應用程序將沒有自己的原生外觀？對此，Igotti 的回應是，“這取決于開發(fā)人員的選擇，取決于他們如何為應用程序設置主題。在這方面，Compose 的情況與 Flutter 等其他框架沒什么區(qū)別。”

那 Compose for Desktop 應用程序是否依賴于 JVM（Java Virtual Machine）運行？Igotti 表示，“我們也知道，JVM 應用程序的發(fā)布情況可能比較棘手。因此我們提供自己的 Gradle 插件，其使用 jpackage 與 Jlink 以 JVM 應用程序為基礎制作原生應用程序。Mac 的.dmg、Windows 的 MSI、Linux 的 deb 包等均可實現(xiàn)，大家用不著擔心 JVM。”

也就是說，開發(fā)成果將會是一款被精心包裹起來的 JVM 應用程序。JetBrains 還有一款用于解決這個問題的 Kotlin/Native 編譯器，“預計將在未來發(fā)布，或者專門用于桌面開發(fā)。”

對應用程序的另一種思考方式

那 Web 應用程序方面呢？Igotti 回應稱，“我們使用 Kotlin/JS 編譯器。”Compose 的 Web 版本不如桌面版先進，說明文檔中也警告稱“API 尚未最終確定，預計會發(fā)生重大變化。”此外，雖然 Web 版本確實使用 Compose 模型，但 API 卻完全不同，而且會使用 HTML 與 CSS。所以，Web 版與 Compose for Desktop 之間能夠共享的代碼應該比較少。

據(jù) Igotti 介紹，“Compose 代表著一種不同的應用程序思考方式。狀態(tài)即 UI 的真實來源，而 UI 本身是無狀態(tài)的，其表達永遠由狀態(tài)計算得出。在這方面，Compose for Web 采用一組相同的原語，完全相同的狀態(tài)管理思路。但是對于具體的小部件集合與排列方式，Web 版與桌面版之間確實無法互通。”

說到這里，為什么要把 Compose for Android 擴展到多種其他平臺之上？“Compose 的目標受眾主要分為三類。首先是使用 Kotlin 與 Compose 的 Android 開發(fā)人員，他們希望把自己的開發(fā)成果交付至其他平臺；其二是純 Kotlin 開發(fā)人員，他們希望以‘一次編寫、隨處運行’的方式開發(fā)新的應用程序；第三則是那些不太熟悉 Kotlin 或者 Compose，但又希望開發(fā)出精美 UI 的用戶，我們希望能為他們提供實現(xiàn)目標的工具。”

Igotti 并沒有給出具體的發(fā)布日期，但表示自己希望 Beta 版能在今年秋天發(fā)布，“我們也希望能在今年之內推出 1.0 版本。”項目本身是完全開源的，“二十一世紀了，框架在大多數(shù)人們心目中就不應該收費。我們只是想開發(fā)一款長期缺失的軟件”，補足 JetBrains 當前商業(yè)模式中的工具鏈。

那么，JetBrains 會在自己的其他工具中使用 Compose 嗎？事實上，他們的 JetBrains Toolbox（用于管理已安裝的 IDE）已經(jīng)在使用 Compose，但 Igotti 表示短時間內 Compose 還無法取代 IntelliJ IDEA 等現(xiàn)有框架。“編輯器是其中最復雜也最重要的組件，經(jīng)歷了 20 年的發(fā)展演進，我們幾乎不可能在中途進行重寫了。無論是 JetBrains 還是我個人，都不打算強迫每個人都轉而使用 Compose。我們的目標是為原有框架選項滿足不了的用戶提供新的解決方案。”

寫在最后

那么，為什么除了 Flutter 之外，我們還需要另一個跨平臺框架？雖然谷歌的 Flutter 最開始主要面向移動設備，但現(xiàn)在也開始向桌面及 iOS 進軍，甚至比 Compose 還搶先了一步。不過，根據(jù) StackOverflow 的最新調查， Flutter 使用的語言為 Dart；盡管 Dart 語言的人氣正在增長（正是受到 Flutter 的推動），但仍然無法與 Kotlin 相提并論。

Compose 代表著一種獨特的 UI 構建方法，也許最期待 Compose 跨平臺功能的受眾，正是那些曾在 Android 上使用過它、又特別喜歡這種 UI 構建體驗的開發(fā)者。

想要進一步了解 Compose，國內 Android 開發(fā)者可訪問以下鏈接查看中文手冊：

延伸閱讀：

做混合的話Uniapp和Flutter我應該學哪個啊？

Uniapp目前比較成熟，而且用的是Vue語法，學習成本比較低，而且行業(yè)里面用的也比較廣泛，而Flutter的話，學習成本略高，因為要學習新的語言，還有就是目前生態(tài)不是特別完備，等他再發(fā)展發(fā)展吧。黑馬程序員官網(wǎng)有成套免費視頻哦，有什么不懂的可以直接過去學習。您的采納是對我成長的鞭策

當前標題：比flutter,比flutter更好
標題來源：http://chinadenli.net/article17/dsegcgj.html

成都網(wǎng)站建設公司_創(chuàng)新互聯(lián)，為您提供定制開發(fā)、關鍵詞優(yōu)化、ChatGPT、電子商務、網(wǎng)站收錄、服務器托管

廣告

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