前言
公司主營(yíng)業(yè)務(wù)：成都網(wǎng)站設(shè)計(jì)、成都網(wǎng)站建設(shè)、移動(dòng)網(wǎng)站開(kāi)發(fā)等業(yè)務(wù)。幫助企業(yè)客戶(hù)真正實(shí)現(xiàn)互聯(lián)網(wǎng)宣傳，提高企業(yè)的競(jìng)爭(zhēng)能力。成都創(chuàng)新互聯(lián)是一支青春激揚(yáng)、勤奮敬業(yè)、活力青春激揚(yáng)、勤奮敬業(yè)、活力澎湃、和諧高效的團(tuán)隊(duì)。公司秉承以“開(kāi)放、自由、嚴(yán)謹(jǐn)、自律”為核心的企業(yè)文化，感謝他們對(duì)我們的高要求，感謝他們從不同領(lǐng)域給我們帶來(lái)的挑戰(zhàn)，讓我們激情的團(tuán)隊(duì)有機(jī)會(huì)用頭腦與智慧不斷的給客戶(hù)帶來(lái)驚喜。成都創(chuàng)新互聯(lián)推出突泉免費(fèi)做網(wǎng)站回饋大家。
為什么跨平臺(tái)是發(fā)展趨勢(shì)？
同一個(gè)應(yīng)用，各個(gè)“端”獨(dú)立開(kāi)發(fā)，不僅開(kāi)發(fā)周期長(zhǎng)，而且人員成本高。同時(shí)，作為技術(shù)人員，也不應(yīng)該滿(mǎn)足于這種重復(fù)、低能的工作狀態(tài)。在這樣的形勢(shì)下，跨平臺(tái)的技術(shù)方案也受到越來(lái)越多人和企業(yè)的關(guān)注。
本篇文章我將從原理、優(yōu)缺點(diǎn)等方面為大家分享跨平臺(tái)技術(shù)
一. H5
說(shuō)到跨平臺(tái)，沒(méi)人不知道H5。不管是在Mac、Windows、Linux、iOS、Android還是其他平臺(tái)，只要給一個(gè)瀏覽器，連“月球”上它都能跑。
1.瀏覽器架構(gòu)
下面，我們來(lái)看看讓H5如此橫行霸道的瀏覽器的架構(gòu)：
瀏覽器由以上7個(gè)部分組成，而“渲染引擎”是性能優(yōu)化的重中之重，一起了解其中的渲染原理。
2.渲染引擎原理
不同的瀏覽器內(nèi)核不同，渲染過(guò)程會(huì)不太一樣，但主要流程還是一致的。
分為下面6步驟：
從以上6步，我們可以總結(jié)渲染優(yōu)化的要點(diǎn)：
以上就是瀏覽器端的內(nèi)容。但H5作為跨平臺(tái)技術(shù)的載體，是如何與不同平臺(tái)的App進(jìn)行交互的呢？這時(shí)候JSBridge就該出場(chǎng)了。
3.JSBridge原理
JSBridge，顧名思義，是JS和Native之間的橋梁，用來(lái)進(jìn)行JS和Native之間的通信。
通信分為以下兩個(gè)維度：
那么App內(nèi)加載H5的過(guò)程是什么樣的呢？
4.App打開(kāi)H5過(guò)程
打開(kāi)H5分為4個(gè)階段：
這四步，對(duì)應(yīng)的過(guò)程如上圖所以，我們可以針對(duì)性的做性能優(yōu)化。
5.優(yōu)缺點(diǎn)分析
下面，我們進(jìn)行H5的優(yōu)缺點(diǎn)分析：
優(yōu)點(diǎn)
缺點(diǎn)
雖然H5目前還存在不足，但隨著PWA、WebAssembly等技術(shù)的進(jìn)步，相信H5在未來(lái)能夠得到越來(lái)也好的發(fā)展。
二.小程序
2018年是微信小程序飛速發(fā)展的一年，19年，各大廠商快速跟進(jìn)，已經(jīng)有了很大的影響力。下面，我們以微信小程序?yàn)槔?，分析小程序的技術(shù)架構(gòu)。
小程序跟H5一樣，也是基于Webview實(shí)現(xiàn)。但它包含View視圖層、App Service邏輯層兩部分，分別獨(dú)立運(yùn)行在各自的WebView線程中。
1.View
可以理解為h5的頁(yè)面，提供UI渲染。由WAWebview.js來(lái)提供底層的功能,具體如下：
每個(gè)窗口都有一個(gè)獨(dú)立的WebView進(jìn)程，因此微信限制不能打開(kāi)超過(guò)5個(gè)層級(jí)的頁(yè)面來(lái)保障用戶(hù)體驗(yàn)。
2. App Service
提供邏輯處理、數(shù)據(jù)請(qǐng)求、接口調(diào)用。由WAService.js來(lái)提供底層的功能,具體如下：
運(yùn)行環(huán)境：
僅有一個(gè)WebView進(jìn)程
3.View App Service通信
視圖層和邏輯層通過(guò)系統(tǒng)層的JSBridage進(jìn)行通信，邏輯層把數(shù)據(jù)變化通知到視圖層，觸發(fā)視圖層頁(yè)面更新，視圖層將觸發(fā)的事件通知到邏輯層進(jìn)行業(yè)務(wù)處理。
4. 優(yōu)缺點(diǎn)分析
優(yōu)點(diǎn)
缺點(diǎn)
既然WebView性能不佳，那有沒(méi)有更好的方案呢？下面我們看看React Native。
三.React Native
RN的理念是在不同平臺(tái)上編寫(xiě)基于React的代碼，實(shí)現(xiàn)Learn once, write anywhere。
Virtual DOM在內(nèi)存中，可以通過(guò)不同的渲染引擎生成不同平臺(tái)下的UI，JS和Native之間通過(guò)Bridge通信
1.React Native 工作原理
在 React 框架中，JSX 源碼通過(guò) React 框架最終渲染到了瀏覽器的真實(shí) DOM 中，而在 React Native 框架中，JSX 源碼通過(guò) React Native 框架編譯后，與Native原生的UI組件進(jìn)行映射，用原生代替DOM元素來(lái)渲染，在UI渲染上非常接近Native App。
2.React Native 與Native平臺(tái)通信
3.優(yōu)缺點(diǎn)分析
優(yōu)點(diǎn)
缺點(diǎn)
4.RN展望
雖然RN還存在不足，但RN新版本已經(jīng)做了如下改進(jìn)，并且RN團(tuán)隊(duì)也在積極準(zhǔn)備大版本重構(gòu)，能否成為開(kāi)發(fā)者們所信賴(lài)的跨平臺(tái)方案，讓我們拭目以待。
既然React Native在渲染方面還擺脫不了原生，那有沒(méi)有一種方案是直接操控GPU，自制引擎渲染呢，我們終于迎來(lái)了Flutter！
四.Flutter
Flutter是Google開(kāi)發(fā)的一套全新的跨平臺(tái)、開(kāi)源UI框架，支持iOS、Android系統(tǒng)開(kāi)發(fā)，并且是未來(lái)新操作系統(tǒng)Fuchsia的默認(rèn)開(kāi)發(fā)套件。渲染引擎依靠跨平臺(tái)的Skia圖形庫(kù)來(lái)實(shí)現(xiàn)，依賴(lài)系統(tǒng)的只有圖形繪制相關(guān)的接口，可以在最大程度上保證不同平臺(tái)、不同設(shè)備的體驗(yàn)一致性，邏輯處理使用支持AOT的Dart語(yǔ)言，執(zhí)行效率也比JavaScript高得多。
1.Flutter架構(gòu)原理
2.Dart優(yōu)勢(shì)
很多人會(huì)好奇，為什么Flutter要用Dart，而不是用JavaScript開(kāi)發(fā)，這里列下Dart的優(yōu)勢(shì)
3.優(yōu)缺點(diǎn)分析
優(yōu)點(diǎn)
缺點(diǎn)
本文面向 Flutter 初學(xué)者，旨在用易懂的方式帶大家入門(mén)。除了 Flutter 代碼，還會(huì)介紹到語(yǔ)法、原理、特性等基礎(chǔ)知識(shí)。相信本文能幫助你學(xué)習(xí)和理解 Flutter。
我們先看一下目前的一些跨平臺(tái)方案，從前端渲染的角度來(lái)分類(lèi)的話，大致可以分為以下幾種方案。
WebView 渲染
這種方案就很好理解，現(xiàn)在很多項(xiàng)目都會(huì)嵌入 H5 的頁(yè)面。就是用 JavaScript 等前端技術(shù)進(jìn)行開(kāi)發(fā)，在客戶(hù)端上用 WebView 來(lái)進(jìn)行渲染。微信小程序目前使用的就是這種方案。
它的優(yōu)點(diǎn)很明顯，使用成熟的前端技術(shù)進(jìn)行開(kāi)發(fā)，學(xué)習(xí)成本低，開(kāi)發(fā)效率高，并且支持動(dòng)態(tài)發(fā)布代碼。
但缺點(diǎn)也很明顯，在性能體驗(yàn)上，和原生還是存在較大差距的。
原生控件渲染
既然 WebView 的性能不夠好，于是就有了使用原生控件進(jìn)行渲染的方案。這種方案，同樣也是使用 JavaScript 開(kāi)發(fā)，區(qū)別是它最終是調(diào)用原生控件進(jìn)行渲染的。這種方案的代表是 Facebook 的 React Native。
由于使用原生控件進(jìn)行渲染，性能體驗(yàn)也會(huì)更接近原生。但也只是更接近，和原生還是有差距的，因?yàn)樗枰l繁的進(jìn)行 JavaScript 和原生之間的通信，這個(gè)通信效率是比較低的。
另外，由于需要適配各個(gè)平臺(tái)的控件，那就有可能出現(xiàn)，系統(tǒng)控件更新了，而框架本身還沒(méi)有更新，由此產(chǎn)生了一些問(wèn)題。換句話說(shuō)，這種方案是受到原生控件限制的。
繪圖引擎渲染
接下來(lái)就是主角了。
在前端，如果完全不使用原生控件，我們可以通過(guò)系統(tǒng)的繪圖 API 繪制出一個(gè)用戶(hù)界面。從這個(gè)角度出發(fā)，可以在各個(gè)平臺(tái)使用一個(gè)統(tǒng)一接口的繪圖引擎來(lái)進(jìn)行界面繪制，這個(gè)引擎最終調(diào)用的是系統(tǒng)的 API 繪制的。這樣的話，它的性能可以做到接近原生，并且又不受原生控件的限制，在不同平臺(tái)上能夠做到 UI 統(tǒng)一。
Flutter 就是這樣的一個(gè)開(kāi)發(fā)框架。
一個(gè)跨平臺(tái) UI 解決方案
Flutter 是由 Google 開(kāi)發(fā)的，一個(gè)跨平臺(tái) UI 解決方案。換句話說(shuō)，它原則上只管 UI 的問(wèn)題，如果涉及到平臺(tái)本身的一些功能，比如調(diào)用藍(lán)牙、攝像頭，一般還是需要原生代碼去操作。但現(xiàn)在也會(huì)有一些第三方庫(kù)幫我們解決這些問(wèn)題。
繪圖引擎 Skia
Flutter 使用 Skia 作為它的繪圖引擎。Skia 已經(jīng)被 Google 收購(gòu)，目前很多 Google 旗下的產(chǎn)品都是用 Skia 繪制的，包括 Android。
Android 內(nèi)置了 Skia，但 iOS 沒(méi)有，所以在打 iOS 安裝包的時(shí)候，會(huì)把 Skia 一起打進(jìn)去。這就導(dǎo)致了，用同一份 Flutter 代碼打包之后，iOS 的包要比 Android 的包大一些。
開(kāi)發(fā)語(yǔ)言 Dart
Flutter 使用的開(kāi)發(fā)語(yǔ)言，叫 Dart。Dart 也是 Google 自家的，它是一門(mén)面向?qū)ο蟮恼Z(yǔ)言，從它身上會(huì)看到一些其他開(kāi)發(fā)語(yǔ)言的影子。學(xué)習(xí)起來(lái)難度不大的。
前面講跨平臺(tái)方案的時(shí)候，可以發(fā)現(xiàn)別的方案基本都是用 JavaScript 作為開(kāi)發(fā)語(yǔ)言的，但為什么 Flutter 不用？就因?yàn)?Dart 是谷歌自家的嗎？這個(gè)問(wèn)題先留著，我們后面會(huì)提到。
這里部分就簡(jiǎn)單點(diǎn)帶過(guò)了，具體的搭建流程可以在官網(wǎng)查看:
主要的搭建步驟如下:
下載 Flutter SDK
官網(wǎng)下載地址：
由于在國(guó)內(nèi)訪問(wèn)可能受限，官方為中國(guó)開(kāi)發(fā)者搭建了鏡像：
更新環(huán)境變量
解壓后，將 flutter\bin 的全路徑添加到環(huán)境變量 PATH 中。
安裝開(kāi)發(fā)工具
理論上，任何文本編輯器都可以用來(lái)開(kāi)發(fā) Flutter 應(yīng)用，但推薦的開(kāi)發(fā)工具是 Android Studio、IntelliJ 以及 VS Code。因?yàn)樵谶@些開(kāi)發(fā)工具上，可以安裝官方的 Flutter 和 Dart 插件，得到更好的開(kāi)發(fā)體驗(yàn)。文章里使用 Android Studio 來(lái)演示。
如果你打算開(kāi)發(fā) iOS 應(yīng)用，則還需要安裝 Xcode。
安裝插件
在開(kāi)發(fā)工具的插件設(shè)置中，安裝上面說(shuō)到的 Flutter 和 Dart 插件。Flutter 插件用于支持 Flutter 的運(yùn)行、調(diào)試、熱重載等功能，而 Dart 插件則提供了代碼的輸入校驗(yàn)、代碼補(bǔ)全等功能。
萬(wàn)物始于 Hello World，我們先來(lái)創(chuàng)建一個(gè)顯示 Hello World 的 Flutter 項(xiàng)目。
在 Android Studio 的歡迎頁(yè)面選擇 Start a new Flutter project ，或者通過(guò)菜單欄的 File New New Flutter Project ，創(chuàng)建一個(gè)新的 Flutter 項(xiàng)目。
創(chuàng)建好的項(xiàng)目里面包含了 android 和 ios 兩個(gè)文件夾，它們是標(biāo)準(zhǔn)的 Android 和 iOS 項(xiàng)目。我們的 Flutter 代碼，存放在 lib 文件夾里。項(xiàng)目創(chuàng)建好后，會(huì)默認(rèn)帶一個(gè)計(jì)數(shù)器的示例，我們不管它，把 main.dart 的代碼改成 Hello World:
啟動(dòng)一個(gè)模擬器，或者連上真機(jī)，點(diǎn)擊 Run 運(yùn)行一下，就能看這樣一個(gè)界面了：
具體代碼先混個(gè)眼熟就好，具體的后面會(huì)再講到。
在寫(xiě) Flutter 之前，還要先跟大家簡(jiǎn)單介紹一下 Dart 的語(yǔ)法。如果你有 Java 或 JavaScript 的開(kāi)發(fā)經(jīng)驗(yàn)，以及面向?qū)ο蟮木幊趟枷?，學(xué)起來(lái)是很快的。
我們可以在 test 文件夾下新建一個(gè) dart 文件，用來(lái)寫(xiě)測(cè)試代碼。
指定類(lèi)型
var
但和 JavaScript 不同的是，以下代碼在 JavaScript 是不會(huì)報(bào)錯(cuò)的，但在 Dart 里會(huì)報(bào)錯(cuò)：
Object
如果非要上面這樣寫(xiě)，那也可以。把 var 換成 Object 就不報(bào)錯(cuò)了：
和 Java 類(lèi)似，Object 是所有對(duì)象的根基類(lèi)。但是這樣的話，如果想打印一下 num 的字符串長(zhǎng)度，是會(huì)報(bào)錯(cuò)的：
因?yàn)?length 是屬于 String 的，但系統(tǒng)只知道 num 是一個(gè)對(duì)象，并不知道它是一個(gè) String。
dynamic
如果還是非要這樣寫(xiě)，那也可以。Dart 有一個(gè)特有的關(guān)鍵字 dynamic，把 Object 改成 dynamic 就不報(bào)錯(cuò)了：
我們運(yùn)行一下這個(gè)文件，可以在控制臺(tái)看到正確打印出了字符串長(zhǎng)度。
函數(shù)
dynamic
在 Dart 里，函數(shù)也是可以不寫(xiě)返回類(lèi)型的，不寫(xiě)的話會(huì)被當(dāng)做 dynamic 來(lái)處理。這樣的話，函數(shù)的類(lèi)型就是 return 的類(lèi)型，如果沒(méi)有 return 則是 void 類(lèi)型。比如可以這樣:
運(yùn)行之后是能正確打印出字符串長(zhǎng)度的。
用于傳參
Dart 里的函數(shù)也是一個(gè)對(duì)象，所以可以把函數(shù)作為參數(shù)來(lái)傳遞，比如：
可選參數(shù)
在 Dart 的函數(shù)傳參里，有一個(gè)叫可選參數(shù)的概念，我們以文字控件 Text 為例，在源碼里可以看到 Text 的構(gòu)造函數(shù)是這樣的:
首先，在參數(shù)里有一個(gè) data，它是要顯示的文字內(nèi)容，是一個(gè)必填項(xiàng)。而 data 后面的一堆參數(shù)，是用一個(gè)大括號(hào)括起來(lái)的，這些參數(shù)就叫做可選參數(shù)，意思是這些參數(shù)可傳可不傳。
假如我們要顯示一個(gè)比較長(zhǎng)的文字，又想限制它最多顯示兩行，就可以這樣來(lái)創(chuàng)建一個(gè) Text:
可選參數(shù)，在 Flutter 里面用的非常多。
異步
Future
在 Dart 里使用 Future 來(lái)處理異步任務(wù)，比如我們現(xiàn)在延時(shí)一秒打印 666，代碼如下：
Future 的語(yǔ)法和 Promise 非常像。任務(wù)執(zhí)行成功會(huì)調(diào)用 then，執(zhí)行失敗會(huì)調(diào)用 catchError，而無(wú)論成功還是失敗，都會(huì)調(diào)用 whenComplete。
async/await
如果你不喜歡上面那種寫(xiě)法，或者是想把異步轉(zhuǎn)成同步，就可以用 async 和 await 這兩個(gè)關(guān)鍵字來(lái)轉(zhuǎn)換。
我們把上面的代碼轉(zhuǎn)換一下，寫(xiě)一個(gè) getString 方法，返回的類(lèi)型是 Future，它會(huì)延時(shí)返回一個(gè)字符串。在 main 函數(shù)后面加上 async 關(guān)鍵字，在 getString() 前面加上 await，代碼如下:
運(yùn)行之后可以看到，能正常延時(shí)一秒后，把字符串打印出來(lái)。這里 getString() 返回的類(lèi)型是 Future，而 await getString() 則是返回了延時(shí)之后返回的字符串。await 要在 async 的函數(shù)里面才能使用。
async 和 await 其實(shí)是一個(gè)語(yǔ)法糖，它最終也是轉(zhuǎn)換成 Future 調(diào)用鏈的形式執(zhí)行的。
接下來(lái)回到 Flutter，F(xiàn)lutter 里最重要的一個(gè)概念是 Widget（下面翻譯作控件）。
在原生開(kāi)發(fā)里面，我們可能會(huì)在界面上區(qū)分，這是一個(gè) View，這是一個(gè) Layout，這是一個(gè) View Controller。但在 Flutter 里面，它們?nèi)紝儆谝粋€(gè)統(tǒng)一的模型 Widget。可以說(shuō)，在 Flutter 界面里，所有東西都是 Widget。
以前學(xué)面向?qū)ο蟮臅r(shí)候，我們都聽(tīng)過(guò)一句話，叫萬(wàn)物皆對(duì)象。我這里套用一下，在 Flutter 里， 萬(wàn)物皆控件 。
具體有哪些控件，我做了一下簡(jiǎn)單的分類(lèi)。
根控件
所有的控件都屬于 StatefulWidget 或 StatelessWidget 。它們的區(qū)別是，StatefulWidget 擁有狀態(tài) State ，而 StatelessWidget 沒(méi)有。
StatefulWidget
當(dāng)一個(gè)控件是可變的時(shí)候，就要使用 StatefulWidget 來(lái)構(gòu)建。StatefulWidget 本身不可變，但它持有的狀態(tài) State 是可變的。
StatelessWidget
當(dāng)一個(gè)控件狀態(tài)是固定不可變的時(shí)候，就可以使用 StatelessWidget。前面我們寫(xiě)的 Hello World 就是使用 StatelessWidget。
容器控件
容器類(lèi)控件一般是將某些屬性或配置，作用在它的子控件上，比如控件所在的寬高、背景、位置等。
常用的容器控件有 Container、Center、Padding 等。
布局控件
布局控件可以類(lèi)比作原生開(kāi)發(fā)中的 Layout，通常它會(huì)擁有一個(gè) children 的屬性，用于接收一個(gè)控件數(shù)組，對(duì)這些控件進(jìn)行特定的排版。
常用的布局控件有 Row、Column、Stack、Flex 等。
基礎(chǔ)控件
基礎(chǔ)控件就是常用的文字、按鈕、圖片等控件。
常用的基礎(chǔ)控件有 Text、TextField、Button、Image 等。
功能控件
在 Flutter 里還有一類(lèi)控件，它們不影響 UI 布局，但帶有一些特定的功能，比如頁(yè)面跳轉(zhuǎn)、事件監(jiān)聽(tīng)、定義主題等。我們把這一類(lèi)控件稱(chēng)作功能控件。
常用的功能控件有 Navigator、NotificationListener、Theme 等。
開(kāi)始寫(xiě) Flutter 代碼了。還記不記得，在 Flutter 項(xiàng)目創(chuàng)建之后，是自帶一個(gè)計(jì)數(shù)器 demo 的，現(xiàn)在我們用自己的代碼實(shí)現(xiàn)一遍。代碼修改成如下：
運(yùn)行之后，就可以看到這樣的界面了：
按鈕每點(diǎn)擊一次，數(shù)字就會(huì)加一。下面我們來(lái)分析一下這段代碼，看下里面用到的一些 Widget。
StatefulWidget
由于頁(yè)面中的數(shù)字是跟隨狀態(tài)變化的，所以該頁(yè)面改用 StatefulWidget。StatefulWidget 并不會(huì)直接返回一個(gè) Widget，而是返回狀態(tài) State，在 State 里再返回 Widget。
Scaffold
Scaffold 是一個(gè)標(biāo)準(zhǔn)的 Material Design 頁(yè)面，它包含了標(biāo)題欄、浮動(dòng)按鈕、側(cè)滑菜單、底部導(dǎo)航欄等配置。我們這里用到了標(biāo)題欄 appBar、頁(yè)面內(nèi)容 body、浮動(dòng)按鈕 floatingActionButton。
AppBar
AppBar 就是標(biāo)題欄，通過(guò)查看控件的構(gòu)造方法，我們可以知道它可配置的屬性。
AppBar 的可選參數(shù)除了標(biāo)題 title，還可以配置標(biāo)題前的內(nèi)容 leading，右側(cè)的操作按鈕 anctions，控件垂直高度 elevation 等。我們只傳了 title，其他屬性都用默認(rèn)值。
Center
Center 是一個(gè)容器類(lèi)控件，它的作用就是讓它的子控件居中顯示。
FloatingActionButton
熟悉安卓開(kāi)發(fā)的應(yīng)該對(duì)這個(gè)控件比較熟悉，它就是頁(yè)面右下角一個(gè)特定樣式的 Button，參數(shù)里面的 onPressed 是一個(gè)必填項(xiàng)，要傳一個(gè)點(diǎn)擊之后的回調(diào)函數(shù)。
根據(jù)這個(gè)例子，下面給大家介紹一下 Flutter 兩個(gè)比較重要的特性。
點(diǎn)擊 Button 之后，我們把 num 變量加一，并使用 setState 通知狀態(tài)發(fā)生了改變，F(xiàn)lutter 會(huì)根據(jù)新的狀態(tài)更新 UI。如果有接觸過(guò)小程序開(kāi)發(fā)，setState 就和小程序的 setData 類(lèi)似。
在 Flutter 里面我們不需要用 set 方法來(lái)更新 UI，可變控件是和狀態(tài)綁定的，這就是 Flutter 的響應(yīng)式 UI 編程。
在 Android Q 和 iOS 13 里都加入了暗黑模式，我們也換一個(gè)暗黑主題來(lái)玩一下。MaterialApp 里有一個(gè) theme 的屬性，我們把它配置一下:
這次改完之后不點(diǎn) Run 了，我們點(diǎn)一下閃電圖標(biāo) Flutter Hot Reload ，就能看到界面發(fā)生了變化:
這就是 Flutter 的 熱重載 ，在修改完代碼之后，通過(guò)熱重載就能馬上在設(shè)備上看到修改結(jié)果，可以很大程度上增加開(kāi)發(fā)效率。
下面再給大家介紹幾個(gè) Flutter 里的常見(jiàn)操作。
在 Flutter 里，使用 Navigator 來(lái)管理頁(yè)面跳轉(zhuǎn)，比如要跳轉(zhuǎn)到一個(gè) NewPage 可以這樣寫(xiě):
進(jìn)棧使用 push，出棧則是 pop。
使用 MaterialPageRoute 會(huì)模擬出 Android 上頁(yè)面跳轉(zhuǎn)的過(guò)場(chǎng)效果。
我們來(lái)看看怎么顯示一張本地圖片。
先在根目錄新建一個(gè)存放圖片的文件夾，比如叫 images，把圖片 picture.png 放進(jìn)去。
找到根目錄下的 pubspec.yaml 文件，這個(gè)便是 Flutter 依賴(lài)配置文件，我們需要在這里配置一下剛才的圖片：
這樣，我們就能使用 Image 控件把這張圖片顯示出來(lái)了：
和 node 的 npm 以及 Android 的 jcenter 類(lèi)似，F(xiàn)lutter 也擁有一個(gè)公共倉(cāng)庫(kù) pub.dev。pub.dev 是 Google 官方的 Dart 倉(cāng)庫(kù)，在上面可以找到我們需要的包和插件。
Flutter 本身沒(méi)有 Toast，我們來(lái)接入一個(gè)。在 pub.dev 上搜索后，我決定使用 fluttertoast：
按照說(shuō)明，在 pubspec.yaml 文件里的 dependencies 下配置：
點(diǎn)一下 Android Studio 右上角的 Packages get 同步之后就可以使用了：
我們上面使用的都是 Material Design 的控件，它們都是在 flutter/material.dart 包里面的。如果要使用 iOS 風(fēng)格的控件，則要用到 flutter/cupertino.dart 包：
iOS 風(fēng)格的控件，基本都以 Cupertino 開(kāi)頭。我們把計(jì)時(shí)器頁(yè)面里的控件替換一下：
效果如下：
代碼的部分就到這里了，接下來(lái)跟大家聊一下編譯方式，編程語(yǔ)言的編譯方式有兩種。
關(guān)于它們孰優(yōu)孰劣，就要看從哪個(gè)角度去對(duì)比了。JIT 的話，它的一大特點(diǎn)就是支持動(dòng)態(tài)發(fā)布代碼，也就是支持熱更新。但要是從性能的角度考慮，AOT 會(huì)更好，因?yàn)樵谶\(yùn)行的時(shí)候不用再進(jìn)行編譯的操作的，運(yùn)行的效率會(huì)更高一些。
回到我們一開(kāi)始的時(shí)候留下的問(wèn)題，為什么別的跨平臺(tái)方案都是用 JavaScript，而 Flutter 要用 Dart 來(lái)開(kāi)發(fā)。JavaScript 的編譯方式是 JIT 的，它不支持 AOT。而 Dart 同時(shí)支持 JIT 和 AOT。
Flutter 在開(kāi)發(fā)階段使用 JIT，讓我們用上了熱重載，增加了開(kāi)發(fā)效率。在打包時(shí)改用 AOT，保證了正式版應(yīng)用的性能。
最后講一下大家比較關(guān)心的一個(gè)東西，F(xiàn)lutter 是否支持熱更新？前面說(shuō)到 Dart 支持 JIT，所以從技術(shù)層面它是支持的。但是目前是不支持的，在官方的計(jì)劃文檔中，可以看到:
至于原因，官方在這里進(jìn)行了說(shuō)明?？偟膩?lái)說(shuō)，是由于政策的限制，以及出于對(duì)性能和安全性的考慮，暫時(shí)不支持了。
到這就結(jié)束啦。由于想把 Flutter 基礎(chǔ)在一篇內(nèi)講完，沒(méi)有涉及太多細(xì)節(jié)，如果要寫(xiě) Flutter 代碼還需要深入學(xué)習(xí)。但相信理解之后再學(xué)，會(huì)輕松很多。
這一周繼續(xù)聊跨平臺(tái)桌面開(kāi)發(fā)這個(gè)事情。
在這篇文章中，我暫時(shí)會(huì)放下Electron與WebView2的一個(gè)對(duì)比，而聊一聊跨平臺(tái)這個(gè)對(duì)于程序員群體來(lái)說(shuō)不陌生的詞。
一個(gè)趨勢(shì)是：跨平臺(tái)開(kāi)發(fā)幾乎是在各個(gè)技術(shù)方向都會(huì)持續(xù)發(fā)展的
跨平臺(tái)這個(gè)詞，對(duì)于程序員來(lái)說(shuō)，應(yīng)該是不陌生的。因?yàn)檫@個(gè)概念不只在某一端存在，后端，前端，移動(dòng)端，桌面端幾乎所有方向都對(duì)跨平臺(tái)有需求。
在后端，Java是跨平臺(tái)的，當(dāng)你用Java來(lái)編寫(xiě)后端服務(wù)時(shí)，并不需要考慮操作系統(tǒng)，因?yàn)樗鼛缀踔С种髁鞯牟僮飨到y(tǒng)?，F(xiàn)在，編寫(xiě)一個(gè)后端服務(wù)，選用Java仍是主流。雖然可能它的跨平臺(tái)特性已經(jīng)不是程序員最在意的點(diǎn)了。
而在移動(dòng)端，類(lèi)似React Native，F(xiàn)lutter也是非常有名的跨平臺(tái)移動(dòng)開(kāi)發(fā)，它們與移動(dòng)原生開(kāi)發(fā)方式之間一直是競(jìng)爭(zhēng)與共存。
而前端因?yàn)橐劳杏跒g覽器，天然就是跨平臺(tái)的。事實(shí)上，很多應(yīng)用或服務(wù)早期紛紛選擇從原生應(yīng)用遷移至前端WEB方式的一個(gè)非常重要的原因就在于它是跨平臺(tái)的。
桌面操作系統(tǒng)很長(zhǎng)一段時(shí)間一直是Windows一家獨(dú)大，所以桌面開(kāi)發(fā)一直是Windows獨(dú)占，直至現(xiàn)在為止，很多專(zhuān)業(yè)級(jí)的軟件仍然是Windows獨(dú)占的。
而Linux桌面操作系統(tǒng)與MacOS桌面操作系統(tǒng)，早些年幾乎可以忽略不計(jì)，壓根不需要考慮這兩種系統(tǒng)。但隨著近些年它們的慢慢流行，特別是蘋(píng)果的MacOS的以其杰出的工藝，流暢的體驗(yàn)，疊加蘋(píng)果手機(jī)的流行，其市場(chǎng)份額增長(zhǎng)非常之快，在特定的諸如編程，設(shè)計(jì)等行業(yè)人群中使用范圍較廣，這使得開(kāi)發(fā)支持MacOS系統(tǒng)這個(gè)點(diǎn)變得越來(lái)越重要。
所以，在桌面開(kāi)發(fā)領(lǐng)域，跨平臺(tái)的需求也越來(lái)越高。
這也是Electron及早期的NW.js能迅速發(fā)展起來(lái)并得到非常廣應(yīng)用的原因所在。
無(wú)論是哪一端，跨平臺(tái)技術(shù)之所以頻繁出現(xiàn)與不斷發(fā)展，其根本原因就在于編程的一個(gè)重要痛點(diǎn)在于：
為了讓同一個(gè)服務(wù)能在所有設(shè)備上運(yùn)行，程序員不得不編寫(xiě)與維護(hù)非常多不同版本的程序
每一個(gè)程序或軟件后面的服務(wù)，都有一個(gè)非常迫切的需求，就是期望它的用戶(hù)無(wú)論何時(shí)，無(wú)論何地，無(wú)論使用任何設(shè)備，都能方便友好的使用這個(gè)服務(wù)。
也是因?yàn)檫@個(gè)原因，Web發(fā)展起來(lái)了，因?yàn)閃eb的優(yōu)勢(shì)就在這，只要你的設(shè)備上有瀏覽器，就能訪問(wèn)。
但Web畢竟性能有限，且瀏覽器這種形式并不利于用戶(hù)忠誠(chéng)度的培養(yǎng)，它存在天然的弱點(diǎn)。一些簡(jiǎn)單的操作服務(wù)使用Web并無(wú)問(wèn)題，但稍微有點(diǎn)要求的，Web可能就并不是非常適合。
所以，一種趨勢(shì)不可避免地流行起來(lái)：
對(duì)不同設(shè)備或系統(tǒng)進(jìn)行抽象，基于某一種特定的編程語(yǔ)言，編寫(xiě)出能與原生程序相媲美的，又能跨平臺(tái)的技術(shù)便層出不窮了
對(duì)吧，Java是使用JVM來(lái)抽象不同的操作系統(tǒng)，React Native則是使用虛擬DOM以及轉(zhuǎn)換成原生控件的方式來(lái)實(shí)現(xiàn)跨平臺(tái)，而Electron則是通過(guò)性能較好的Chrome內(nèi)核+NodeJS原生調(diào)用能力的搭配來(lái)實(shí)現(xiàn)跨平臺(tái)桌面開(kāi)發(fā)。
總而言之，這種跨平臺(tái)的技術(shù)不會(huì)消亡，只會(huì)有新的技術(shù)層出不窮，而它們與原生開(kāi)發(fā)一定是相互競(jìng)爭(zhēng)，配合與共存的。相互之間無(wú)法取代。
那再回到跨平臺(tái)技術(shù)上來(lái)說(shuō)，一個(gè)良好的跨平臺(tái)開(kāi)發(fā)的技術(shù)或框架，重點(diǎn)是什么。
或者換種方式說(shuō)，哪些特性使得它更易于流行起來(lái)？
我個(gè)人認(rèn)為有以下的幾個(gè)點(diǎn)：
跨平臺(tái)開(kāi)發(fā)技術(shù)能不能流行起來(lái)的一個(gè)非常重要的點(diǎn)就在于，使用了什么樣的編程語(yǔ)言。
以移動(dòng)端跨平臺(tái)開(kāi)發(fā)技術(shù)來(lái)說(shuō)明，一個(gè)React Native，一個(gè)Flutter，這兩個(gè)是比較知名主流的跨平臺(tái)移動(dòng)開(kāi)發(fā)技術(shù)。React Native使用的是前端React技術(shù)，而Flutter則是Google的D語(yǔ)言。
顯而易見(jiàn)的是，雖然Flutter是使用skia引擎在底層重繪一套UI，其性能相比React Native這種模式更佳，但React Native更易于被接受。
在流行度上，React Native始終比Flutter更流行，一個(gè)最重要的原因也在于：
使用已熟知的前端編程語(yǔ)言，比起重新學(xué)習(xí)一個(gè)D語(yǔ)言更易于被接受，維護(hù)成本更可控。
這個(gè)問(wèn)題在跨平臺(tái)桌面開(kāi)發(fā)中也是類(lèi)似，跨平臺(tái)桌面開(kāi)發(fā)技術(shù)也不是Electron最開(kāi)始出現(xiàn)，比如著名的QT很早就有了，但比起Electron這種使用前端編程技術(shù)來(lái)說(shuō)，顯然在編程語(yǔ)言的門(mén)檻上和程序員群體上都存在困難，這也是Electron能后來(lái)居上的原因所在。
因?yàn)椋蠖鄶?shù)程序員群體，相比較另外學(xué)習(xí)一門(mén)什么語(yǔ)言去做什么，使用自己熟悉的語(yǔ)言來(lái)做什么是更容易，意愿也更高。
而從公司或團(tuán)隊(duì)的考量上看，選擇偏門(mén)的小眾語(yǔ)言存在成本上的顧慮，比如人員招聘是否容易？
跨平臺(tái)技術(shù)在嘗試解決不同平臺(tái)不一致，它或多或少會(huì)損耗性能。這也決定了幾乎沒(méi)有任何一個(gè)跨平臺(tái)技術(shù)能取代原生開(kāi)發(fā)。
這是一個(gè)取舍的問(wèn)題，對(duì)于一個(gè)程序來(lái)說(shuō)，究竟性能有多重要。對(duì)于比較看重性能的程序來(lái)說(shuō)，原生開(kāi)發(fā)可能是最優(yōu)選擇。
但跨平臺(tái)的性能損耗也有高低之分，并不在同一水平線上。
其實(shí)，無(wú)論是Electron，或是WebView2，都是基于瀏覽器內(nèi)核+前端技術(shù)的跨平臺(tái)桌面解決方案，這也是為什么要把它們放在一起聊的原因。
Electron是先行者（當(dāng)然，嚴(yán)格說(shuō)來(lái)，NW.js出現(xiàn)的更早，但今天它的流行度已遠(yuǎn)遠(yuǎn)落后于Electron了），而WebView2則是后來(lái)者。
那做為后來(lái)者的WebView2究竟做了哪些改進(jìn)？它又有多大的能力來(lái)挑戰(zhàn)Electron呢？
下一篇，繼續(xù)聊。
重慶分公司
重慶分公司
