使用 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 方法中:
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方法。一个简单的例子如下:
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}>当前价: ¥{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 运行的效果如下:
分页
除了简单的渲染之外,另外一个要考虑的问题就是 当数据量很大的时候如何分页加载 。这种情形分两种情况考虑:
- 数据一次性拿到,边滚动边加载
- 数据不是一次性拿到,而是有可能分屏取数据
对于第一种情况,在 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 上,它映射为RCTScrollView和AndroidHorizontalScrollView。
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 基础用法作了简要介绍,更为细致的点还是要在实际使用的过程中去发现。