flutter全局存储,flutter本地存储

Flutter 之 文件操作（二十九）

Dart的 IO 库包含了文件读写的相关类，它属于 Dart 语法标准的一部分，所以通过 Dart IO 库，无论是 Dart VM 下的脚本还是 Flutter，都是通过 Dart IO 库来操作文件的，不过和 Dart VM 相比，Flutter 有一个重要差异是文件系统路径不同，这是因为Dart VM 是运行在 PC 或服务器操作系统下，而 Flutter 是运行在移动操作系统中，他们的文件系统会有一些差异。

站在用户的角度思考问题，与客户深入沟通，找到安图网站设计与安图网站推广的解决方案，凭借多年的经验，让设计与互联网技术结合，创造个性化、用户体验好的作品，建站类型包括：成都网站设计、网站建设、企业官网、英文网站、手机端网站、网站推广、域名注册、网络空间、企业邮箱。业务覆盖安图地区。

Android 和 iOS 的应用存储目录不同， PathProvider 插件提供了一种平台透明的方式来访问设备文件系统上的常用位置。该类当前支持访问两个文件系统位置：

File代表一个整体的文件,他有三个构造函数，分别是：

文件读取本身有两种形式，一种是文本，一种是二进制。

2.2.1 读取文本内容

如果是文本文件，File提供了readAsString、readAsLines、readAsStringSync、readAsLinesSync方法，读取文本内容

readAsString 一次性读取所有文本

readAsLines 一行行的读取文本

结果返回的是一个List，list中表示文件每行的内容

readAsStringSync、readAsLinesSync同步读取文本

2.2.2 读取二进制内容

如果文件是二进制，那么可以使用readAsBytes或者同步的方法readAsBytesSync:

dart中表示二进制有一个专门的类型叫做Uint8List,他实际上表示的是一个int的List。

上面提到的读取方式，都是一次性读取整个文件，缺点就是如果文件太大的话，可能造成内存空间的压力。

所以File为我们提供了另外一种读取文件的方法，流的形式来读取文件.

示例

dart提供了open和openSync两个方法来进行随机文件读写：

写入和文件读取一样，可以一次性写入或者获得一个写入句柄，然后再写入。

一次性写入的方法有四种，分别对应字符串和二进制

句柄形式可以调用openWrite方法，返回一个IOSink对象，然后通过这个对象进行写入：

默认情况下写入是会覆盖整个文件的，但是可以通过下面的方式来更改写入模式：

虽然dart中所有的异常都是运行时异常，但是和java一样，要想手动处理文件读写中的异常，则可以使用try,catch:

我们还是以计数器为例，实现在应用退出重启后可以恢复点击次数。 这里，我们使用文件来保存数据：

1.引入PathProvider插件；在pubspec.yaml文件中添加如下声明：

执行 flutter pub get

2.实现如下

参考：

iOS开发Flutter探索-State状态保存(10)

有时候我们不希望某个页面每次打开时都重新加载，比如就我们之前的Tabbar结构的页面，每当我们在切换Tab的时候都会执行 void initState() ，这就意味着页面每次都会重新渲染，之所以这样就是因为我们的 State 状态没有保存，如下图所示：

[没有状态保存效果图]

给当前 State 类添加一个扩展(这里就用扩展这个词吧，其实类似于iOS下的 Category )，一个系统的扩展类 AutomaticKeepAliveClientMixin ，并重写 wantKeepAlive 方法，让一个普通的 State 类，具有保存状态的能力。

在Dart语法中通过使用 with 关键字来添加扩展：

bool get wantKeepAlive = true; 之后，当前 State 就具备保存能力了，也就意味着重复切换Tab后， void initState() 就不会重复执行了（由原来的 viewWillAppear() 变成了 viewDidLoad() ）。

按照上面方式修改后，发现切换Tab后 void initState() 依然重复执行了，这是为什么呐？这里我们看下我们之前 root_page.dart 里面是如何配置我们的tabbar结构的：

这里我们是通过一个 _viewControllers 的List，把4个子页面放在了里面，全局有一个 _currentIndex ，当 onTap 回调后后，更新 _currentIndex 的值，执行 setState () 后， body 对应的 widget 页面发生改变。而问题也就出在这里，当 body 部分发生改变时，根据Flutter的底层渲染逻辑，这里会移除掉之前的 Widget ，并重新创建新的 Widget ，我们之前在 _viewControllers 放的子页面，并不像iOS下是一个实例对象，存在就直接拿来使用。在Flutter 中 setState () 后界面会被重新绘制，而 body 部分只知道我要渲染一个什么样的 widget ，而该类型的 widget 每次都是会重新创建，这也就意味着我们在Tab切换时，每次都是重新创建，所以每次都执行了 initState() 。

显然我们现在的方式是不合理的，那在Flutter中如何管理这样的子页面，而避免重复渲染呐？

这就要用到一个新的部件了： PageView() ,内部的2个关键属性：

子页面切换通过 _controller.jumpToPage(index); 来实现。

这样子页面也就不会重新创建渲染了，我们的状态保存也就能正常实现了。

学习是一个循序渐进的过程，我们总是在踩坑中不断的前行，把坑填平了也就意味着我们在这个新的东西面前立了足，就可能进行更多为什么的探索了。

Flutter_定义控件StatefulWidgets和StatelessWidget

Stateful（有状态） 和 stateless（无状态） widgets

stateless widget 没有内部状态. Icon、 IconButton, 和Text 都是无状态widget, 他们都是 StatelessWidget的子类。

stateful widget 是动态的. 用户可以和其交互 (例如输入一个表单、 或者移动一个slider滑块),或者可以随时间改变 (也许是数据改变导致的UI更新). Checkbox, Radio, Slider, InkWell, Form, and TextField 都是 stateful widgets, 他们都是 StatefulWidget的子类。

StatefulWidget类

具有可变状态的小部件。

状态是（1）在构建窗口小部件时可以同步读取的信息，以及（2）在窗口小部件的生命周期内可能会更改的信息。这是小工具实施者的责任，以确保国家的及时通知当这种状态的改变，使用State.setState。

有状态窗口小部件是一个窗口小部件，它通过构建一个更具体地描述用户界面的其他窗口小部件来描述用户界面的一部分。构建过程以递归方式继续，直到用户界面的描述完全具体（例如，完全由RenderObjectWidget组成，其描述具体的RenderObject）。

当您描述的用户界面部分可以动态更改时（例如由于具有内部时钟驱动状态或依赖于某些系统状态），状态窗口小部件非常有用。对于仅依赖于对象本身中的配置信息以及窗口小部件膨胀的 BuildContext的组合，请考虑使用 StatelessWidget。

StatefulWidget实例本身是不可变的，并且将它们的可变状态存储在由createState方法创建的单独State对象中 ，或者存储在State订阅的对象中，例如Stream或ChangeNotifier对象，其引用存储在StatefulWidget的最终字段中本身。

框架在膨胀StatefulWidget时 调用createState，这意味着如果该窗口小部件已插入到多个位置的树中，则多个State对象可能与同一StatefulWidget关联。同样，如果StatefulWidget从树中移除，后来在树再次插入时，框架将调用createState再创建一个新的国家目标，简化的生命周期状态的对象。

如果StatefulWidget的创建者使用GlobalKey作为其 键，则StatefulWidget在从树中的一个位置移动到另一个位置时保持相同的State对象。由于具有GlobalKey的窗口小部件可以在树中的至多一个位置使用，因此使用GlobalKey的窗口小部件最多只有一个关联元素。当通过将与该窗口小部件关联的（唯一）子树从旧位置移植到新位置（而不是在该位置重新创建子树）时，框架利用此属性将全局键从树中的一个位置移动到另一个位置时利用此属性。新的位置）。与StatefulWidget关联的State对象与子树的其余部分一起被移植，这意味着State对象在新位置被重用（而不是被重新创建）。但是，为了有资格进行嫁接，必须将窗口小部件插入到从旧位置移除它的同一动画帧中的新位置。

StatefulWidget有两个主要类别。

首先是其中一个分配资源State.initState并在他们的处置State.dispose，但不依赖于InheritedWidget S或致电State.setState。这些小部件通常在应用程序或页面的根目录中使用，并通过ChangeNotifier， Stream或其他此类对象与子小部件进行通信。遵循这种模式的有状态小部件相对便宜（就CPU和GPU周期而言），因为它们构建一次然后永不更新。因此，它们可能有一些复杂和深刻的构建方法。

第二类是使用State.setState或依赖于 InheritedWidget的小部件。这些通常会在应用程序的生命周期内重建多次，因此最小化重建此类窗口小部件的影响非常重要。（他们也可以使用State.initState或 State.didChangeDependencies并分配资源，但重要的是他们重建。）

可以使用几种技术来最小化重建有状态窗口小部件的影响：

StatelessWidget类

一个不需要可变状态的小部件。

无状态窗口小部件是一个窗口小部件，它通过构建一个更具体地描述用户界面的其他窗口小部件来描述用户界面的一部分。构建过程以递归方式继续，直到用户界面的描述完全具体（例如，完全由RenderObjectWidget组成，其描述具体的RenderObject）。

当您描述的用户界面部分不依赖于对象本身的配置信息以及窗口小部件膨胀的BuildContext时，无状态窗口小部件非常有用。对于可以动态更改的组合，例如由于具有内部时钟驱动状态或依赖于某些系统状态，请考虑使用StatefulWidget。

无状态窗口小部件的构建方法通常仅在以下三种情况下调用：第一次将窗口小部件插入树中，窗口小部件的父窗口更改其配置时，以及何时依赖于更改的InheritedWidget。

如果窗口小部件的父级将定期更改窗口小部件的配置，或者它依赖于经常更改的继承窗口小部件，则优化构建方法的性能以保持流畅的呈现性能非常重要。

可以使用几种技术来最小化重建无状态窗口小部件的影响：

flutter provider的理解

provider 是flutter 中的状态管理 开源库;

存储的数据对象 必须extends ChangeNotifier；下层widget 通过 Provider.of(context) 函数 获取model对象 ,并且可以建立依赖关系；当数据对象发生变化时，依赖的widget 会重新build，像不像InheritedWidget Provider 没错 下层widget就是 封装了InheritedWidget

主要 通过 Provider.ofT(context) 函数，来获取；

推荐使用 Provider.of而不是 Consumer,因为 listen默认为true,也就是说 默认 依赖于 持有数据model的widget 对应的element;

数据类 可继承的 ChangeNotifier,本身和privider框架 没有关系；

ChangeNotifier 是 flutter框架 提供的工具类， 用来实现一对多的订阅通知功能。

第十六章：Flutter数据存储

Flutter的数据存储分为三类

Preference相当于iOS的NSUserDefaults,其实也是按plist的方式存储的

step1:添加依赖

step2:pub get

step3:导入头文件

在path_provider中有三个获取文件路径的方法：

- getTemporaryDirectory()

://获取应用缓存目录，等同iOS的NSTemporaryDirectory()和Android的getCacheDir() 方法。

- getApplicationDocumentsDirectory():

//获取应用文件目录类似于iOS的NSDocumentDirectory和Android上的 AppData目录。

step1:添加依赖

step2:pub get

step3:导入头文件

Flutter全局状态管理机

需求：

· 在我的界面，展示了用户信息姓名、年龄、性别等信息

· 我的界面有一个设置按钮，可以修改这些用户信息

· 修改之后怎么刷新呢？

· 这时候就使用到全局状态管理

eg：

访问数据⏬

更新数据⏬

/// 在需要更新或者获取全局状态时候需要获取到store ⏬

/// 点击事件 更新全局状态 1、创建对象 2、调用更新方法⏬

/// 哪里需要使用全局状态，就在最外面new StoreBuilder⏬

Flutter完整开发实战详解

Dio网络请求

UI界面