React-Native iOS 列表（ListView）优化方案

在项目开发中，很多地方用到了列表，而 React-Native 官网中提供的组件 ListView，虽然能够满足我们的需求，但是性能问题并没有很好的解决，对于需要展现大量数据的列表，app 的内存将会非常庞大。针对 React-Native 的列表性能问题，现在提供几套可行性方案：

1.利用 Facebook 提供的建议对 ListView 进行优化

Facebook 官方对 ListView 的性能优化做了简单介绍，并提供了以下几个方法：

• initialListSize
• 这个属性用来指定我们第一次渲染时，要读取的行数。如果我们想尽可能的快，我们可以设置它为1, 然后可以在后续的帧中，填弃其它的行。每一次读取的行数，由 pageSize 决定.
• pageSize
• 在使用了 initialListSize 之后，ListView 根据 pageSize 来决定每一帧读取的行数，默认值为1, 但如果你的的 views 非常的小，并且读取时占的资源很少, 你可以调整这个值，在找到适合你的值。
• scrollRenderAheadDistance
• 如果我们的列表有2000个项，而让它一次性读取，它会导致内存和计算资源的耗尽。所以 scrollRenderAhead distance 可以指定，超出当前视图多少，继续宣染。
• removeClippedSubviews
• “当它设置为true时，当本地端的superview为offscreen时 ，不在屏幕上显示的子视图offscreen（它的overflow的值为hidden) 会被删除。它可以改善长列表的滚动的性能，默认值为true. 这对于大的ListViews来说是一个非常重要。在Android, overflow的值通常为hidden. 所以我们并不需要担心它的设置，但是对于iOS来说，你需要设置row Container的样式为overflow: hidden。

在使用了上述方法后，我们可以看到app的内存占用有了一定的下降（加载100张图片时的效果）：

使用前：

使用后：

3.桥接 Native tableview

第二种方法里面，能够比较好的解决屏幕外的 cell 内存问题，但是和 native tableview 相比，并没有 native 的 cell 重用机制完美，那么，我们可以讲 native 的 tableview 桥接到 React-native 中来，让我们可以在 React-Native 中也可以重用 cell

我们创建一些 VirtualView，他只是遵从了 RCTComponent 协议，其实并不是一个真正的 View，我把它形成一个组件，把它 Bridge 到 JS，这就使得，你在写 JSX 的时候，就可以直接用 VirtualView 来去做布局了。在RN里面做布局的时候我们用VirtualView来做布局。但是最终在 insertReactSubview 时，我们把这些 VirtualView 当做数据去处理，通过 VirtualView 和RealView 的对应关系，把它转化成一个真实的 View 对象添加到 TableView 中去。

但是使用这种方法，我们需要将 tableview 的所有常用数据源方法和代理方法都桥接到 React-Native 中来，甚至对于一些 cell 组件，我们也需要自己桥接，并不能像 React-Native 那样使用自己的组件。当我们的需求比较复杂或者需求发生变化时，就需要重新桥接我们的自定义 cell，这样工作量就会比较大。大多数的 cell 里面如果做展示来用的话，Label 和 Image 基本上能够满足大多数的需求了。所以我们现在只是做了 Label 和 Image 的对应工作，但在 RN 的一些官方控件，在这个 view 里面都是没法直接使用的。

4.用 JS 实现一套 cell 重用的逻辑

基于 RN 的 ScrollView，我们也监听 OnScroll()，他往上滑的时候，我们需要把上面的 cellComponent 挪下来，挪到上面去用。但是这个方式最终的效果并不是特别好。

问题在于，如果我们所有的 Cell 都是一样高的，里面的元素不是很多的情况下，性能还相对好一些，我们每次 OnScroll 的时候，他处理的Cell比较少。如果你希望有一个界面滚动能够达到流畅的话，所有的处理都需要在 16ms 内完成，但是这又造成了 onScroll 都要去刷新页面，导致这样的交互会非常非常多，导致你从 JS，到 native 的 bridge 要频繁的通讯，JS 中的很多处理方式都是异步的，使得这个方案的效果没有达到很好的预期。

总结

从上面的几种方案可以看出，方案1、2、3、4都能够比较好的解决列表的性能问题 ，而且各有优缺点，那么，我们在项目开发中该如何应用呢？

• 当我们在进行列表展示的时候，如果数据量不是特别的庞大（不是无限滚动的），且界面比较复杂的时候，方案1能够比较好的解决性能问题，而且操作起来比较简单，只需要对 listview 的一些属性进行基本设置。
• 当我们需要展示很多数据的时候（不是无限滚动的），我们可以使用方案2，对那些超出屏幕外的部分，对他进行组件最小化
• 当我们需要展示大量数据（可以无限滚动的），我们可以通过方案3/4，来达到重用的目的