包含flutter实例的词条

Flutter Dio源码分析(四)--封装

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 的代理。

用于验证正在访问的网站是否真实。提供安全性，因为证书和域名绑定，并且由根证书机构签名确认。

日志打印主要是帮助我们开发时进行辅助排错

相关问答

Q1: Flutter中的StatefulWidget及其生命周期

状态可变的 widget 。

通过其类的定义能够看到 StatefulWidget 配置 StatefulElement 。

State 是 StatefulWidget 的内部逻辑与状态，由 StatefulWidget 的 createState 创建。

StatefulWidget 实例本身是不可变的， 但是 StatefulWidget 将其可变的状态，存储在与之关联的 State 对象中。

不管什么时候，只要在树中 mount 一个新的 StatefulElement ，必然需要注入一个 StatefulWidget ，注入一个 StatefulWidget 时， framework 都会调用一次 createState 方法。

其实，在 StatefulElement 构造的时候，就会调用 createState ，创建 _state 对象，（ _state 是 StatefulElement 的变量）并且在 StatefulElement 的初始化方法中为 _state 关联当前的 StatefulElement 和用以配置 StatefulElement 的 StatefulWidget 。

StatefulElement 初始化方法如下：

这意味着如果 StatefulWidget 被插入到树中的多个位置，则会有多个 State 对象分别与它们关联。

关于此类的定义如下：

描述： 重写此方法以执行初始化。

场景： 如果 State 的 build 方法依赖于本身可以改变状态的对象时。（例如 ChangeNotifier 或 Stream ，或者可以订阅并接收通知的其他对象）正确的方式是：

注意点： 此方法中不能使用 BuildContext.dependOnInheritedWidgetOfExactType 。但是此方法被调用后会立即调用 didChangeDependencies ，在 didChangeDependencies 可以使用 BuildContext.dependOnInheritedWidgetOfExactType 。

调用时机： StatefulElement ，首次插入树中时会调用此方法，在 build 方法调用之前调用。

描述： StatefulElement 通过此方法返回的 widget 并通过调用 updateChild 来更新自己。

调用时机： framework 调用此方法的几个不同的场景如下：

描述： StatefulElement 存在，并且符合 Widget.canUpdate 的情况下对 StatefulWidget 进行更新。

调用时机： 不论何时只要 StatefulElement 的配置 widget 改变的时候就会调用。

注意： didUpdateWidget 方法最终会调用 build 方法，因此在此方法中调用 setState 是多余的。如果重写此方法，请确保调用 super.didUpdateWidget(oldWidget) 。

调用时机： 当此 State 对象的依赖项（ InheritedWidget ）更改时调用。

描述： 用于开发阶段 hot reload 。

调用时机： hot reload 时调用，调用后 build 方法也将被调用。无需在此方法中做任何操作。

调用时机： 当 StatefulElement 从树中移除的时候会调用。

调用时机： 当 StatefulElement 从树中 unmount 的时候会调用。

StatefulWidget 用以配置 StatefulElement ，但在这两者之间的 State 承接了 StatefulElement 的生命周期，而 StatefulWidget 仅仅只是连接了 State 与 StatefulElement 的不可变的实例，因此 StatefulWidget 的生命周期，依赖于 StatefulElement ，而 State 却是其最简单直接的体现形式。

为了能更好的理解 StatefulWidget 的生命周期，我画了一张关于 State 、 StatefulElement 、 Component 、 Element 的关系图。

Q2: Flutter 6种构造函数详解

Flutter有生成构造函数、默认构造函数、命名构造函数、重定向构造函数、常量构造函数、工厂构造函数

生成构造函数是最常见的构造函数，即生成实体类对象。

如果未声明构造函数，则会提供默认构造函数。 默认构造函数没有参数，并调用父类无参数构造函数。

默认情况下，子类中的构造函数调用父类的未命名无参数构造函数。 父类的构造函数在子类构造函数体的开头被调用。 如果还使用初始化了列表，则会在调用父类构造函数之前执行。 执行顺序如下：

如果父类没有未命名的无参数构造函数，则必须手动调用父类中的一个构造函数。 在子类的构造函数体之后用冒号(:)指定父类构造函数

当需要定义一个有特别含义的构造函数的时候，可以通过命名构造 形式：构造函数.XXX来命名构造函数

有时构造函数需要重定向到同一个类中的另一个构造函数，在冒号后面用this：

如果你的类需要成为永远不会更改的对象，则可以使这些对象成为编译时常量。 定义const构造函数要确保所有实例变量都是final。

不用直接创建对象（可以通过调用其他构造函数创建）

Q3: Flutter中InheritedWidget的使用

在Tree中从上往下高效传递数据的基类widget , 定义为:abstract class InheritedWidget extends ProxyWidget

Flutter的响应式开发与React类似，数据都是自顶向下的。

假设有祖先组点A，中间经过结点B, C，然后到结点D，D需要从A中获取数据f，那按照自顶向下数据流转，f需要依次传递给B及C，最后才到C。这样开发极为不灵活，成本也比较高。所有Flutter需要有跨结点(只能是祖先后代节点，不能跨兄弟节点)高效传递数据的方案。

大体意思如下:

InheritedWidget 是在树中高效向下传递信息的基类部件；

调用[BuildContext.inheritFromWidgetOfExactType]方法可以从 BuildContext 中获取到最近的 InheritedWidget 类型的实例；

在 InheritedWidget 类型的控件被引用,也就是调用过 inheritFromWidgetOfExactType 方法后,当 InheritedWidget 自身状态改变时，会导致引用了 InheritedWidget 类型的子控件重构(rebuild)。

这里随便定义一个人 Person 类。

创建一个类继承 InheritedWidget，并实现 updateShouldNotify 方法。

之前说到调用[BuildContext.inheritFromWidgetOfExactType]方法可以从 BuildContext 中获取到最近的 InheritedWidget 类型的实例，所以此处定义一个静态的 of 方法，通过传入的 context 获取到最近的 InheriedDataWidget 实例。

1.定义数据模型

这里随便定义一个 Person 类。

2.自定义 InheritedWidget 控件类

创建一个类继承 InheritedWidget，并实现 updateShouldNotify 方法。

之前说到调用[BuildContext.inheritFromWidgetOfExactType]方法可以从 BuildContext 中获取到最近的 InheritedWidget 类型的实例，所以此处定义一个静态的 of 方法，通过传入的 context 获取到最近的 InheriedDataWidget 实例。

3.InheriedDataWidget 的使用

InheriedDataWidget 使用起来也很简单，它本身也是一个控件，只要在任意一个页面的子控件调用其构造方法就行，这里我们定义一个形如的 Widget 树。

WidgetA 是一个 StatefulWidget 类型的控件，可以调用 setState 刷新，如果是继承人 Stateless 类型的控件,那我们也可以通过 Stream 或者其他方式刷新数据，感兴趣的请看[什么是 Stream? Dart

WidgetA1_1 类

WidgetA1_2 类

WidgetA1_3 类

当我们点击 floatingActionButton 的时候，WidgetA1, WidgetA1_1， WidgetA1_2 的控件都会更新 Person 的信息，而且每点 floatingActionButton 一次， 当我们点击 floatingActionButton 的时候，WidgetA1, WidgetA1_1， WidgetA1_2 的控件都会更新 Person 的信息，而且每点 floatingActionButton 一次，都会输出：

如果我们试图在和 WidgetA 的同一层级的兄弟节点去访问 InheriedDataWidget 的 Person 数据，是不行的，因为父节点中并没有插入 InheriedDataWidget。

把 WidgetB 和 WidgetA 保持同一节点

这也体现了 Inheried(遗传) 这一单词的特性，遗传只存在于父子。兄弟不存在遗传的关系。

这种数据共享的方式在某些场景还是很有用的，就比如说全局主题，字体大小，字体颜色的变更，只要在 App 根层级共享出这些配置数据，然后在触发数据改变之后，所有引用到这些共享数据的地方都会刷新，这换主题，字体是不是就很轻松，事实上 Theme.of(context).primaryColor 之流就是这么干的。

以上就是有关InheritedWidget的使用。

自己也是从事Android开发5年有余了；整理了一些Android开发技术核心笔记和面经题纲，有关更多Android开发进阶技术资料、面经题纲、核心技术笔记； 想要进阶自己、拿高薪的同学请私信我回复“核心笔记”或“面试”领取！