一「表」走天下，Flutter瀑布流及通用列表解决方案

2401_84149256

于 2024-05-16 04:33:39 发布

阅读量883

点赞数 10

分类专栏：程序员文章标签： flutter javascript 前端

本文链接：https://blog.csdn.net/2401_84149256/article/details/138936250

版权

程序员专栏收录该内容

294 篇文章 0 订阅

订阅专栏

void _paintWithContext(PaintingContext context, Offset offset) {

// 重新布局就不需要调整offset了.

if (_needsLayout)

return;

_needsPaint = false;

paint(context, offset);

}

Viewport通过PaintingContext间接持有Canvas进行绘制。Offset指笛卡尔坐标系下的坐标，与Axis方向无关。绘制时只需改变对应RenderObject的Offset即可实现滚动的效果, 这样就不必重新创建RenderObject。所以我们如果想实现性能较高的列表视图，就要尝试去减少重新布局Child。在对Flutter的列表布局有了基本了解后，我们再来看瀑布流的实现过程。

瀑布流的实现逻辑

WatetfallFlow的布局过程中需要指定Child的Offset，然后对其进行布局。所以需要继承SliverMultiBoxAtaptor，依赖于其将SliverConstraints转换为BoxConstraints的能力。我们也可以使用其SliverBoxChildManager, 方便控制Child的懒加载过程。

▐ 核心逻辑

在瀑布流中由于同一行（列）的child（大多）具有先后关系，需要按照顺序来进行布局，所以瀑布流相比于GridView更类似于ListView，而瀑布流的布局过程也借鉴了ListView。整个瀑布流的布局逻辑围绕三个核心展开：

在滑动的过程中找到其边缘最近的child，在其后（前）进行添加child，并对child进行layout。
在child离开一定距离后进行GC。
保证layout方法被尽可能少的调用. 上文有提过layout会调用performLayout而不能直接进行paint。

其中核心的数据结构是ParentData。

ParentData位于Child中，Child将其传递给Sliver，Sliver又将其传递至上层，其中储存了全部的布局信息（在笛卡尔坐标系下）。在performLayout中，child在调用layout时所使用的布局信息就来自ParentData。在Child的添加过程中，用一个Manager存储前后边缘所有Child的ParentData，在添加时寻找边缘最靠近可见区域的Child，对其ParentData进行设置并替换当前Child。

布局的核心逻辑为对从最开始的Child（对应firstIndex）到最末的Child（对应targetLastIndex）进行布局。如果_layoutedChilds中已经有记录，则跳过其布局过程。

for (int index = firstIndex; index <= targetLastIndex; ++index) {

final SliverGeometry gridGeometry = layout.getGeometryForChildIndex(index);

final BoxConstraints childConstraints = gridGeometry.getBoxConstraints(constraints);

RenderBox child = childAfter(trailingChildWithLayout);

if (child == null || indexOf(child) != index) {

// 重新获取Child.

child = _createAndLayoutChildIfNeeded(childConstraints, after: trailingChildWithLayout);

if (child != null && indexOf(child) == index) {

_layoutedChilds.add(index);

}else if (child == null) {

// Child已经用尽.

break;

}

} else {

if (!_layoutedChilds.contains(index)) {

_layoutChildIfNeeded(child, parentUsesSize: true);

_layoutedChilds.add(index);

}

trailingChildWithLayout = child;

}

对离开视图的child进行GC，同时记得将数组中的child清除。

if (firstChild != null) {

// 上一次的最先最末Child.

final int oldFirstIndex = indexOf(firstChild);

final int oldLastIndex = indexOf(lastChild);

// 前后需要GC的child数量

final int leadingGarbage = (firstIndex - oldFirstIndex).clamp(0, childCount);

final int trailingGarbage = targetLastIndex == null

? 0 : (oldLastIndex - targetLastIndex).clamp(0, childCount);

// GC

collectGarbage(leadingGarbage, trailingGarbage);

_layoutedChilds.sort();

_layoutedChilds.removeRange(0, leadingGarbage);

_layoutedChilds.removeRange(layoutedChilds.length - 1 - trailingGarbage,

layoutedChilds.length - 1);

} else {

collectGarbage(0, 0);

}

在开发过程中出现了帧数偏低的问题，发现是Child在performLayout的过程中会出现重复布局。解决方法是我们不仅记录leading, trailing边缘的child。而且用对已经layout过的child进行记录，粗暴直接但是有效，这样做也可以提供单独update单个child的Layout能力。在更新Child的布局时也只需从记录中将对应child移除。

相比于原生视图，我们可以通过获取所有Child的ParentData信息，可以为上层接口提供实时并且有效的回调.。这样就可以根据每个Child的实时位置来提供生命周期，曝光打点的能力。所以可以对每个child的坐标进行监听，从而获得精准的曝光信息。

从瀑布流到容器

在瀑布流的开发过程中也暴露出了一些设计上的问题。比如瀑布流的具体渲染逻辑都在RenderObject中进行，太过底层显然是不利于业务方根据业务进行定制。又比如由于没有复用的机制，在视图层级较为复杂时帧数会由于重复渲染而不可避免的降低。

借鉴native思路重新设计后将整体容器分为3个部分进行设计。

▐ delegate

主要管理child生命周期并响应手势，由于我们可以得到每个可见Child的parentData属性，所以可在滚动时进行实时的通知。从而对每个Child的位置监听，从开始创建到进入缓冲区，到从缓冲区进入可见区域。手势则来自于顶层的Scrollable。

▐ layout

主要负责布局所有的Child。将具体的布局逻辑抽离出，类似于iOS中的UICollectionViewLayout。但是在开发过程中也出现了一些问题，原因主要来自于Flutter特殊的信息传递方式，就是我们不能采用native的方式一次性计算出所有child的布局。因为RenderBox需要接收一个BoxConstraints才能返回一个size。