flutter啊,百度贴吧flutter

关于flutter NestedScrollView导致其body的tabbarview的多个list同步滚动的解决方案

讲道理我起的好长的名字啊，不过文如上题，搜索到这里的兄弟应该都知道我说的是啥情况，正好

～～

我这个方案可能有点笨拙TT，不过自测有效，有其它想法的老哥希望可以帮忙指点一下～

下面进入正题

点进源码里面看，可以发现他直接继承了StatelessWidget，那我们就直接看看build方法

可以看到，这里直接返回一个scrollable或者一个子节点是scrollable的InheritedWidget

scrollable是一个StatefulWidget，那我们就看看它的state

首先scrollable持有一个scrollposition对象，是通过其scrollcontroller构建的

在其state的setCanDrag方法中，对其拖动设置了一系列的监听

这里就可以看出来，当拖动触发时，就会通过当前scrollable的position生成一个Drag/Hold对象，并调用相应的方法 这个position有几个子类，我们先随便看一个实现

可以看到生成了一个ScrollDragController对象，当手势拖动而调用这个对象的update方法时

可以看到直接调用其委托对象的applyUserOffset方法进行偏移，而这个委托对象根据刚才的drag方法可以得知正是我们scrollable中的position

最后，由position通知其scrollcontext，也就是之前的scrollable进行滑动

具体的滑动流程这里就不细说了，我们只是要知道这个事件是怎么传递的就好了，有兴趣的老哥可以自行分析

NestedScrollView是一个statefulwidget，那我们就先看看它的build方法

先忽略其他奇奇怪怪的方法，我们发现在我们body的外面，包裹了一层PrimaryScrollController，同时它还持有innerController，这个innerController暂时先不管它是啥

还记不记得在最开始ScrollView的build方法中，生成Scrollable的时候，我们已经见过这个PrimaryScrollController了，再回顾一下

再看看PrimaryScrollController.of(context)

可以看到，在生成scrollable的时候，在primary = true的情况下是会向上查找的，看看有没有PrimaryScrollController，如果有的话，scrollable使用的controller实际就是nestedscrollview中的innerController了

而之前看过了，scrollable中的position就是scrollcontroller来生成的，那么在这种情况下：

实际上是生成了_NestedScrollPosition并返回给了body中的scrollable

构造方法中有一个参数coordinator 暂时先不管

好了，下面我们在回头看刚才NestedScrollView的build方法，实际上是生成了一个_NestedScrollViewCustomScrollView，继承自大名鼎鼎的CustomScrollView，它当然也是scrollview啦，而我们传给它的controller也是一个_NestedScrollController，不过叫做_outerController，和body中的不是同一个罢了，那么自然这个父scrollview的position也是_NestedScrollPosition。

下面我们按照之前的逻辑，当拖动开始时，就会调用position.drag方法

可以看到，实际上吧方法交给了我们之前多次见到的coordinator来完成，那我们就简单看一下吧

这里可以看到，他把返回的ScrollDragController的委托者设成了自己

那么自然在拖动的时候，调用的就是coordinator的applyUseroffset方法了 我们分析一下

可以看到，在需要子列表滚动时，是对innerPositions中的所有position调用滑动方法的

而这innerPositions中的position是怎么来的呢？跟踪一下可以发现是在调用NestedScrollController的attach时添加进来的，如下

因为之前我们看到过，子scrollable中的controller就是这个NestedScrollController，所以在updateopsition时会把旧的detach调，把新生成的position attach进来

另外，在dispose中也会detach

由此我们就知道啦，因为开启了缓存后就不会调用划出屏幕的页面的dispose，自然所有子scrollable的position都存在nestedScrollController里面了，当发生滑动时，遍历调用positions数组，就导致屏幕外的列表也跟着滑动了～

既然开启了缓存，手动dispose肯定是没啥意义的，实际上我们只要在页面切换过后把未显示的position 给detach掉就好了。

然鹅，因为flutter不支持反射，子布局传递的position我们拿不到，nestedScrollController我们也不能直接拿到=。=

不过有一个对象我们之前见到过，scrollable就是通过他获取controller的，而position则是传给了获取到的controller 就是PrimaryScrollController了，所以我打算在中间第三者插足，对传递Position的PrimaryScrollController进行Hook

在使用的时候把子列表添加进去，并设置对应的GlobalKey。

然后监听Tab切换

以上是我的方案，有问题的话还希望老哥帮忙指正，也希望有其他思路的老哥指点一下～～

上一下Github项目地址 用Flutter写的WanAndroid 其中用到了这个方案

= =

3

相关问答

Q1: 做混合的话Uniapp和Flutter我应该学哪个啊？

Uniapp目前比较成熟，而且用的是Vue语法，学习成本比较低，而且行业里面用的也比较广泛，而Flutter的话，学习成本略高，因为要学习新的语言，还有就是目前生态不是特别完备，等他再发展发展吧。目前黑马程序员就有学习Vue的视频，你可以去学习一下，提高自己的能力，让自己的职场更好！您的采纳给我提供源源不断的动力，很高兴您能满意

Q2: Flutter 与 iOS 原生 webView 对比

本文对比的是 UIWebView、WKWebView、flutter_webview_plugin（在iOS中使用的是WKWebView）的加载速度，内存使用情况。

测试网页打开的速度，只需要获取 WebView 在开始加载网页和网页加载完成时的时间戳，时间戳的差即为打开网页的时间

为了使差异更明显，我们选择较为复杂的 新浪首页 进行加载的对比，为了减小网络对加载速度的影响，我们让手机连接同一个网络，分别进行 10 次测试然后取平均值，另外，我们需要关闭 WebView 的缓存，防止缓存对加载速度产生影响

下面使笔者进行 10 次测试所得到的数据

结果让我有点惊讶，一直以为 WKWebView 会是个王者。结果看，速度上 WKWebView 略慢一点，不过总体差异不大（该结果仅仅是测试新浪的结果，仅供参考啦）

在这里，笔者又加了一个测试，尝试记录从 viewController 的 viewDidLoad 到 webview 的 didFinish 时间，测试了新浪的数据，如下：

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 的数据就是加载 sina 主站的时间；UIWebViewA 的数据是因为在加载完 sina 主站之后，新浪又加载了一个 ，所以导致总时间延长，不过即使按照 UIWebViewB 的数据来比较，也是 wkWebView 略胜一筹。

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

结论：

速度（didStart - didFinish） UIWebView flutter_webview WKWebView

速度（viewDidLoad - didFinish）WKWebView UIWebView flutter_webview

这里查看内存使用的是 xcode 的 debug session 中的 memory。

首先看之前测试时，连续打开十次新浪的内存情况

接着我们在看一下打开淘宝首页的内存情况

从图上可以看出，WKWebView 在内存方面有很大的优势啊，UIWebView 的内存是真的伤啊，然后 debug 看了一下 flutter_webView，他使用的就是原生的 webView 。

他相比较原生 WKWebView 的内存开销稍大一点，从测试表现来看，一般大个 30 MB 左右。

结论：内存 WKWebView flutter_webview UIWebView

可以在 html5test 中对浏览器的兼容性进行评分，通过测试发现得分分别如下

因为 flutter 里使用的就是 WK，所以和原生的 WKWebView 一样都是 444 分，比 UIWebView 的 437 略胜一筹

结论：兼容性 WKWebView = flutter_webview UIWebView

UIWebView : 速度相比较 WKWebView 稍快一点，但是内存是一大硬伤，所以只要条件允许，就不推荐使用了

WKWebView : 速度略慢一点，不过差别不大，总体可以接受。是比UIWebView更好的选择，推荐使用。

flutter_webView_plugin ：在iOS中使用的就是原生的WKWebView，所以总体和 native WKWebView 表现差不多。如果是混编项目中，因为它被包了一层，所以页面加载上存在一定的劣势，所以混编项目中仍然推荐使用 WKWebView。不过如果从多端考虑、以及项目可迁移等，那么使用也未尝不可，就是维护成本要增加一些，需要维护两套 webView。这个就需要根据自己的情况自己取舍了。

Q3: vscode里面输入flutter run什么反应都没有是什么问题？要怎么解决呢？

首先你要确定你的网络是不是通的，之前能运行说明你之前环境是好的，现在不行了，那你中途肯定是有过变动，有变动就有可能需要联网去下载（很慢会造成假死），或者是你项目里配的仓库访问不到了（比如是国外的仓库，换成阿里的试试）

Q4: Flutter 网络请求 Dio 拦截器详解

昔日的小王凭借这他的小心谨慎和借助漂亮能干的女友 Dio 的辅助，终于干下了一番事业，成为中华大地响当当的人物，小王也变成老王。如今，老王已经年近花甲，看似迈上了人生巅峰，却也遇到了人生的烦恼——那就是他的儿子，新的小王。

小王和他爹当年的小心谨慎不同，小王自海外留学回来，也不愿意接手老王的事业。反而迷恋起了互联网，玩游戏、微博喷人、撩网红等等。前两项倒还好，但是后一项，让老王心烦得很。这网红哪能随便撩的，万一弄出许多小小王来，多大家业都不够分的啊！

关键时刻，还是老王的媳妇，曾经被 金屋藏娇 的Dio 想出了新的招术，再次让老王佩服不已。老王媳妇Dio给小王搞了个拦截器，只要小王要在互联网做什么，都会被她给先拦截下来，然后她再根据小王要做的事情决定是不是要替他发出去；或者是收到什么消息的时候，也会先看一遍，没问题再给小王看。而且，最为关键的是，小王对这一切压根都不知道！

老王媳妇一开始是这么干的，小王在互联网有什么新的动向直接向老王汇报。

这下小王在互联网就完全被监视了——而且他压根不知道！只是，每次他说要钱的时候，老王不再随便给了！

但这个时候，小王还能在网上撩，毕竟上网在这个时代是不怎么要钱的。

老王媳妇 Dio 一看这种方式不行，就又心生一计，每次小王聊网红的时候，直接狠心拒绝！

小王这下子懵圈了，难道是他的那些“土味情话”已经失效了？每次发出去消息都遭受到了无情的打击，让他心灰意冷。渐渐地他就淡出了互联网，至于现在在干什么，谁也不知道。感觉又像是当初老王金屋藏娇一样，现在的小王也逐渐被隐藏了起来。从此，互联网只剩下小王和各个网红的传说。

借着老王和小王的故事，我们讲述了 Dio 的封装和 Dio 的拦截器。其中拦截器可以应用于很多实际场景：

注意，Dio 的实例可以同时添加多个拦截器，以便处理不同的情况。

Q5: flutter dio 网络请求问题

最近在做公司工业互联网的一个项目 之前做了一个ipad 版本的 在使用dio网络请求框架的时候发现请求登录的时候后台一直报签名错误问题  检查了几遍写的签名方法没有发现错误 后面仔细查了下 是服务器不能识别我传的数据。。。

如果content-type是form-data 我们需要通过FormData类来构建数据，否则服务器将无法识别

同时需要传入一个Option指明content-type，而form-data的content-type完整类型表述为：multipart/form-data

主要我是个新手啊 

查看源码 

headers里面并有multipart/form-data 这个类型啊    讲道理这个是常用的contentType啊 应该要列出来才对啊 

 咋整？

自己设置。。。。

后台就可以正常接收表单参数了