關(guān)于flutter NestedScrollView導(dǎo)致其body的tabbarview的多個(gè)list同步滾動(dòng)的解決方案

講道理我起的好長的名字啊，不過文如上題，搜索到這里的兄弟應(yīng)該都知道我說的是啥情況，正好

清苑網(wǎng)站制作公司哪家好，找創(chuàng)新互聯(lián)！從網(wǎng)頁設(shè)計(jì)、網(wǎng)站建設(shè)、微信開發(fā)、APP開發(fā)、響應(yīng)式網(wǎng)站設(shè)計(jì)等網(wǎng)站項(xiàng)目制作，到程序開發(fā)，運(yùn)營維護(hù)。創(chuàng)新互聯(lián)從2013年開始到現(xiàn)在10年的時(shí)間，我們擁有了豐富的建站經(jīng)驗(yàn)和運(yùn)維經(jīng)驗(yàn)，來保證我們的工作的順利進(jìn)行。專注于網(wǎng)站建設(shè)就選創(chuàng)新互聯(lián)。

～～

我這個(gè)方案可能有點(diǎn)笨拙TT，不過自測有效，有其它想法的老哥希望可以幫忙指點(diǎn)一下～

下面進(jìn)入正題

點(diǎn)進(jìn)源碼里面看，可以發(fā)現(xiàn)他直接繼承了StatelessWidget，那我們就直接看看build方法

可以看到，這里直接返回一個(gè)scrollable或者一個(gè)子節(jié)點(diǎn)是scrollable的InheritedWidget

scrollable是一個(gè)StatefulWidget，那我們就看看它的state

首先scrollable持有一個(gè)scrollposition對(duì)象，是通過其scrollcontroller構(gòu)建的

在其state的setCanDrag方法中，對(duì)其拖動(dòng)設(shè)置了一系列的監(jiān)聽

這里就可以看出來，當(dāng)拖動(dòng)觸發(fā)時(shí)，就會(huì)通過當(dāng)前scrollable的position生成一個(gè)Drag/Hold對(duì)象，并調(diào)用相應(yīng)的方法 這個(gè)position有幾個(gè)子類，我們先隨便看一個(gè)實(shí)現(xiàn)

可以看到生成了一個(gè)ScrollDragController對(duì)象，當(dāng)手勢拖動(dòng)而調(diào)用這個(gè)對(duì)象的update方法時(shí)

可以看到直接調(diào)用其委托對(duì)象的applyUserOffset方法進(jìn)行偏移，而這個(gè)委托對(duì)象根據(jù)剛才的drag方法可以得知正是我們scrollable中的position

最后，由position通知其scrollcontext，也就是之前的scrollable進(jìn)行滑動(dòng)

具體的滑動(dòng)流程這里就不細(xì)說了，我們只是要知道這個(gè)事件是怎么傳遞的就好了，有興趣的老哥可以自行分析

NestedScrollView是一個(gè)statefulwidget，那我們就先看看它的build方法

先忽略其他奇奇怪怪的方法，我們發(fā)現(xiàn)在我們body的外面，包裹了一層PrimaryScrollController，同時(shí)它還持有innerController，這個(gè)innerController暫時(shí)先不管它是啥

還記不記得在最開始ScrollView的build方法中，生成Scrollable的時(shí)候，我們已經(jīng)見過這個(gè)PrimaryScrollController了，再回顧一下

再看看PrimaryScrollController.of(context)

可以看到，在生成scrollable的時(shí)候，在primary = true的情況下是會(huì)向上查找的，看看有沒有PrimaryScrollController，如果有的話，scrollable使用的controller實(shí)際就是nestedscrollview中的innerController了

而之前看過了，scrollable中的position就是scrollcontroller來生成的，那么在這種情況下：

實(shí)際上是生成了_NestedScrollPosition并返回給了body中的scrollable

構(gòu)造方法中有一個(gè)參數(shù)coordinator 暫時(shí)先不管

好了，下面我們在回頭看剛才NestedScrollView的build方法，實(shí)際上是生成了一個(gè)_NestedScrollViewCustomScrollView，繼承自大名鼎鼎的CustomScrollView，它當(dāng)然也是scrollview啦，而我們傳給它的controller也是一個(gè)_NestedScrollController，不過叫做_outerController，和body中的不是同一個(gè)罷了，那么自然這個(gè)父scrollview的position也是_NestedScrollPosition。

下面我們按照之前的邏輯，當(dāng)拖動(dòng)開始時(shí)，就會(huì)調(diào)用position.drag方法

可以看到，實(shí)際上吧方法交給了我們之前多次見到的coordinator來完成，那我們就簡單看一下吧

這里可以看到，他把返回的ScrollDragController的委托者設(shè)成了自己

那么自然在拖動(dòng)的時(shí)候，調(diào)用的就是coordinator的applyUseroffset方法了 我們分析一下

可以看到，在需要子列表滾動(dòng)時(shí)，是對(duì)innerPositions中的所有position調(diào)用滑動(dòng)方法的

而這innerPositions中的position是怎么來的呢？跟蹤一下可以發(fā)現(xiàn)是在調(diào)用NestedScrollController的attach時(shí)添加進(jìn)來的，如下

因?yàn)橹拔覀兛吹竭^，子scrollable中的controller就是這個(gè)NestedScrollController，所以在updateopsition時(shí)會(huì)把舊的detach調(diào)，把新生成的position attach進(jìn)來

另外，在dispose中也會(huì)detach

由此我們就知道啦，因?yàn)殚_啟了緩存后就不會(huì)調(diào)用劃出屏幕的頁面的dispose，自然所有子scrollable的position都存在nestedScrollController里面了，當(dāng)發(fā)生滑動(dòng)時(shí)，遍歷調(diào)用positions數(shù)組，就導(dǎo)致屏幕外的列表也跟著滑動(dòng)了～

既然開啟了緩存，手動(dòng)dispose肯定是沒啥意義的，實(shí)際上我們只要在頁面切換過后把未顯示的position 給detach掉就好了。

然鵝，因?yàn)閒lutter不支持反射，子布局傳遞的position我們拿不到，nestedScrollController我們也不能直接拿到=。=

不過有一個(gè)對(duì)象我們之前見到過，scrollable就是通過他獲取controller的，而position則是傳給了獲取到的controller 就是PrimaryScrollController了，所以我打算在中間第三者插足，對(duì)傳遞Position的PrimaryScrollController進(jìn)行Hook

在使用的時(shí)候把子列表添加進(jìn)去，并設(shè)置對(duì)應(yīng)的GlobalKey。

然后監(jiān)聽Tab切換

以上是我的方案，有問題的話還希望老哥幫忙指正，也希望有其他思路的老哥指點(diǎn)一下～～

上一下Github項(xiàng)目地址 用Flutter寫的WanAndroid 其中用到了這個(gè)方案

= =

3

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

Uniapp目前比較成熟，而且用的是Vue語法，學(xué)習(xí)成本比較低，而且行業(yè)里面用的也比較廣泛，而Flutter的話，學(xué)習(xí)成本略高，因?yàn)橐獙W(xué)習(xí)新的語言，還有就是目前生態(tài)不是特別完備，等他再發(fā)展發(fā)展吧。目前黑馬程序員就有學(xué)習(xí)Vue的視頻，你可以去學(xué)習(xí)一下，提高自己的能力，讓自己的職場更好！您的采納給我提供源源不斷的動(dòng)力，很高興您能滿意

Flutter 與 iOS 原生 webView 對(duì)比

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

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

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

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

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

在這里，筆者又加了一個(gè)測試，嘗試記錄從 viewController 的 viewDidLoad 到 webview 的 didFinish 時(shí)間，測試了新浪的數(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 主站的時(shí)間；UIWebViewA 的數(shù)據(jù)是因?yàn)樵诩虞d完 sina 主站之后，新浪又加載了一個(gè) ，所以導(dǎo)致總時(shí)間延長，不過即使按照 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。

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

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

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

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

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

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

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

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

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

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

flutter_webView_plugin ：在iOS中使用的就是原生的WKWebView，所以總體和 native WKWebView 表現(xiàn)差不多。如果是混編項(xiàng)目中，因?yàn)樗话艘粚樱皂撁婕虞d上存在一定的劣勢，所以混編項(xiàng)目中仍然推薦使用 WKWebView。不過如果從多端考慮、以及項(xiàng)目可遷移等，那么使用也未嘗不可，就是維護(hù)成本要增加一些，需要維護(hù)兩套 webView。這個(gè)就需要根據(jù)自己的情況自己取舍了。

vscode里面輸入flutter run什么反應(yīng)都沒有是什么問題？要怎么解決呢？

首先你要確定你的網(wǎng)絡(luò)是不是通的，之前能運(yùn)行說明你之前環(huán)境是好的，現(xiàn)在不行了，那你中途肯定是有過變動(dòng)，有變動(dòng)就有可能需要聯(lián)網(wǎng)去下載（很慢會(huì)造成假死），或者是你項(xiàng)目里配的倉庫訪問不到了（比如是國外的倉庫，換成阿里的試試）

Flutter 網(wǎng)絡(luò)請求 Dio 攔截器詳解

昔日的小王憑借這他的小心謹(jǐn)慎和借助漂亮能干的女友 Dio 的輔助，終于干下了一番事業(yè)，成為中華大地響當(dāng)當(dāng)?shù)娜宋铮⊥跻沧兂衫贤酢Ｈ缃瘢贤跻呀?jīng)年近花甲，看似邁上了人生巔峰，卻也遇到了人生的煩惱——那就是他的兒子，新的小王。

小王和他爹當(dāng)年的小心謹(jǐn)慎不同，小王自海外留學(xué)回來，也不愿意接手老王的事業(yè)。反而迷戀起了互聯(lián)網(wǎng)，玩游戲、微博噴人、撩網(wǎng)紅等等。前兩項(xiàng)倒還好，但是后一項(xiàng)，讓老王心煩得很。這網(wǎng)紅哪能隨便撩的，萬一弄出許多小小王來，多大家業(yè)都不夠分的啊！

關(guān)鍵時(shí)刻，還是老王的媳婦，曾經(jīng)被 金屋藏嬌 的Dio 想出了新的招術(shù)，再次讓老王佩服不已。老王媳婦Dio給小王搞了個(gè)攔截器，只要小王要在互聯(lián)網(wǎng)做什么，都會(huì)被她給先攔截下來，然后她再根據(jù)小王要做的事情決定是不是要替他發(fā)出去；或者是收到什么消息的時(shí)候，也會(huì)先看一遍，沒問題再給小王看。而且，最為關(guān)鍵的是，小王對(duì)這一切壓根都不知道！

老王媳婦一開始是這么干的，小王在互聯(lián)網(wǎng)有什么新的動(dòng)向直接向老王匯報(bào)。

這下小王在互聯(lián)網(wǎng)就完全被監(jiān)視了——而且他壓根不知道！只是，每次他說要錢的時(shí)候，老王不再隨便給了！

但這個(gè)時(shí)候，小王還能在網(wǎng)上撩，畢竟上網(wǎng)在這個(gè)時(shí)代是不怎么要錢的。

老王媳婦 Dio 一看這種方式不行，就又心生一計(jì)，每次小王聊網(wǎng)紅的時(shí)候，直接狠心拒絕！

小王這下子懵圈了，難道是他的那些“土味情話”已經(jīng)失效了？每次發(fā)出去消息都遭受到了無情的打擊，讓他心灰意冷。漸漸地他就淡出了互聯(lián)網(wǎng)，至于現(xiàn)在在干什么，誰也不知道。感覺又像是當(dāng)初老王金屋藏嬌一樣，現(xiàn)在的小王也逐漸被隱藏了起來。從此，互聯(lián)網(wǎng)只剩下小王和各個(gè)網(wǎng)紅的傳說。

借著老王和小王的故事，我們講述了 Dio 的封裝和 Dio 的攔截器。其中攔截器可以應(yīng)用于很多實(shí)際場景：

注意，Dio 的實(shí)例可以同時(shí)添加多個(gè)攔截器，以便處理不同的情況。

flutter dio 網(wǎng)絡(luò)請求問題

最近在做公司工業(yè)互聯(lián)網(wǎng)的一個(gè)項(xiàng)目 之前做了一個(gè)ipad 版本的 在使用dio網(wǎng)絡(luò)請求框架的時(shí)候發(fā)現(xiàn)請求登錄的時(shí)候后臺(tái)一直報(bào)簽名錯(cuò)誤問題? 檢查了幾遍寫的簽名方法沒有發(fā)現(xiàn)錯(cuò)誤 后面仔細(xì)查了下 是服務(wù)器不能識(shí)別我傳的數(shù)據(jù)。。。

如果content-type是form-data 我們需要通過FormData類來構(gòu)建數(shù)據(jù)，否則服務(wù)器將無法識(shí)別

同時(shí)需要傳入一個(gè)Option指明content-type，而form-data的content-type完整類型表述為：multipart/form-data

主要我是個(gè)新手啊?

查看源碼?

headers里面并有multipart/form-data 這個(gè)類型啊? ? 講道理這個(gè)是常用的contentType啊 應(yīng)該要列出來才對(duì)啊?

咋整？

自己設(shè)置。。。。

后臺(tái)就可以正常接收表單參數(shù)了

網(wǎng)站欄目：flutter啊,百度貼吧flutter
鏈接URL：http://chinadenli.net/article19/dsioogh.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供網(wǎng)站策劃、移動(dòng)網(wǎng)站建設(shè)、品牌網(wǎng)站設(shè)計(jì)、搜索引擎優(yōu)化、微信小程序、Google

廣告

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