build()方法优化
在 build() 方法中执行了耗时的操作
我们应该尽量避免在build()中执行耗时的操作,这是因为build()方法会频繁的调用,尤其是当父Widget重建的时候,所以耗时操作建议挪到 initState()这种不会被频繁调用的方法中。
另外,我们尽量不要在代码中进行阻塞式操作,可以将文件读取,数据库操作,网络请求这些操作通过Future来转成异步完成。
另外对于CPU计算频繁的操作,例如图片压缩等可以使用Iolate来充分利用多核心CPU。
build() 方法中堆砌了庞大的Widget
- 代码可读型差
因为Flutter布局方式的特殊性,画界面我们离不了的需要一个Widget嵌套一个 Widget,但如果Widget嵌套太深则会导致代码的可读型变差,也不利于后期的维护和扩展。 - 复用难
由于所有的代码都在一个 build() 方法中,会导致无法将公共的UI代码复用到其他的页面或模块。 - 影响性能
我们在State
上调用setState()
时,所有build()
中的Widget
都将会被重建,因此build()
中返回的Widget
数越大那么需要重新建的Widget
越多,对性能越不利。
列表优化方法
在构建大型网格或列表是,我们要尽量避免直接使用 ListView(children:[])
或 GridView(children:[])
,因为这种场景下回导致列表中所有的数据都会被一次性绘制出来不管列表内容是否可见,这种用法类似 Android
的 ScrollView
,建议使用 ListView.builder()
和 GridView.builder()
,两个方法只有在屏幕可见部分是在列表的内容才开始被创建,类似 Android
的 RecyclerView
替换flutter_staggered_grid_view
为flutter_nested
在使用到列表的地方替换成如下代码:
HiNestedScrollView(
controller: scrollController,
// 条目总数
itemCount: dataList.length,
// 内边距
padding: EdgeInsets.only(top: 10, left: 10, right: 10),
// 头布局
headers: [
if (widget.bannerList != null)
Padding(padding: EdgeInsets.only(bottom: 8), child: _banner())
],
//控制网格中图块的布局。
gridDelegate: SliverGridDelegateWithFixedCrossAxisCount(
crossAxisCount: 2, childAspectRatio: 0.95),
// 构建列表项
itemBuilder: (BuildContext context, int index) {
return VideoCard(
videoMo: dataList[index],
);
});