渲染不流畅？让我来看看

Skyline 下的 scroll-view 组件自带按需渲染的优化功能，但它主要是在内核层面进行的，上层可视的 DOM 节点依然会不断创建。因此，为了更好地提升渲染性能，Skyline 提供了"-builder"组件。它通过回收和创建 DOM 节点的方式，优化了按需渲染的效果。今天就让我们来为大家详细介绍一下。

-builder组件

Skyline 下我们通常使用 list-view 和 grid-view 来进行长列表布局。

但是由于目前 *-view 组件渲染时节点会不断的创建，内存占用会越来越多。于是我们新增了 *-builder 组件来支持对暂时不存在于屏幕上的节点进行回收，等到节点即将滚动到屏幕时再进行创建。

这样做有很多好处：

        1、节省内存

        2、降低节点创建的开销

        3、提升渲染性能

目前，我们提供了两个 *-builder 组件：

· list-builder：list-view 组件的 builder 模式，即列表布局容器。

· grid-builder：grid-view 组件的 builder 模式，即网格布局容器和瀑布流布局容器。

让我们来看一下效果，可以从开发者工具的 wxml 看到，当列表滚动时，list-builder 中渲染的 view 节点只有在屏的几个。

除了使用 wxml 板块查看之外，*-builder 组件还提供了监听事件，开发者可以监听列表创建和回收。

· binditembuild：列表项创建时触发，event.detail = {index}，index 即被创建的列表项序号。

· binditemdispose：列表项回收时触发，event.detail = {index}，index 即被回收的列表项序号。

使用场景

既然 *-builder 组件拥有回收+创建能力，如此强大，那是不是就可以不用 *-view 组件了？

当然不是啦～

回收+创建能力本身就是有开销的，所以也要根据业务场景按需使用：

·  *-builder：对于长列表、无限滚动列表等，或者节点内存占用高的，每个时刻都确保不会有太多节点创建出来时，使用 *-builder 可以节省内存。

· *-view：对于短列表，或者内存占用不高的列表则比较适合使用 *-view。

答疑解惑

在长列表渲染功能的实际使用中，许多开发者产生了一些疑惑：

scroll-view 下拉感觉不太流畅？list-view 有什么作用呢？关于长列表的按需渲染功能，我们如何才能检测到这个功能正确触发了呢？

下面就让我们一一来为大家解答吧。

Q1  scroll-view 下拉不太流畅？

当发现 scrll-view 下拉不够流畅时，可能是用法不对导致的不流畅。

根据 type 不同，按需渲染的用法也不同，建议按以下方式检查一下：

· type="list" : 根据直接子节点是否在屏来按需渲染。

· type="custom" : 只渲染在屏节点，对于列表、网格、瀑布流等，子节点必须包裹在 list-view、grid-view 内部才会按需渲染。

Q2  list-view 有什么作用呢？

对于 list-view、grid-view 组件，符合规定的写法则会按需渲染。

默认情况下，视口外节点不渲染。也可以根据业务需要，设置 scroll-view 的 cache-extent 属性（详见文档）来指定视口外渲染区域的距离，优化滚动体验和加载速度。

注意：cache-extent 越大也会提高内存占用且影响首屏速度，建议大家按需启用。

Q3   关于长列表的按需渲染功能，如何检测到这个功能是否正确触发？

当使用按需渲染时（例如下面使用的 type="list"），直接子节点都是一开始就创建的，所以没有办法从开发者工具检查到这个功能正常触发。

不过可以在真机上开启 “开发调试 - Debug Skyline -  checkerboardRasterCacheImages” 调试。

当滚动 view 离开屏幕回来之后颜色变了，说明节点重新渲染了，以此来确认按需渲染功能是否正确触发。

例如下图中第一个节点，一开始是紫色，当离开屏幕重新滚动回屏幕时，又变成了黄色，证明按需渲染成功。

注意：不是所有的组件都会形成 RasterCache，需要结构复杂一些才会。

那今天的介绍就到这里啦～大家还有什么疑问欢迎评论区进行留言哦。