这是领苗确认记录详情页需要展示给用户的内容，大家可以看到这个页面要承载很多的信息，要向下滚动一段很长的距离才能展示完，想要实现的效果是在页面的顶部有一个TabBar，用户可以通过点击TabBar进行锚点(jumpTo到指定位置)，AppBar下的整个页面是可以自由滚动的，在滚动过程中AppBar始终固定在顶部，TabBar在第一次进入详情页的时候不显示，只有在向下滑动的时候会由透明渐变为不透明并固定在顶部，同时当页面滑动到TabBar锚点位置的时候TabBar会切换到对应的下标，也就是要实现TabBar和ScrollView联动的双向控制，Tabbar的切换可以控制页面的跳转，页面的滑动又可以反过来控制TabBar的切换，类似与京东、淘宝的商品详情页效果。
创新互联建站是专业的怀仁网站建设公司，怀仁接单;提供成都网站制作、网站设计,网页设计,网站设计,建网站,PHP网站建设等专业做网站服务;采用PHP框架,可快速的进行怀仁网站开发网页制作和功能扩展;专业做搜索引擎喜爱的网站,专业的做网站团队,希望更多企业前来合作!
SliverAppBar基本已经达到了我们想要的效果，但在界面顶部会有块空白区域试了很多方法怎么都去不掉，最后看了SliverAppBar这个控件的源码发现是它自带的初始高度。
这个没法设置或消除，不可能直接去改源码，所以后来换了一种实现思路，舍弃了SliverAppBar这个控件，以Stack的形式将TabBar置于ScrollView之上也能达到我们想要的效果，那么问题来了，如何实现TabBar的滚动渐变？很容易想到Opacity透明度控件，通过滚动监听来控制TabBar透明度的改变，借助Notificaion可以完美实现我们的需求。
Notification是Flutter中一个重要的机制，在Widget树中，每一个节点都可以分发通知（Notification）与父(包括祖先)Widget通信，通知会沿着当前节点（context）向上传递，所有父节点都可以通过NotificationListener来监听自己关注的通知，Flutter中称这种通知由子向父的传递为“通知冒泡”（Notification Bubbling）。
Flutter中很多地方使用了通知，如可滚动(Scrollable) Widget中滑动时就会分发ScrollNotification，而Scrollbar正是通过监听ScrollNotification来确定滚动条位置的。除了ScrollNotification，Flutter中还有SizeChangedLayoutNotification、KeepAliveNotification 、LayoutChangedNotification等。
通过NotificationListener监听滚动事件和通过ScrollController有两个主要的不同：
通过改造后，目前这个组件的原型已经实现并且可以满足我们的需求，最后就是对该demo进行完善使其能够完美接入我们的业务，做到技术赋能业务。
在一个页面滚动区域不是很长的情况下不建议使用，只有当页面足够长的情况下使用这个组件效果会比较好，因为如果一个页面过短，点击TabBar最后一栏进行锚点时，页面最后一个子模块内容无法置顶，只会将页面最后的内容推到屏幕范围内，并且由于TabBar监听到的是滚动的位置，会导致TabBar无法切换到对应的下标，看上去会像个bug，其实是因为底部已经没有内容了。
这个组件本身并没有太大的技术难度，但是有一些比较细节的小逻辑得处理好，并且从中衍生出来的很多琐碎的小的知识点都可以进行拓展。 在组件开发的过程中遇到问题时不局限于控件本身的设计模式，转变开发思维去找寻一些比较新颖的解决方案可能会有意外的收获。同时技术不能脱离于业务，技术赋能业务才能创造价值。
腾讯课堂14M
今日头条3M
闲鱼22M
百度贴吧13M
蚂蚁财富56.8M
百度网盘14M
手机淘宝15M
贝壳找房8M
由粗粒度小组件动态拼装出页面，Native端已经有很多成熟的框架，如天猫的Tangram。
开发语言：iOS、Android
适用场景：快速迭代的活动营销页面
优点：无侵入，更新简单
缺点：提前预埋，扩展性差，灵活性差
以webview作为容器的app，历史悠久，最早到2011年。
开发语言：HTML
适用场景：双端严格一致的银行类app，容器类的支付宝小程序等
优点：动态更新，跨平台
缺点：性能，加载速度
UI用Xml+JS表达，用Native View渲染。
开发语言：Xml+JS
适用场景：双端严格一致的银行类app，容器类的支付宝小程序等
优点：native组件，生态成熟
缺点：三方库crash，性能缺陷
UI用Dart表达，用Dart engine渲染。
Flutter官方不支持动态化。原因是Flutter在 Release 模式下构建的是 AOT 编译产物，在 Debug 模式下构建的是 JIT ，AOT 依赖的 Dart VM 和 JIT 并不一样， JIT Release 并不支持 iOS 设备。可行的方案是：AOT 需要一个编译后的 “Dart VM”。抽离一份 DartVM 独立编译，再以动态库的形式引入项目。
开发语言：Dart
适用场景：iOS、Android、Web、Desktop、Embed
优点：性能最佳
缺点：增大包体积 20MB+
大厂的主流方案。UI用JS表达，用Dart engine渲染。
开发语言：JS、类JS
适用场景：iOS、Android
优点：性能最佳
缺点：需要掌握JS、Dart两个语言和框架
大厂的主流方案。UI用Dart表达，用Dart engineX渲染。
开发语言：Dart
适用场景：iOS、Android
优点：性能最佳
缺点：需要改造Dart engine
1、 美团外卖Flutter动态化实践
2、 携程App 首页动态化探索
3、 Flutter 动态化在最右 App 中的实践
4、 Flutter 动态化热更新的思考与实践
5、 NOW直播Flutter动态搜索列表页实现
6、 Flutter动态化的方案对比及最佳实现-闲鱼
7、 基于JavaScript 的MXFlutter
这是个产假作业。故事是这样的。
生了娃，生活一地鸡毛。擦，碎钞机的需求怎么那么多。
当时，有一堆返利优惠券app比较火
...这里扯多了这篇文章被锁了....
我就想，来扒一扒，他们是怎么赚钱的。
结论：淘宝联盟。
淘宝联盟是阿里巴巴旗下的亲儿子，不那么有名是因为是个私生子吧，官网上还有个没听过的名号叫“阿里妈妈”，呵呵。淘宝联盟是给淘宝上推广商品的人用的，他们有一个专门的名称，叫做淘宝客，即“推广者（Publisher）”，他们帮电商平台推荐商品给别的买家，买家购买后，电商平台可以增加销量，而他们则可以获得推广佣金。
后来，知道京东也有自己的联盟平台，叫做“京东联盟”，拼多多也有，叫做“多多进宝”。
回到这些app的赚钱逻辑上来。对于用户而言，它们的两个噱头是：
“用我们的app买，你可以自用省钱”
“用我们的app，分享给别人下单，你可以赚钱！”
所以，这些app推广起来很容易啊，因为谁用谁赚钱呀！
那么为何不自己搭一个呢？
与其这些佣金落到别人口袋，不如自己直接做最顶层上线，发展出N个下线，岂不是躺着赚钱，哈哈哈哈哈
搞清楚赚钱逻辑之后，我发现淘宝联盟的api是很开放的。
商品链接： ;pid=mm_343780171_368000361_101527600308itemId=595640102734src=qtka_wxxtdx=1
其中，activityId是优惠券id，pid是推广者在阿里妈妈官网注册的id，只有这个id是我注册的，那么佣金就到我口袋去了，哈哈哈。
刚好练一下flutter，一次开发，两端使用，我一个人就可以了。app暂时取名为“小猪购”，拿粉红猪贴牌。
演示视频：
本文对比的是 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。这个就需要根据自己的情况自己取舍了。
Uniapp目前比较成熟，而且用的是Vue语法，学习成本比较低，而且行业里面用的也比较广泛，而Flutter的话，学习成本略高，因为要学习新的语言，还有就是目前生态不是特别完备，等他再发展发展吧。黑马程序员官网有成套免费视频哦，有什么不懂的可以直接过去学习。您的采纳是对我成长的鞭策
