Taobao FED

使用 JS 构建跨平台的原生应用:ListView 组件介绍

使用 JS 构建跨平台的原生应用:ListView 组件介绍

背景

滚动列表 几乎是移动开发中用途最广的 UI 组件,其重要性不言而喻。由于平台差异性,React Native 中的滚动列表组件 ListView 并没有直接映射为 Android 中的 ListView 或 iOS 中的 UITableView,而是在 ScrollView 的基础上使用 JS 做了一次封装。这样,滚动体验部分由 Native 负责,而 React 部分则专注于组件何时渲染、如何渲染等问题。

ListView 的基本设计原则是 “数据和展现相隔离” ,如下图所示。给我们带来的好处就是,我们只需关注数据的组织方式,任何对数据的操作都会自动渲染出对应的展现。

数据

ListView 在创建时需要绑定数据源,类似于 Android 中的 Adaptor。数据源内部保存了展现需要的初始数据 _dataBlob ,它是一个纯粹的对象或数组。列表可以带 SectionHeader (即列表中某一段的标题部分)也可以不带,本质上相同。数据源默认的格式有三个维度:

  • 第一个维度是 sectionId ,标识属于哪一段, 可以手动指定或隐式地使用数组索引或对象的 key 值;
  • 第二个维度是 rowId ,标识某个数据段下的某一个行,同样可以手动指定或隐式地使用数组索引或对象的 key 值;
  • 第三个维度是具体的数据对象,根据实际的需要而定。

需要注意的是,上面只是 默认的数据格式,如果它不符合实际的需求, 完全可以使用自定义的数据结构 。唯一的区别就是需要额外指定给 ListView 数据源中哪些是 id,哪些是 rowData。

DataSource 的构造函数接收以下几个参数:

  • rowHasChanged: 用于在数据变化的时候,计算出变化的部分,在更新时只渲染脏数据;
  • sectionHeaderHasChanged: 同理,在列表带分段标题时需要实现;
  • getRowData/getSectionHeaderData: 如果遵循默认的数据源格式,这两个方法就没有必要实现,用内部默认的即可;而当数据源格式是自定义时,需要手动实现这两个方法。

如文档中一般介绍的那样,DataSource 的初始化一般在 getInitialState 方法中:

1
2
3
4
5
6
getInitialState: function() {
var ds = new ListView.DataSource({rowHasChanged: (r1, r2) => r1 !== r2});
return {
dataSource: ds.cloneWithRows(['row 1', 'row 2']),
};
}

在初次见到这种写法时,心中其实疑惑这里为什么不一次性把整个对象 new 出来,而要拆分为两步?

首先,如前所述,DataSource 的构造函数里的参数只有四个,并不能直接传入数据对象。其次,一个页面中的滚动列表常常要不时修改数据,比如:

  • 边滚动边添加列表元素;
  • 展现搜索结果时,当搜索条件变化后,列表对应的数据对象需要重置;
  • 对列表中的结果进行筛选、排序等操作。

在这些情况下,数据源需要做调整,但上述写法可以使得我们在调整时,无需重新定义 rowHasChanged 等比较函数,只需变化真实的数据对象即可。

展现

基本用法

数据源确定后,下一个工作就是列表的渲染。在渲染时发挥重要作用的是 renderRow 属性,它接收数据源中保存的数据对象,并通过返回值确定该行该如何进行展现。我们可以对所有行统一进行展现,也可以根据里面的字段做出不同的展现。在列表包含 sectionHeader 时,还需要实现 renderSectionHeader 方法。一个简单的例子如下:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
var postDemo = React.createClass({
getInitialState: function() {
var ds = new ListView.DataSource({
rowHasChanged: (r1, r2) => r1 !== r2,
sectionHeaderHasChanged: (s1, s2) => s1 !== s2
});
var dataBlob = {...}
return {
dataSource: ds.cloneWithRowsAndSections(dataBlob)
}
},
renderRow: function(rowData, sectionId, rowId) {
return (<View style={styles.row}>
<Image source={{uri: 'http:' + rowData.pic}}
style=
{styles.image} />
<View style={styles.rightSection}>
<Text style={styles.title}>{rowData.title}</Text>
<Text style={styles.priceInfo}>当前价: &yen;{rowData.price}</Text>
</View>
</View>);
},
renderSectionHeader: function(sectionData, sectionId) {
return (<View>
<Text style={styles.sectionHeaderStyle}>{sectionId}</Text>
</View>);
},
render: function() {
return (
<ListView
style={styles.listview}
dataSource={this.state.dataSource}
renderSectionHeader={this.renderSectionHeader}
renderRow={this.renderRow}/>
);
}
});

Demo 运行的效果如下:

分页

除了简单的渲染之外,另外一个要考虑的问题就是 当数据量很大的时候如何分页加载 。这种情形分两种情况考虑:

  1. 数据一次性拿到,边滚动边加载
  2. 数据不是一次性拿到,而是有可能分屏取数据

对于第一种情况,在 ListView 内部其实已经做了分页的处理:

  • ListView 内部通过 curRenderedRowsCount 状态保存已渲染的行数;
  • 初始状态下,要加载的数据条数等于 initialListSize(默认为 10 条);
  • 在滚动时检测当前滚动的位置和最底部的距离,如果小于 scrollRenderAheadDistance (默认为 1000),就更新curRenderedRowsCount ,在它原有值基础上加 pageSize 个(默认为 1 条);
  • 由于属性变化,触发了 ListView 重新的 render 。在渲染过程中,curRenderedRowsCount 起到截断数据的作用,React 的 diff 算法使得只有新加入的数据才会渲染到了界面上。

整个过程类似于 Web 端懒加载机制,即 每次在和底部的距离达到一个阈值时,加载接下来的 pageSize 个数据

对于第二种情况,ListView 提供了相关的属性:

  • onEndReachedThreshold,在滚动即将到达底部时触发;
  • onEndReached,在已经到达底部时触发;

我们可以在这两个方法中调用接口去拿数据,取到数据后再更新数据源。

多列

很多页面中的列表并非单列的,如手淘搜索结果页里,商品分两列并排展示。乍一看似乎要做出不少调整,但实际上只通过布局即可达到相关效果。ListView 并没有强制要求一个 rowData 在展示时一定要占满一行,在多列的情况下,我们适时调整每个 rowData 占据的宽度即可。

由于 React Native 使用 Flexbox 进行布局,在实现多列时,主要用到的是 flexWrap:wrap 属性:它的效果类似于 float,即水平地排列每一项,当放不下时进行折行处理。在设置每行视图占据一半宽度后就达到了两列的效果,多列的类似。

具体示例可以参考ListViewGridLayoutExample

滚动

ListView 只是整合了数据和展现,但实际滚动的功能还是由 ScrollView 全权负责。ScrollView 实现完全和平台相关:在 iOS 上,它映射为 RCTScrollView;在 Android 上,它映射为 RCTScrollViewAndroidHorizontalScrollView

React Native 让不同端上的技术融合在了一起,同时也给开发人员提出了更高的要求。以 ScrollView 为例,大量的属性其实原封不动映射给了 UIScrollView,这就意味着如果想再深入地研究下去,必须对客户端相关技术有足够了解。无论是前端还是客户端,跳出自己熟悉的那片领域也许才是更进一步的关键。

谈到滚动,有一点不得不说的就是 列表的无限加载,这牵涉到滚动的性能。

Github 上的这个 issue对此展开了热烈的讨论。其中有人就提到,数据量很大情况下,ListView 在加载时所占用的 CPU 和内存会大大增加,滚动到最后就导致了应用 crash。

为此,ListView 中新添加了一个实验性的属性: removeClippedSubviews ,它能在滚动时及时删掉列表中处于视窗的之外的行,以此达到降低内存消耗的目的。不幸的是,即使设置了这个属性,程序虽然各项占用减少了不少,但还是没避免崩溃的命运。处于好奇,我也在最新版的 ListView 基础上做了简单尝试,不断加载一个无限大的列表,但并没有出现崩溃的情况:

  • 即使加载了 3000、4000 行,Android 真机、iOS 真机和 iOS 模拟器上都没有崩溃;
  • Android 上明显感到数据加载有 阶段性的延时 ,即滚动一定程度后,再次滚动数据始终加载不出来或要等一段时间才加载出来,体验较差;iOS 相比要流畅的多;

但不崩溃并非最终的目的,很多 React Native 使用者都在试图改进 ListView 的性能表现,相比于直接使用 Native 端的组件,ListView 性能还是差强人意,有很大优化空间。

总结

ListView 并没有创造出新的东西,它只是集各家所长,很好地将 React 的视图渲染和 Native 端很成熟的滚动机制融合在了一起,使用起来和其他组件无差,静态地定义展现、动态地组织数据,是给人带来的直观感受。本文仅对 ListView 基础用法作了简要介绍,更为细致的点还是要在实际使用的过程中去发现。