flutter列表优化,flutter复杂列表

Flutter 之列表和头部 （ListView + Header）

上一篇介绍Banner的开发。在大多数应用场景中。banner和ListView通常是一起显示的。 并且能够共同滑动。例如如下界面：

创新互联公司主营拉孜网站建设的网络公司,主营网站建设方案,成都App制作,拉孜h5小程序开发搭建,拉孜网站营销推广欢迎拉孜等地区企业咨询

要实现上图的界面，直接想到是ListView添加Header。但在Flutter中，ListView 组件相当于RecyclerView，所以添加Header也用RecyclerView的原理：

封装ListPage组件，list_page.dart

使用及测试：异步加载网络数据使用

flutter图片内存优化

按照给定尺寸进行图片的解码，而不是解码整个图片的尺寸，用来减少内存的占用。

官方文档：

官方说明：

Instructs Flutter to decode the image at the specified dimensions instead of at its native size.

This allows finer control of the size of the image in ImageCache and is generally used to reduce the memory footprint of ImageCache .

The decoded image may still be displayed at sizes other than the cached size provided here.

使用：

三方库： cached_network_image 限2.5.0之后版本才可用

设定最大的缓存宽度和高度 this.maxWidthDiskCache 、 this.maxHeightDiskCache

使用：

从相册选取图片，展示时使用指定尺寸宽高进行处理。

使用三方库：

使用自定义 provider 来指定所需图片的宽高：

AssetEntityImageProvider 传入宽高和图片原图 AssetEntity 数据。

provider 中 key.entity.thumbDataWithSize 方法：

进入 entity 中 thumbDataWithSize 方法：

进入 _getThumbDataWithId 方法中，

进入getThumb：

调用iOS原生的获取图片方法，

进入 getThumbWithId 方法，

原生实现获取置顶宽高缩略图方法实现：

使用 iOS 原生类 PHImageManager 的

来获取缩略图。

[Flutter Package]类iOS使用方法的SectionTableView

此控件的package我已经托管到了 pub仓库

如果你被墙住了，也可以看 国内镜像

使用方式就是在你的flutter pubspec.yaml中添加依赖：

然后flutter packages get更新依赖即可

最近写demo时发现Flutter自带的ListView widget很简陋，没有分隔线，没有section/row之分，也没有sectionHeader，如果要实现一个有分割线，有section区分，有section header的ListView，耦合会非常严重：

在 上没有找到封装好的这种TableView，于是乎决定自己写一个，命名为SectionTableView

本人是iOS开发，所以习惯了iOS上的UITableView的调用风格，所以在实现flutter的SectionTableView时，决定实现如下功能

为了实现这些功能，并且方便后期增加滚动功能，上下拉刷新功能，使用了StatefulWidget作为父类：

接着在对应的_SectionTableViewState中的build方法中，返回ListView：

熟悉flutter ListView的同学知道，ListView的builder类方法，有一个itemBuilder回调函数，参数是当前的上下文，和将要渲染的行索引index，index对应想要获取的某一行控件(cell或者叫ListItem)，返回非空的组件就证明这个index有值，返回null就表示列表到尽头了。

我们需要做的就是对index进行映射，判断当前index对应的控件，应该是列表里的section header，还是分隔线devider，还是某一行的真正内容cell。

出于性能的考虑，不可能每次调用 _buildCell的时候，都计算一遍index对应的section和row的位置，所以定义了一个类成员变量indexPathSearch，是数组，数组长度就是ListView所有的行，当 _buildCell 的参数index大于等于indexPathSearch的长度的时候，就返回null，表示列表内容到此为止了。

indexPathSearch里每一个元素，就是index对应的section和row（称为indexPath），index指向实际行(cell)的时候，section和row都是大于等于0的，当section大于等于0，row==-1的时候，表示这里是一个section header，当两者都等于-1的时候，表示这里是一个分割线：

计算好了index到indexPath的映射，剩下的就好说了，在_buildCell中，提取indexPath并判断indexPath的内容，返回对应的控件：

这是我的第一个flutter package，目前还很简陋，flutter目前尚且如此，所以大家一起改善它，

下一步将优化如下内容：

如果大家喜欢，请多多star我的 项目GitHub

Flutter 小技巧之优化你使用的 BuildContext

Flutter 里的 BuildContext 相信大家都不会陌生，虽然它叫 Context，但是它实际是 Element 的抽象对象，而在 Flutter 里，它主要来自于 ComponentElement 。

关于 ComponentElement 可以简单介绍一下，在 Flutter 里根据 Element 可以简单地被归纳为两类：

所以一般情况下，我们在 build 方法或者 State 里获取到的 BuildContext 其实就是 ComponentElement 。

那使用 BuildContext 有什么需要注意的问题 ？

首先如下代码所示，在该例子里当用户点击 FloatingActionButton 的时候，代码里做了一个 2秒的延迟，然后才调用 pop 退出当前页面。

正常情况下是不会有什么问题，但是当用户在点击了 FloatingActionButton 之后，又马上点击了 AppBar 返回退出应用，这时候就会出现以下的错误提示。

可以看到此时 log 说，Widget 对应的 Element 已经不在了，因为在 Navigator.of(context) 被调用时， context 对应的 Element 已经随着我们的退出销毁。

一般情况下处理这个问题也很简单， 那就是增加 mounted 判断，通过 mounted 判断就可以避免上述的错误 。

上面代码里的 mounted 标识位来自于 State ， 因为 State 是依附于 Element 创建，所以它可以感知 Element 的生命周期 ，例如 mounted 就是判断 _element != null; 。

那么到这里我们收获了一个小技巧： 使用 BuildContext 时，在必须时我们需要通过 mounted 来保证它的有效性 。

那么单纯使用 mounted 就可以满足 context 优化的要求了吗 ？

如下代码所示，在这个例子里：

由于在 5 秒之内，Item 被划出了屏幕，所以对应的 Elment 其实是被释放了，从而由于 mounted 判断， SnackBar 不会被弹出。

那如果假设需要在开发时展示点击数据上报的结果，也就是 Item 被释放了还需要弹出，这时候需要如何处理 ？

我们知道不管是 ScaffoldMessenger.of(context) 还是 Navigator.of(context) ，它本质还是通过 context 去往上查找对应的 InheritedWidget 泛型，所以其实我们可以提前获取。

所以，如下代码所示，在 Future.delayed 之前我们就通过 ScaffoldMessenger.of(context); 获取到 sm 对象，之后就算你直接退出当前的列表页面，5秒过后 SnackBar 也能正常弹出。

为什么页面销毁了，但是 SnackBar 还能正常弹出 ？

因为此时通过 of(context); 获取到的 ScaffoldMessenger 是存在 MaterialApp 里，所以就算页面销毁了也不影响 SnackBar 的执行。

但是如果我们修改例子，如下代码所示，在 Scaffold 上面多嵌套一个 ScaffoldMessenger ，这时候在 Item 里通过 ScaffoldMessenger.of(context) 获取到的就会是当前页面下的 ScaffoldMessenger 。

这种情况下我们只能保证Item 不可见的时候 SnackBar 还能正常弹出， 而如果这时候我们直接退出页面，还是会出现以下的错误提示，因为 ScaffoldMessenger 也被销毁了 。

所以到这里我们收获第二个小技巧： 在异步操作里使用 of(context) ，可以提前获取，之后再做异步操作，这样可以尽量保证流程可以完整执行 。

既然我们说到通过 of(context) 去获取上层共享往下共享的 InheritedWidget ，那在哪里获取就比较好 ？

还记得前面的 log 吗？在第一个例子出错时，log 里就提示了一个方法，也就是 State 的 didChangeDependencies 方法。

为什么是官方会建议在这个方法里去调用 of(context) ？

首先前面我们一直说，通过 of(context) 获取到的是 InheritedWidget ，而 当 InheritedWidget 发生改变时，就是通过触发绑定过的 Element 里 State 的 didChangeDependencies 来触发更新， 所以在 didChangeDependencies 里调用 of(context) 有较好的因果关系 。

那我能在 initState 里提前调用吗 ？

当然不行，首先如果在 initState 直接调用如 ScaffoldMessenger.of(context).showSnackBar 方法，就会看到以下的错误提示。

这是因为 Element 里会判断此时的 _StateLifecycle 状态，如果此时是 _StateLifecycle.created 或者 _StateLifecycle.defunct ，也就是在 initState 和 dispose ，是不允许执行 of(context) 操作。

当然，如果你硬是想在 initState 下调用也行，增加一个 Future 执行就可以成功执行

那我在 build 里直接调用不行吗 ？

直接在 build 里调用肯定可以，虽然 build 会被比较频繁执行，但是 of(context) 操作其实就是在一个 map 里通过 key - value 获取泛型对象，所以对性能不会有太大的影响。

真正对性能有影响的是 of(context) 的绑定数量和获取到对象之后的自定义逻辑 ，例如你通过 MediaQuery.of(context).size 获取到屏幕大小之后，通过一系列复杂计算来定位你的控件。

例如上面这段代码，可能会导致键盘在弹出的时候，虽然当前页面并没有完全展示，但是也会导致你的控件不断重新计算从而出现卡顿。

所以到这里我们又收获了一个小技巧： 对于 of(context) 的相关操作逻辑，可以尽量放到 didChangeDependencies 里去处理 。

Flutter实战：撸半个知乎日报

感谢 知乎日报-API-分析 提供的api帮助完成这个demo

该项目完全开源，单纯为了学习与交流，希望大家喜欢，多多提意见。

后续会将未来学到的新知识点用到该项目，持续更新

1.今日热点

2.主题分类

3.文章详情

4.抽屉列表增加缓存, 防止多次拉去数据

5.评论列表 (界面，动画优化)

6.主题列表 (界面，动画优化)

7.主页banner自动轮播,手指滑动是禁止轮播，放开则继续

8.刷新数据失败，增加重试按钮

9.分享UI

9.登录UI，联动交互（在评论界面可以点击写点评进入）

1.Flutter加载Html

1.注册

2.登录

3.发表评论

4.收藏

5.等等

Flutter：手把手教你使用滚动型列表组件：ListView

ListView的基础创建使用有三种方式：

通过默认构造函数来创建列表，应用场景 = 短列表

这种方式创建的列表存在一个问题：对于那些长列表或者需要较昂贵渲染开销的子组件，即使还没有出现在屏幕中但仍然会被ListView所创建，这将是一项较大的开销，使用不当可能引起性能问题甚至卡顿。

长列表

列表子项之间需要分割线

ListView的进阶使用主要包括：下拉刷新 上拉加载

在Flutter中，ListView结合RefreshIndicator组件实现下拉刷新

通过包裹一层RefreshIndicator，自定义onRefresh回调方法实现

方式有两种：

通过ListView.controller属性可以判断ListView是否滑动到了底部，再进行上拉加载

NotificationListener是一个Widget，可监听子Widget发出的Notification

ListView在滑动时中会发出ScrollNotification类型的通知，可通过监听该通知得到ListView的滑动状态，判断是否滑动到了底部，从而进行上拉加载

NotificationListener有一个onNotification属性，定义了监听的回调方法，通过它来处理加载更多逻辑

不定期分享关于 安卓开发 的干货，追求 短、平、快 ，但 却不缺深度 。