13518219792
讲道理我起的好长的名字啊，不过文如上题，搜索到这里的兄弟应该都知道我说的是啥情况，正好
为和平等地区用户提供了全套网页设计制作服务，及和平网站建设行业解决方案。主营业务为网站设计制作、网站制作、和平网站设计，以传统方式定制建设网站，并提供域名空间备案等一条龙服务，秉承以专业、用心的态度为用户提供真诚的服务。我们深信只要达到每一位用户的要求，就会得到认可，从而选择与我们长期合作。这样，我们也可以走得更远！
～～
我这个方案可能有点笨拙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
最近在开发中想实现一个AppBar下面有选项卡，来回切换的页面功能，百度了很多没有和自己需求符合的，网上大都是返回的Scaffold，使用系统的Appbar，添加至.bottom中，但是现在项目中用的是自定义的Appbar,不想破坏系统的统一封装。
所以在body 中实现TabBar 和 TabBarView，开始使用Column一直不行，只能显示一个，但是在body里面同时放置 TabBar 和 TabBarView需要注意
TabBarView 的父 Widget 必须知道宽高才能布局，否则，会报错：BoxConstraints forces an infinite height.
使用 Column + Expanded 即可：
注：还有设置tabbar的tab背景颜色，tabbar中的tab的背景颜色取的实际是AppBar的主题色，所以我们将tabbar放在Material中来重置了主题色，变成我们想要的背景色.
buildTabBar为创建TabBar的方法：
buildBodyView创建视图方法：
flutter加载h5很卡的解决方法如下：
一种临时解决方案，在切换动画加载完毕后，再去构造 WebView，这样从用户角度上看，就不会有路由切换动画的卡顿了。class WebViewPage extends StatefulWidget {undefined
final String uri;
WebViewPage({undefined
@required this.uri,
}) : assert(uri != null);
@override
_WebViewPageState createState() = _WebViewPageState();
}
class _WebViewPageState extends State {undefined
WebViewController _controller;
bool _animationCompleted = false;
@override
Widget build(BuildContext context) {undefined
// 主要是下面的代码
var route = ModalRoute.of(context);
if (route != null !_animationCompleted) {undefined
void handler(status) {undefined
if (status == AnimationStatus.completed) {undefined
route.animation.removeStatusListener(handler);
setState(() {undefined
_animationCompleted = true;
});
}
}
route.animation.addStatusListener(handler);
}
return Scaffold(
title: widget.title,
backgroundColor: Colors.white,
body: _animationCompleted
? WebView(
initialUrl: 'about:blank',
onWebViewCreated: (WebViewController webViewController) {undefined
_controller = webViewController;
_loadHtmlFromAssets();
},
)
: Container(),
);
}
_loadHtmlFromAssets() async {undefined
var uri = Uri.dataFromString(
await rootBundle.loadString(widget.uri),
mimeType: 'text/html',
encoding: Encoding.getByName('utf-8'),
).toString();
_controller.loadUrl(uri);
}
}
Fluent是目前国际上比较流行的商用CFD软件包，在美国的市场占有率为60%，凡是和流体、热传递和化学反应等有关的工业均可使用。
它具有丰富的物理模型、先进的数值方法和强大的前后处理功能，在航空航天、汽车设计、石油天然气和涡轮机设计等方面都有着广泛的应用。
FLUENT软件包含基于压力的分离求解器、基于密度的隐式求解器、基于密度的显式求解器，多求解器技术使FLUENT软件可以用来模拟从不可压缩到高超音速范围内的各种复杂流场。
FLUENT软件包含非常丰富、经过工程确认的物理模型，由于采用了多种求解方法和多重网格加速收敛技术，因而FLUENT能达到最佳的收敛速度和求解精度。
灵活的非结构化网格和基于解的自适应网格技术及成熟的物理模型，可以模拟高超音速流场、传热与相变、化学反应与燃烧、多相流、旋转机械、动/变形网格、噪声、材料加工等复杂机理的流动问题。
Flutter Dio源码分析(一)--Dio介绍
Flutter Dio源码分析(二)--HttpClient、Http、Dio对比
Flutter Dio源码分析(三)--深度剖析
Flutter Dio源码分析(四)--封装
Flutter Dio源码分析(一)--Dio介绍视频教程
Flutter Dio源码分析(二)--HttpClient、Http、Dio对比视频教程
Flutter Dio源码分析(三)--深度剖析视频教程
Flutter Dio源码分析(四)--封装视频教程
github仓库地址
本文会手把手教你该怎么去封装一个类库，平时在我们的工作中都是拿着别人的造好的轮子在使用，这篇文章将带你怎么去自己造轮子，以后再碰到别的类库需要对其进行封装的时候提供一个的思路和方法。
在前面的文章中，我们对 Dio 的基本使用、请求库对比、源码分析，我们知道 Dio 的使用非常的简单，那为什么还需要进行封装呢？有两点如下：
当组件库方法发生重要改变需要迁移的时候如果有多处地方用到，那么需要对使用到的每个文件都进行修改，非常的繁琐而且很容易出问题。
当不需要 Dio 库的时候，我们可以随时方便切换到别的网络请求库，当然 Dio 目前内置支持使用第三方库的适配器。
因为一个应用程序基本都是统一的配置方式，所以我们可以针对 拦截器 、 转换器 、 缓存 、 统一处理错误 、 代理配置 、 证书校验 等多个配置进行统一管理。
因为我们的应用程序在每个页面中都会用到网络请求，那么如果我们每次请求的时候都去实例化一个 Dio ，无非是增加了系统不必要的开销，而使用单例模式对象一旦创建每次访问都是同一个对象，不需要再次实例化该类的对象。
这是通过静态变量的私有构造器来创建的单例模式
我们对 超时时间 、 响应时间 、 BaseUrl 进行统一设置
因为不管是 get() 还是 post() 请求， Dio 内部最终都会调用 request 方法，只是传入的 method 不一样，所以我们这里定义一个枚举类型在一个方法中进行处理
我们已经把 Restful API 风格简化成了一个方法，通过 DioMethod 来标明不同的请求方式。在我们平时开发的过程中，需要在请求前、响应前、错误时对某一些接口做特殊的处理，那我们就需要用到拦截器。 Dio 为我们提供了自定义拦截器功能，很容易轻松的实现对请求、响应、错误时进行拦截
我们发现虽然 Dio 框架已经封装了一个 DioError 类库，但如果需要对返回的错误进行统一弹窗处理或者路由跳转等就只能自定义了
在我们发送请求的时候会碰到几种情况，比如需要对非open开头的接口自动加上一些特定的参数，获取需要在请求头增加统一的 token
在我们请求接口前可以对响应数据进行一些基础的处理，比如对响应的结果进行自定义封装，还可以针对单独的 url 做特殊处理等。
我们看了转换器的介绍，发现和拦截器的功能差不多，那为什么还要存在转换器，有两点：
执行流程： 请求拦截器 请求转换器 发起请求 响应转换器 响应拦截器 最终结果 。
只会被用于 'PUT'、 'POST'、 'PATCH'方法，因为只有这些方法才可以携带请求体(request body)
会被用于所有请求方法的返回数据。
在开发过程中，客户端和服务器打交道的时候，往往会用一个 token 来做校验，因为每个公司处理刷新token的逻辑都不一样，我这里举一个简单的例子
为什么我们需要有取消请求的功能，如果当我们的页面在发送请求时，用户主动退出当前界面或者app应用程序退出的时候数据还没有响应，那我们就需要取消该网络请求，防止不必要的错误。
由 服务器生成 的 一小段文本信息 ，发送给浏览器，浏览器把 cookie 以kv形式保存到本地 某个目录下的文本文件内，下一次请求同一网站时会把该 cookie 发送给服务器。
cookie 的使用需要用到两个第三方组件 dio_cookie_manager 和 cookie_jar
因为在我们平时的开发过程中，会碰到一种情况，在进行网络请求时，我们希望能正常访问到上次的数据，对于用户的体验比较好，而不是展示一个空白的页面，该缓存主要是 《Flutter实战》网络接口缓存 提供参考。
我们在程序退出后内存缓存将会消失，所以我们用 shared_preferences 进行磁盘缓存数据。
在我们用flutter进行抓包的时候需要配置 Dio 代理。由 DefaultHttpClientAdapter 提供了一个 onHttpClientCreate 回调来设置底层 HttpClient 的代理。
用于验证正在访问的网站是否真实。提供安全性，因为证书和域名绑定，并且由根证书机构签名确认。
日志打印主要是帮助我们开发时进行辅助排错
class _OpenLogListComponentState extends StateOpenLogListComponent with AutomaticKeepAliveClientMixin{
@protected
bool get wantKeepAlive=true;
//其他逻辑
}
方法二： 使用IndexedStack存储页面
_body = IndexedStack(
children: Widget[
BookHousePage(),
FunctionPage(),
ChatPage(),
MinePage()
],
index: _currentPageIndex,
);
