基于Weex的Flutter項目框架

最近在做的一個項目，項目的前期采用Weex開發(fā)。但是隨著交互復(fù)雜度的增加，Weex一處開發(fā)多處多處運行的特征并沒有很好的體現(xiàn)，相反很多時候我們還是需要做IOS和Android的適配。如今火熱的Flutter相比Weex和Rn來說，給出了更好的跨平臺解決方案。所以我們設(shè)計了一套基于Weex實現(xiàn)，底層跑在Flutter Engine上的框架。

創(chuàng)新互聯(lián)專注于吉首企業(yè)網(wǎng)站建設(shè),成都響應(yīng)式網(wǎng)站建設(shè)公司,商城網(wǎng)站制作。吉首網(wǎng)站建設(shè)公司,為吉首等地區(qū)提供建站服務(wù)。全流程按需開發(fā)網(wǎng)站，專業(yè)設(shè)計，全程項目跟蹤，創(chuàng)新互聯(lián)專業(yè)和態(tài)度為您提供的服務(wù)

底層的Runtime采用isolate engine,框架業(yè)務(wù)邏輯，Dom的解析邏輯和Render邏輯都跑在這里。

渲染引擎采用Flutter的Skia，徹底剝離了Android和IOS的差異性.

將Weex VirsualDom的解析都替換成Flutter Widget.

設(shè)計基于Weex2Dart的Brider,使JS和Dart可以相互調(diào)用

weex-demo的性能展示

release環(huán)境下采用AOT模式，性能會有質(zhì)的飛躍。

Android-Release版本只有10m大小

相比Weex和Rn具有更好的性能，同時具有更好的跨平臺性

相比Flutter，具有動態(tài)部署的能力（Flutter Release采用AoT模式并沒有動態(tài)部署的能力，即使Debug版本也只是開發(fā)環(huán)境下才有動態(tài)化能力并沒有可以實施項目的能力）

只需要會Weex開發(fā)或則Rn開發(fā)就可以，不需要額外學(xué)習(xí)Dart，已有的Weex項目可以無縫切換。

Flutter開發(fā)性能提升之：如何避免Widget重復(fù)Build

問題描述：

在Flutter開發(fā)的過程中，當(dāng)我們獲取到新的數(shù)據(jù)或者數(shù)據(jù)發(fā)生變化，需要去執(zhí)行setState進(jìn)行頁面刷新的時候，經(jīng)常會出現(xiàn)不必要的子節(jié)點Widget也進(jìn)行了build，但實際上我們是不想讓它再次build，出現(xiàn)這些問題的典型情況是在使用FutureBuilder的時候，例如：

在上面這個示例中，如果再次調(diào)用Build方法，則會觸發(fā)httpCall()的方法。

那么怎樣才能避免不必要的部件構(gòu)建呢？

分析：

在Flutter中，Build方法的設(shè)計方式是pure/without side effects，書面意思是無副作用的/純粹的，簡單點理解我們可以將其含義看作不會對外部的方法或者變量產(chǎn)生影響的。這是因為許多外部因素能夠觸發(fā)新的小部件的構(gòu)建，例如這些情況：

但是，這也意味著Build方法可以不去觸發(fā)httpCall()的方法或者不修改任何狀態(tài)。

解決

回歸問題，當(dāng)前我們面臨的問題是Build方法造成了副作用，也就是造成了無關(guān)的Build調(diào)用麻煩。

所以，只要我們使Build方法保持純粹/無副作用，這樣就算多少次調(diào)用它，也不會對其他Widget的Build方法產(chǎn)生影響。

在上面的示例中，我們將Widget轉(zhuǎn)換為StatefulWidget，然后提取httpCall()到initState中，這樣問題就解決了

另外，還可以使一個Widget能夠在不強迫其子部件也構(gòu)建的情況下進(jìn)行重新構(gòu)建。

在Widget的實例保持不變時;Flutter會有意識的不去重建子部件。這意味著我們可以緩存Widget樹的某些部分，以防止不必要的重新構(gòu)建。

最簡單的方法是使用const修飾構(gòu)造函數(shù):

由于const的修飾，即使調(diào)用了數(shù)百次build，DecoratedBox的實例也將保持不變。

或者你可以這樣使用以達(dá)到相同的結(jié)果:

在這個例子中，當(dāng)StreamBuilder收到新值的通知時，即使StreamBuilder的Column進(jìn)行了重構(gòu)，subtree也不會進(jìn)行重構(gòu)。這是因為由于閉包，MyWidget的實例沒有改變。

這種模式在動畫中經(jīng)常使用。典型的是使用AnimatedBuilder和所有的*Transition時，例如AlignTransition。

我們還可以將subtree存儲到類的一個字段中，但是并不推薦你這樣做，因為它會破壞Flutter的熱重載。

做混合的話Uniapp和Flutter我應(yīng)該學(xué)哪個啊？

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

Flutter 仿京東商品詳情頁嵌套滾動組件

這是領(lǐng)苗確認(rèn)記錄詳情頁需要展示給用戶的內(nèi)容，大家可以看到這個頁面要承載很多的信息，要向下滾動一段很長的距離才能展示完，想要實現(xiàn)的效果是在頁面的頂部有一個TabBar，用戶可以通過點擊TabBar進(jìn)行錨點(jumpTo到指定位置)，AppBar下的整個頁面是可以自由滾動的，在滾動過程中AppBar始終固定在頂部，TabBar在第一次進(jìn)入詳情頁的時候不顯示，只有在向下滑動的時候會由透明漸變?yōu)椴煌该鞑⒐潭ㄔ陧敳浚瑫r當(dāng)頁面滑動到TabBar錨點位置的時候TabBar會切換到對應(yīng)的下標(biāo)，也就是要實現(xiàn)TabBar和ScrollView聯(lián)動的雙向控制，Tabbar的切換可以控制頁面的跳轉(zhuǎn)，頁面的滑動又可以反過來控制TabBar的切換，類似與京東、淘寶的商品詳情頁效果。

SliverAppBar基本已經(jīng)達(dá)到了我們想要的效果，但在界面頂部會有塊空白區(qū)域試了很多方法怎么都去不掉，最后看了SliverAppBar這個控件的源碼發(fā)現(xiàn)是它自帶的初始高度。

這個沒法設(shè)置或消除，不可能直接去改源碼，所以后來換了一種實現(xiàn)思路，舍棄了SliverAppBar這個控件，以Stack的形式將TabBar置于ScrollView之上也能達(dá)到我們想要的效果，那么問題來了，如何實現(xiàn)TabBar的滾動漸變？很容易想到Opacity透明度控件，通過滾動監(jiān)聽來控制TabBar透明度的改變，借助Notificaion可以完美實現(xiàn)我們的需求。

Notification是Flutter中一個重要的機制，在Widget樹中，每一個節(jié)點都可以分發(fā)通知（Notification）與父(包括祖先)Widget通信，通知會沿著當(dāng)前節(jié)點（context）向上傳遞，所有父節(jié)點都可以通過NotificationListener來監(jiān)聽自己關(guān)注的通知，F(xiàn)lutter中稱這種通知由子向父的傳遞為“通知冒泡”（Notification Bubbling）。

　 Flutter中很多地方使用了通知，如可滾動(Scrollable) Widget中滑動時就會分發(fā)ScrollNotification，而Scrollbar正是通過監(jiān)聽ScrollNotification來確定滾動條位置的。除了ScrollNotification，F(xiàn)lutter中還有SizeChangedLayoutNotification、KeepAliveNotification 、LayoutChangedNotification等。

通過NotificationListener監(jiān)聽滾動事件和通過ScrollController有兩個主要的不同：

通過改造后，目前這個組件的原型已經(jīng)實現(xiàn)并且可以滿足我們的需求，最后就是對該demo進(jìn)行完善使其能夠完美接入我們的業(yè)務(wù)，做到技術(shù)賦能業(yè)務(wù)。

在一個頁面滾動區(qū)域不是很長的情況下不建議使用，只有當(dāng)頁面足夠長的情況下使用這個組件效果會比較好，因為如果一個頁面過短，點擊TabBar最后一欄進(jìn)行錨點時，頁面最后一個子模塊內(nèi)容無法置頂，只會將頁面最后的內(nèi)容推到屏幕范圍內(nèi)，并且由于TabBar監(jiān)聽到的是滾動的位置，會導(dǎo)致TabBar無法切換到對應(yīng)的下標(biāo)，看上去會像個bug，其實是因為底部已經(jīng)沒有內(nèi)容了。

這個組件本身并沒有太大的技術(shù)難度，但是有一些比較細(xì)節(jié)的小邏輯得處理好，并且從中衍生出來的很多瑣碎的小的知識點都可以進(jìn)行拓展。 在組件開發(fā)的過程中遇到問題時不局限于控件本身的設(shè)計模式，轉(zhuǎn)變開發(fā)思維去找尋一些比較新穎的解決方案可能會有意外的收獲。同時技術(shù)不能脫離于業(yè)務(wù)，技術(shù)賦能業(yè)務(wù)才能創(chuàng)造價值。

跨平臺桌面開發(fā)，Electron還是WebView2 （中篇）

這一周繼續(xù)聊跨平臺桌面開發(fā)這個事情。

在這篇文章中，我暫時會放下Electron與WebView2的一個對比，而聊一聊跨平臺這個對于程序員群體來說不陌生的詞。

一個趨勢是：跨平臺開發(fā)幾乎是在各個技術(shù)方向都會持續(xù)發(fā)展的

跨平臺這個詞，對于程序員來說，應(yīng)該是不陌生的。因為這個概念不只在某一端存在，后端，前端，移動端，桌面端幾乎所有方向都對跨平臺有需求。

在后端，Java是跨平臺的，當(dāng)你用Java來編寫后端服務(wù)時，并不需要考慮操作系統(tǒng)，因為它幾乎支持主流的操作系統(tǒng)。現(xiàn)在，編寫一個后端服務(wù)，選用Java仍是主流。雖然可能它的跨平臺特性已經(jīng)不是程序員最在意的點了。

而在移動端，類似React Native，F(xiàn)lutter也是非常有名的跨平臺移動開發(fā)，它們與移動原生開發(fā)方式之間一直是競爭與共存。

而前端因為依托于瀏覽器，天然就是跨平臺的。事實上，很多應(yīng)用或服務(wù)早期紛紛選擇從原生應(yīng)用遷移至前端WEB方式的一個非常重要的原因就在于它是跨平臺的。

桌面操作系統(tǒng)很長一段時間一直是Windows一家獨大，所以桌面開發(fā)一直是Windows獨占，直至現(xiàn)在為止，很多專業(yè)級的軟件仍然是Windows獨占的。

而Linux桌面操作系統(tǒng)與MacOS桌面操作系統(tǒng)，早些年幾乎可以忽略不計，壓根不需要考慮這兩種系統(tǒng)。但隨著近些年它們的慢慢流行，特別是蘋果的MacOS的以其杰出的工藝，流暢的體驗，疊加蘋果手機的流行，其市場份額增長非常之快，在特定的諸如編程，設(shè)計等行業(yè)人群中使用范圍較廣，這使得開發(fā)支持MacOS系統(tǒng)這個點變得越來越重要。

所以，在桌面開發(fā)領(lǐng)域，跨平臺的需求也越來越高。

這也是Electron及早期的NW.js能迅速發(fā)展起來并得到非常廣應(yīng)用的原因所在。

無論是哪一端，跨平臺技術(shù)之所以頻繁出現(xiàn)與不斷發(fā)展，其根本原因就在于編程的一個重要痛點在于：

為了讓同一個服務(wù)能在所有設(shè)備上運行，程序員不得不編寫與維護(hù)非常多不同版本的程序

每一個程序或軟件后面的服務(wù)，都有一個非常迫切的需求，就是期望它的用戶無論何時，無論何地，無論使用任何設(shè)備，都能方便友好的使用這個服務(wù)。

也是因為這個原因，Web發(fā)展起來了，因為Web的優(yōu)勢就在這，只要你的設(shè)備上有瀏覽器，就能訪問。

但Web畢竟性能有限，且瀏覽器這種形式并不利于用戶忠誠度的培養(yǎng)，它存在天然的弱點。一些簡單的操作服務(wù)使用Web并無問題，但稍微有點要求的，Web可能就并不是非常適合。

所以，一種趨勢不可避免地流行起來：

對不同設(shè)備或系統(tǒng)進(jìn)行抽象，基于某一種特定的編程語言，編寫出能與原生程序相媲美的，又能跨平臺的技術(shù)便層出不窮了

對吧，Java是使用JVM來抽象不同的操作系統(tǒng)，React Native則是使用虛擬DOM以及轉(zhuǎn)換成原生控件的方式來實現(xiàn)跨平臺，而Electron則是通過性能較好的Chrome內(nèi)核+NodeJS原生調(diào)用能力的搭配來實現(xiàn)跨平臺桌面開發(fā)。

總而言之，這種跨平臺的技術(shù)不會消亡，只會有新的技術(shù)層出不窮，而它們與原生開發(fā)一定是相互競爭，配合與共存的。相互之間無法取代。

那再回到跨平臺技術(shù)上來說，一個良好的跨平臺開發(fā)的技術(shù)或框架，重點是什么。

或者換種方式說，哪些特性使得它更易于流行起來？

我個人認(rèn)為有以下的幾個點：

跨平臺開發(fā)技術(shù)能不能流行起來的一個非常重要的點就在于，使用了什么樣的編程語言。

以移動端跨平臺開發(fā)技術(shù)來說明，一個React Native，一個Flutter，這兩個是比較知名主流的跨平臺移動開發(fā)技術(shù)。React Native使用的是前端React技術(shù)，而Flutter則是Google的D語言。

顯而易見的是，雖然Flutter是使用skia引擎在底層重繪一套UI，其性能相比React Native這種模式更佳，但React Native更易于被接受。

在流行度上，React Native始終比Flutter更流行，一個最重要的原因也在于：

使用已熟知的前端編程語言，比起重新學(xué)習(xí)一個D語言更易于被接受，維護(hù)成本更可控。

這個問題在跨平臺桌面開發(fā)中也是類似，跨平臺桌面開發(fā)技術(shù)也不是Electron最開始出現(xiàn)，比如著名的QT很早就有了，但比起Electron這種使用前端編程技術(shù)來說，顯然在編程語言的門檻上和程序員群體上都存在困難，這也是Electron能后來居上的原因所在。

因為，大多數(shù)程序員群體，相比較另外學(xué)習(xí)一門什么語言去做什么，使用自己熟悉的語言來做什么是更容易，意愿也更高。

而從公司或團(tuán)隊的考量上看，選擇偏門的小眾語言存在成本上的顧慮，比如人員招聘是否容易？

跨平臺技術(shù)在嘗試解決不同平臺不一致，它或多或少會損耗性能。這也決定了幾乎沒有任何一個跨平臺技術(shù)能取代原生開發(fā)。

這是一個取舍的問題，對于一個程序來說，究竟性能有多重要。對于比較看重性能的程序來說，原生開發(fā)可能是最優(yōu)選擇。

但跨平臺的性能損耗也有高低之分，并不在同一水平線上。

其實，無論是Electron，或是WebView2，都是基于瀏覽器內(nèi)核+前端技術(shù)的跨平臺桌面解決方案，這也是為什么要把它們放在一起聊的原因。

Electron是先行者（當(dāng)然，嚴(yán)格說來，NW.js出現(xiàn)的更早，但今天它的流行度已遠(yuǎn)遠(yuǎn)落后于Electron了），而WebView2則是后來者。

那做為后來者的WebView2究竟做了哪些改進(jìn)？它又有多大的能力來挑戰(zhàn)Electron呢？

下一篇，繼續(xù)聊。

網(wǎng)頁名稱：關(guān)于flutter設(shè)計模式的信息
當(dāng)前URL：http://chinadenli.net/article16/dseeigg.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供網(wǎng)站內(nèi)鏈、做網(wǎng)站、網(wǎng)站導(dǎo)航、品牌網(wǎng)站設(shè)計、、電子商務(wù)

廣告

聲明：本網(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)