<p> </p>    <h2>1 基本使用</h2>    <p><a href="/misc/goto?guid=4959672957518057695" rel="nofollow,noindex"><strong>ScrollView</strong> </a> 是 React Native（后面简称：RN） 中最常见的组件之一。理解 ScrollView 的原理，有利于写出高性能的 RN 应用。</p>    <p>ScrollView 的基本使用也非常简单，如下：</p>    <pre>  <code class="language-javascript"><ScrollView>      <Child1 />    <Child2 />    ...  </ScrollView>    </code></pre>    <p>它和 View 组件一样，可以包含一个或者多个子组件。对子组件的布局可以是垂直或者水平的，通过属性 horizontal=true/false 来控制。甚至还默认支持“下拉”刷新操作。另外还有一个特别赞的特性，超出屏幕的 View 会自动被移除，从而节省资源和提高绘制效率。我们来看如下一个例子：</p>    <pre>  <code class="language-javascript">class ScrollViewTest extends Component {      render() {      let children = [];        for (var i = 0; i < 20; i++) {        children.push(          <View key={"key_" + i} style={styles.child}>            <Text>{"T" + i}</Text>          </View>);      }      return (          <ScrollView style={styles.scrollView}>            {children}          </ScrollView>      );    }  }  </code></pre>    <p>在 Android 上的效果如下： <img src="https://simg.open-open.com/show/432287003cd996906995751a80989a17.png"> 如图，我们在 ScrollView 中添加了 20 个子组件，但是我们的屏幕任意时刻最多只能显示 5 个子项目。</p>    <p>下面我们来看实际对应的 Native 控件的情况。RN 中的 ScrollView 对应到 Native 的 RCTScrollView，自动把子组件包含在一个 ViewGroup 中（因为Android 的 ScrollView 只能有一个直接子控件），如下图中的红色框内：</p>    <p><img src="https://simg.open-open.com/show/76beebd1953b47b16a8f8c9f0a81cc07.png"></p>    <p>注意到，我们在 JS 中添加了 20 个子组件，但是在 RCTViewGroup 中只有在屏幕上显示的 5 个子控件，在屏幕外的组件，也会自动添加到 View 树中，这与 Native 的 ScrollView 表现一致。</p>    <p>其实，RN 中的 ScrollView 有一个 removeClippedSubviews 属性，表示如果子 View 超出可视区域，是否自动移除，虽然默认是 true。但是也需要子 View 的 overflow: 'hidden' 属性配合。所以，给子组件的 style 添加如下属性即可。</p>    <pre>  <code class="language-javascript"><View key={"key_" + i} style={styles.child}>      <Text>{"T" + i}</Text>  </View>;    const styles = StyleSheet.create({      child: {      ...      overflow: 'hidden',    },  });  </code></pre>    <p>得到的效果是，在使用上完全没有区别，而我们来看一下界面的 Tree View，如下图：</p>    <p><img src="https://simg.open-open.com/show/f49ea7b113261dc1dda45e8612500879.png"> 可见，屏幕外的子 View，就被自动从 View 树中移除了。</p>    <p>同时，我们来看一下 iOS 平台上的表现，与 Android 上类似：</p>    <p><img src="https://simg.open-open.com/show/7adc6f5b496d9f1017ba148bd2ee9fad.png"></p>    <p>这印证了我们前面的结论，RN 自动优化了 Native 平台 ScrollView，在这个层面，我们可以说 RN 比 Native 的性能还要高。</p>    <h2>2 性能研究</h2>    <p>通过上面的实例，我们可以看到，ScrollView 应该是非常高效的，它使用简单，并且还能按需构建 View 树，高效渲染，有点类似 Native 平台上的 ListView 了，是我心目完美 ScrollView 该有的样子。</p>    <p>但是，之前看到腾讯的 TAT.ronnie 一篇文章 <a href="/misc/goto?guid=4959672957605024134" rel="nofollow,noindex"> <em>探索 react native 首屏渲染最佳实践</em> </a> ，文中提到的优化方法，主要就是针对 ScrollView 的。作者认为，在 ScrollView 中，即使不可见（例如，超出屏幕）的组件还是会绘制的。为了优化 ScrollView 的绘制性能，不可见的组件，应该在 JS 中避免添加到 ScrollView 中。</p>    <p>显然，这与我们前面观察到的结论是矛盾的。但是，作者的通过那样处理，确实优化了显示性能，这是怎么回事呢？为了验证，我们也和文中一样，使用 componentDidMount() 和 componentWillMount() 的时间差衡量显示速度。在 Android 上，测试 ScrollView 的子组件数量分别为 10，100，1000 的时候，显示的时间，以及 APP 所占用的内存：</p>    <table>     <tbody>      <tr>       <th>子组件数量</th>       <th>加载时间(ms)</th>       <th>占用内存(MB)</th>       <th>绘制时间*(ms)</th>      </tr>      <tr>       <td>10</td>       <td>309</td>       <td>19.7</td>       <td>14.666</td>      </tr>      <tr>       <td>100</td>       <td>1170</td>       <td>21.9</td>       <td>15.016</td>      </tr>      <tr>       <td>1000</td>       <td>9461</td>       <td>26.5</td>       <td>15.025</td>      </tr>     </tbody>    </table>    <p>* 注，这里的绘制时间，是在 Tree View 中获得的 Draw 时间。</p>    <p>从加载时间看，时间随着子组件的数量线性增加，占用内存也有类似趋势，说明 TAT.ronnie 的改进方法确实是有效的。另外我们也注意到，随着子组件的数量增加，Draw 的时间并没有明显的变化，其实 Measure 和 Layout 时间也没有明显的变化。</p>    <p>说明 ScrollView 虽然有 removeClippedSubviews 属性，也确实在 View Hierarchy 中去掉了不可见的 View。但是组件的加载时间消耗资源还是随着子组件的数量成正比。</p>    <h2>3 原因分析</h2>    <p>来看一下 RN 中 ScrollView 的相关的源码，主要分析 Android 平台的代码，iOS 类似，就不赘述了。</p>    <pre>  <code class="language-javascript">// ScrollView.js  var AndroidScrollView = requireNativeComponent('RCTScrollView', ScrollView, nativeOnlyProps);    var AndroidHorizontalScrollView = requireNativeComponent(      'AndroidHorizontalScrollView',    ScrollView,    nativeOnlyProps  );    var ScrollView = React.createClass({      render: function() {      var contentContainer =         <View           ...           removeClippedSubviews={this.props.removeClippedSubviews}           collapsable={false}>           {this.props.children}         </View>;         var ScrollViewClass;       if (Platform.OS === 'ios') {         ...       } else if (Platform.OS === 'android') {         if (this.props.horizontal) {           ScrollViewClass = AndroidHorizontalScrollView;         } else {           ScrollViewClass = AndroidScrollView;         }       }         // 为了简单，忽略有下拉刷新的情况       return (        <ScrollViewClass ...>          {contentContainer}        </ScrollViewClass>      );    }  });  </code></pre>    <p>JS 部分的代码逻辑很简单。首先把 ScrollView 所有子组件包装在一个 View contentContainer 中，并继承设置了 removeClippedSubviews 属性。根据 ScrollView 是否是水平方向，决定是用 RCTScrollView 或者 AndroidHorizontalScrollView Native 组件来包含 contentContainer。</p>    <p>所以，我们先来看 RCTScrollView 本地组件对应的代码（AndroidHorizontalScrollView 原理也类似）。JS 中的 RCTScrollView 组件由 com.非死book.react.views.scroll.ReactScrollViewManager 提供，具体的 View 的实现是 com.非死book.react.views.scroll.ReactScrollView 。</p>    <p>其中 ReactScrollViewManager 是最基础的 ViewManager 的实现，导出了一些属性和事件。ReactScrollView 则继承于 android.widget.ScrollView ，并实现了 ReactClippingViewGroup 接口。关于 Scroll 事件相关的代码我们先忽略，我主要关心 View 绘制相关的代码。主要在下面这段代码：</p>    <pre>  <code class="language-javascript">@Override  public void updateClippingRect() {      if (!mRemoveClippedSubviews) {      return;    }    ...    View contentView = getChildAt(0);    if (contentView instanceof ReactClippingViewGroup) {      ((ReactClippingViewGroup) contentView).updateClippingRect();    }  }  </code></pre>    <p>可见，如果不开启 mRemoveClippedSubviews ，它就和普通的 ScrollView 一样，否者，它就会调用了它的第一个（也是唯一的一个）子 View 的 updateClippingRect() 方法。从上面的 JS 中我们可以看到，它的第一个子元素应该就是一个 View 组件，对应的 Native 的控件就是 ReactViewGroup 。 ReactViewGroup 是 RN for Android 中最基础的控件，它直接继承于 android.view.ViewGroup ：</p>    <pre>  <code class="language-javascript">public class ReactViewGroup extends ViewGroup implements        ReactInterceptingViewGroup, ReactClippingViewGroup, ReactPointerEventsView, ReactHitSlopView {    private boolean mRemoveClippedSubviews = false;    // 用来保存所有子 View 的数组，包括可见和不可见的    private @Nullable View[] mAllChildren = null;    private int mAllChildrenCount;    // 当前 ReactViewGroup 于父 View 相交矩阵，    // 也就是它自己在父 View 中可见区域    private @Nullable Rect mClippingRect;    ...  }  </code></pre>    <p>在 ReactViewGroup 中实现 removeClippedSubviews 的功能也非常直接，需要更新界面 Layout 的时候，遍历所有的子 View，看子 View 是否在 mClippingRect 区域内，如果在，就通过 addViewInLayout() 方法添加此 View，否者就通过 removeViewsInLayout() 方法移除它。</p>    <p>到这了，我们就可以解释前面的矛盾了。虽然在 ScrollView 的 View Hierarchy 中，会自动移除不显示的 View，但是实际上还是创建了所有的子 View，所以所占内存和加载时间会线性增加。</p>    <p>关于创建所有子 View，我这里可以多分析一下。我们知道在 Android 中，创建 View 的代价是很大的。特别是在 ScrollView 中，所有的子 View 都是同时创建的。如果 ScrollView 中子 View 的数量很多，这样的代价累加起来，对 APP 造成的延迟和卡顿是相当可观的。例如前面的测试中有 1000 个子组件，加载时间竟然长达 9.5 秒。我们用 <strong>Method Tracing</strong> 看一下创建一个子 View 所花的时间，如下图：</p>    <p><img src="https://simg.open-open.com/show/0aaa8e68f5e1fe8314410d662b26c6e4.png"> 这里只是简单的创建一个 TextView 就消耗了大约 25ms 的时间。当然 Tracing 过程本身会拖慢 APP 运行，但是不影响我们的结论。所以 Android 中列表类的控件，都内部支持对 View 的复用，尽量避免创建 View。</p>    <p>通过前面的分析，我们可以得到的结论是： <strong>RN 中的 ScrollView 并不像我们想象的那样高性能</strong> 。</p>    <h2>4 ListView</h2>    <p>在这里提到 ListView，是因为 RN 中的 ListView 就是基于 ScrollView 的，但是有一些优化。这里简要介绍一些 ListView 的原理。</p>    <p>ListView 其实是对 ScrollView 的一个封装，对应到 Native 平台，和 ScrollView 的表现一模一样。但是 ListView 在显示列表内容的时候，会根据滑动距离，逐步向 ScrollView 中添加子组件（通过调用 renderRow() 方法）。注意到 ListView 有 initialListSize 属性，表示第一次加载的时候添加多少个子项，默认是 10，还有 pageSize 属性，表示每次需要添加的时候，增加多少个子项，默认是 1。</p>    <p>通过上面的分析我们可以看到，ListView 在第一次加载的时候，不论你的列表有多大，默认最多加载 initialListSize 个子项，所以能保证启动速度，如果还没有充满，或者在向下滑动过程中，再组件添加子项。这样的操作似乎比较合理，但是注意到，整个操作中，会逐渐向 ListView 中添加子项，新出现的子项，都是通过创建新的 View，而完全没有复用的过程。所以，如果在应用中，ListView 中的子项数量特别多，ListView 往下滑动的过程中，内存会逐渐上涨的。</p>    <p>值得一提的是，ListView 提供了 renderScrollComponent ，可以使用其他 Scroll 组件来替换 ScrollView，并且 RecyclerViewBackedScrollView 组件来作为备选。看到这个名字我很欣喜，说明它支持子项的回收复用（Recycler）。首先，看到 iOS 的实现 RecyclerViewBackedScrollView.ios.js ，其实它就是 ScrollView，并没有实现所谓的复用，失望了一半。继续看 Android 的实现，它实际上是对应 Native 的 com.非死book.react.views.recyclerview.AndroidRecyclerViewBackedScrollView ，它继承与 Android 的 RecyclerView 。看到这里，如果使用这种方法，我直观感觉 RN 的 ListView 性能在 Android 上表现应该会比 iOS 好。</p>    <p>我们继续来看它是怎么实现回收复用的，AndroidRecyclerViewBackedScrollView 内部实现了一个 RecyclerView.Adapter，如下：</p>    <pre>  <code class="language-javascript">static class ReactListAdapter extends Adapter<ConcreteViewHolder> {      private final List<View> mViews = new ArrayList<>();      public void addView(View child, int index) {      mViews.add(index, child);      ...    }      public void removeViewAt(int index) {      View child = mViews.get(index);      if (child != null) {        mViews.remove(index);        ...      }    }      @Override    public ConcreteViewHolder onCreateViewHolder(ViewGroup parent, int viewType) {      return new ConcreteViewHolder(new RecyclableWrapperViewGroup(parent.getContext()));    }      @Override    public void onBindViewHolder(ConcreteViewHolder holder, int position) {      RecyclableWrapperViewGroup vg = (RecyclableWrapperViewGroup) holder.itemView;      View row = mViews.get(position);      if (row.getParent() != vg) {        vg.addView(row, 0);      }    }      @Override    public void onViewRecycled(ConcreteViewHolder holder) {      super.onViewRecycled(holder);      ((RecyclableWrapperViewGroup) holder.itemView).removeAllViews();    }    }  </code></pre>    <p>注意到这里有一个 mViews ，用来保存所有的子 View，绑定 View 的时候只是简单用一个空的 View（RecyclableWrapperViewGroup）包了一下。这样一来，RecyclerView 完全没有什么起到复用的作用呀！测试一下，确实也是这样，性能问题还是很严重。</p>    <p>这里我们也可以得到一个结论： RN 中的 ListView 也不是我们想象的 ListView 该有的性能 。</p>    <h2>5 改进方案</h2>    <p>通过前面的分析，我们已经知道了 RN 中的 ScrollView 或者 ListView 的性能瓶颈了，同时也有了改进的思路。下面针对各种情况分析：</p>    <ol>     <li>如果要优化首次加载速度，也就是启动速度：可以参考 TAT.ronnie 的文章中的方法，根据实际情况，最小化 ScrollView 或者 ListView 初始子项数量；</li>     <li>优化内存：因为 ScrollView/ListView 会保存所有子 View 在内存中，因为我们没法删掉子项，但是我们可以尽量减少每个子项所占的内存。例如这个项目 <a href="/misc/goto?guid=4959672957689396053" rel="nofollow,noindex">react-native-sglistview</a> ，它在子项不可见的时候，就把它退化成一个最基本的 View；</li>     <li>终极解决方案：要真正达到高性能，就需要尽量少的创建 View，要想办法真正重复利用已经创建的子项。目前只有一些想法，待我实现了，再来更新。</li>    </ol>    <p>via： http://www.race604.com/react-native-scrollview-performance/ </p>