ListView
RN环境：0.57.8 端：iOS
- 默认不会一次性创建，创建item的条数为大约两屏幕 这个会根据 item 高度的不同创建的个数是不一样的
- 如果initialListSize为0 会全部创建
- pageSize 一次性创建item 的条数
- 创建以后不会销毁，内存在不断增长
- 目前已经被废弃，废弃原因是导致内存在增长
ScrollView
一个封装了平台的 ScrollView（滚动视图）的组件，同时还集成了触摸锁定的“响应者”系统。 Naitve 的ScrollView 比起大家都了解就是一切行全部绘制出来，需要给一个明确的高度.这里就不做过多的阐述
VirtualizedList
FlatList和SectionList 的底层实现，通过维护一个有限的渲染窗口，并将渲染窗口之外的元素全部用合适的定长空白空间代替的方式，极大的改善了内存消耗以及再有大量数据情况下的使用性能。这个渲染窗口能影响滚动行为，当一个元素可视区域太远时，它就有一个较低优先级；否则就获得一个较高的优先级。
注意事项：
- 为了优化内存占用同时保持滑动的流畅，列表内容会在屏幕外异步绘制。这就意味着如果用户滑动的速度超过渲染的速度，则会先看到空白的内容，
- 组件继承自PureComponent 而非通常的Component,这意味着如果其props在浅比较中是相等，则不会重新渲染，如果是一个引用类型，则需要先修改其引用地址然后再修改其值，否则界面很可能不会刷新，
原来分析
- 基于ScrollView 进行封装
- 首次初始化的条数 默认10条
- 后续每次初始化增加的条数 默认是10条
- 设置加载视图的高度 默认是21 * visibleH ，这里指得上下，如果0从开始就是 （21-1）* 0.5 *visibleH
- 前10条数据不会被重置可以根据外边设置
FlatList
前边说过 FlatList是基于对VirtualizedList 的实用性封装
先来点字面量的解释
- js 实现
- 优先渲染一定的条数
- 异步绘制屏幕外内容
- 会不断的进行render
- 目的就是将窗口外边的数据用一个白色的空间代替，减少一个item 数据过多导致的 性能问题
- 给定一个长度这个长度区间是不会移除的，离屏幕的距离大于这个区间就会被移除，在这个屏幕区间会被创建，刚试了10屏高度
- 这里说的试定长度 是值销毁组件，创建一个新的空白页放这里占位
- getItemLayout 添加以后会增加绘制的条数 ,不增加基本就是10屏，增加一下子干到24屏了，why??? 是不是因为有了这个方法 不用计算高度，所以速度就会快一点，这样子多加了10几屏数据
RecycleList
RecycleList 的实现也是基于ScrollView进行封装的
- 可视窗口上下是250，在这个区域的进行初始化
- 始终保持这些元素，不会重复创建销魂
- 底层是position:absolute ，会算出每个视图的偏移量，通过top存放位置
- RecyclePool 来存放视图，有一个逻辑是 新的render 视图 和 旧的render 视图进行比较，如果新的里边有就添加，如果只有旧的里边有就移除，移除的放到RecyclePool 里边，新的添加的时候回到RecyclePool里边去取。
- onScoll判断便宜量
RecycleList 和FlatList 的区别
- 不会复用每次都是创建和销魂
- FlatList 的思路是保持视图顶部的x 条数据不变，x+1 开始销魂会创建，目的就是点击回到顶部
- FlatList 是提前创建多少屏幕数据，如果设置了这个屏幕数回一次性全部创建出来当然可以先加载首屏的，但是可以控制，不过这个render 都是创建与销魂 一是CPU 二是性能问题
- RecycleList 说白了也是几屏数据，不过就保持这些视图不会创建与销魂，只是在复制，如果FlatList 创建屏幕的数据减少，首先和RecycleList的就无限接近，但是有个问题就是 创建和销魂上有区别
