React Native 的 ListView 性能問題已解決

長列表或者無限下拉列表是最多見的應用場景之一。RN 提供的 ListView 組件，在長列表這種數據量大的場景下，性能堪憂。而在最新的 0.43 版本中，提供了 FlatList 組件，或許就是你須要的高性能長列表解決方案。它足以應對大多數的長列表場景。

測試數據

FlatList 到底行不行，光說不行，先動手測試一下吧。

性能瓶頸主要體如今 Android 這邊，因此就用魅族 MX5 測試機，測試無限下拉列表，列表爲常見的左文右圖的形式。

測試數據以下：

對比	ListView	FlatList
1000條時內存	350M	180M
2000條時內存	/	230M
js-fps	4~6 fps	8~20 fps

js-pfs 相似於遊戲的畫面渲染的幀率，60 爲最高。它用於判斷 js 線程的繁忙程度，數值越大說明 js 線程運行狀態越好，數值越小說明 js 線程運行狀態越差。在快速滑動測試 ListView 的時候， js-pfs 的值一直在 4~6 範圍波動，即便中止滑動，js-pfs 的值也不能很快恢復正常。而 FlatList 在快速滾動後中止，js-pfs 可以很快的恢復到正常。

內存方面，ListView 滑動到 1000 條時，已經漲到 350M。這時機器已經卡的不行了，因此無法滑到 2000 條並給出相關數據。而 FlatList 滑到 2000 條時的內存，也比 ListView 1000 條時的內存少很多。說明，FlatList 對內存的控制是很優秀的。

主觀體驗方面：FlatList 快速滑動至 2000 條的過程當中全程體驗流暢，沒有出現卡頓或肉眼可見的掉幀現象。而ListView 滑動到 200 條開始卡頓，頁面滑動變得不暢，到 500 條渲染極其緩慢，到 1000 條時已經滑不動了。

經過以上的簡單的測試，能夠看出，FlatList 已經可以應對簡單的無限列表的場景。

使用方法

FlatList 有三個核心屬性 data renderItem getItemLayout。它繼承自 ScrollView 組件，因此擁有 ScrollView 的屬性和方法。

data

和 ListView 不一樣，它沒有特殊的 DataSource 數據類型做爲傳入參數。它接收的僅僅只是一個 Array<object> 做爲參數。
參數數組中的每一項，須要包含 key 值做爲惟一標示。數據結構以下：

[{title: 'Title Text', key: 'item1'}]

renderItem

和 ListView 的 renderRow 相似，它接收一個函數做爲參數，該函數返回一個 ReactElement。函數的第一個參數的 item 是 data屬性中的每一個列表的數據（ Array<object> 中的 object) 。這樣就將列表元素和數據結合在一塊兒，生成了列表。

_renderItem = ({item}) => (
   <TouchableOpacity onPress={() => this._onPress(item)}>
     <Text>{item.title}}</Text>
   <TouchableOpacity/>
 );
 ...
 <FlatList data={[{title: 'Title Text', key: 'item1'}]} renderItem={this._renderItem} />

getItemLayout

可選優化項。可是實際測試中，若是不作該項優化，性能會差不少。因此強烈建議作此項優化！
若是不作該項優化，每一個列表都須要事先渲染一次，動態地取得其渲染尺寸，而後再真正地渲染到頁面中。

若是預先知道列表中的每一項的高度(ITEM_HEIGHT)和其在父組件中的偏移量(offset)和位置(index)，就能減小一次渲染。這是很關鍵的性能優化點。

getItemLayout={(data, index) => (
   {length: ITEM_HEIGHT, offset: ITEM_HEIGHT * index, index}
 )}

完整代碼以下：

// 這裏使用 getData 獲取假數據
// 數據結構相似於 [{title: 'Title Text', key: 'item1'}]
import getData from './getData';
import TopicRow from './TopicRow';
// 引入 FlatList
import FlatList from 'react-native/Libraries/CustomComponents/Lists/FlatList';

export default class Wuba extends Component {

  constructor(props) {
    super(props);
    this.state = {
      listData: getData(),
    };
  }

  renderItem({item,index}) {
    return <TopicRow  {...item} id={item.key} />;
  }

  render() {
    return (
      <FlatList
        data = {this.state.listData}
        renderItem={this.renderItem}
        onEndReached={()=>{
          // 到達底部，加載更多列表項
          this.setState({
            listData: this.state.listData.concat(getData())
          });
        }}
        getItemLayout={(data, index) => (
          // 120 是被渲染 item 的高度 ITEM_HEIGHT。
          {length: 120, offset: 120 * index, index}
        )}
      />
    )
  }
}

源碼分析

FlatList 之因此節約內存、渲染快，是由於它只將用戶看到的(和即將看到的)部分真正渲染出來了。而用戶看不到的地方，渲染的只是空白元素。渲染空白元素相比渲染真正的列表元素須要內存和計算量會大大減小，這就是性能好的緣由。

FlatList 將頁面分爲 4 部分。初始化部分/上方空白部分/展示部分/下方空白部分。初始化部分，在每次都會渲染；當用戶滾動時，根據需求動態的調整(上下)空白部分的高度，並將視窗中的列表元素正確渲染出來。

_usedIndexForKey = false;
const lastInitialIndex = this.props.initialNumToRender - 1;
const {first, last} = this.state;
// 初始化時的 items (10個) ，被正確渲染出來
this._pushCells(cells, 0, lastInitialIndex);
//  first 就是 在視圖中(包括要即將在視圖)的第一個 item
if (!disableVirtualization && first > lastInitialIndex) {
  const initBlock = this._getFrameMetricsApprox(lastInitialIndex);
  const firstSpace = this._getFrameMetricsApprox(first).offset -
    (initBlock.offset + initBlock.length);
  // 從第 11 個 items (除去初始化的 10個 items) 到 first 渲染空白元素
  cells.push(
    <View key="$lead_spacer" style={{[!horizontal ? 'height' : 'width']: firstSpace}} />
  );
}
// last 是最後一個在視圖(包括要即將在視圖)中的元素。
// 從 first 到 last ，即用戶看到的界面渲染真正的 item
this._pushCells(cells, Math.max(lastInitialIndex + 1, first), last);
if (!this._hasWarned.keys && _usedIndexForKey) {
  console.warn(
    'VirtualizedList: missing keys for items, make sure to specify a key property on each ' +
    'item or provide a custom keyExtractor.'
  );
  this._hasWarned.keys = true;
}
if (!disableVirtualization && last < itemCount - 1) {
  const lastFrame = this._getFrameMetricsApprox(last);
  const end = this.props.getItemLayout ?
    itemCount - 1 :
    Math.min(itemCount - 1, this._highestMeasuredFrameIndex);
  const endFrame = this._getFrameMetricsApprox(end);
  const tailSpacerLength =
    (endFrame.offset + endFrame.length) -
    (lastFrame.offset + lastFrame.length);
   // last 以後的元素，渲染空白
  cells.push(
    <View key="$tail_spacer" style={{[!horizontal ? 'height' : 'width']: tailSpacerLength}} />
  );
}

既然要使用空白元素去代替實際的列表元素，就須要預先知道實際展示元素的高度(或寬度)和相對位置。若是不知道，就須要先渲染出實際展示元素，在獲取完展示元素的高度和相對位置後，再用相同（累計）高度空白元素去代替實際的列表元素。_onCellLayout 就是用於動態計算元素高度的方法，若是事先知道元素的高度和位置，就可使用上面提到的 getItemLayout 方法，就能跳過 _onCellLayout 這一步，得到更好的性能。

return (
    // _onCellLayout 就是這裏的 _onLayout
    // 先渲染一次展示元素，經過 onLayout 獲取其尺寸等信息
  <View onLayout={this._onLayout}>
    {element}
  </View>
);
...
  _onCellLayout = (e, cellKey, index) => {
    // 展示元素尺寸等相關計算
    const layout = e.nativeEvent.layout;
    const next = {
      offset: this._selectOffset(layout),
      length: this._selectLength(layout),
      index,
      inLayout: true,
    };
    const curr = this._frames[cellKey];
    if (!curr ||
      next.offset !== curr.offset ||
      next.length !== curr.length ||
      index !== curr.index
    ) {
      this._totalCellLength += next.length - (curr ? curr.length : 0);
      this._totalCellsMeasured += (curr ? 0 : 1);
      this._averageCellLength = this._totalCellLength / this._totalCellsMeasured;
      this._frames[cellKey] = next;
      this._highestMeasuredFrameIndex = Math.max(this._highestMeasuredFrameIndex, index);
      // 從新渲染一次。最終會調用一次上面分析的源碼
      this._updateCellsToRenderBatcher.schedule();
    }
  };

簡單分析 FlatList 的源碼後，後發現它並無和 native 端複用邏輯。並且若是有些機器性能極差，渲染過慢，那些假的列表——空白元素就會被用戶看到！

那麼爲何要基於 RN 的 ScrollView 組件進行性能優化，而不直接使用 Android 或 iOS 提供的列表組件呢？

最簡單回答就是：太難了！

因爲本人對 RN 底層原理實現只有簡單理解。只能引用 Facebook 大神的解釋，起一個拋磚引玉的做用。

以 iOS 的 UITableView 爲例，全部即將在視窗中呈現的元素都必須同步渲染。這意味着若是渲染過程超過 16ms，就會掉幀。

In UITableView, when an element comes on screen, you have to synchronously render it. This means that you've got less than 16ms to do it. If you don't, then you drop one or multiple frames.

可是問題是，從 RN render 到真正調用 native 代碼這個過程自己是異步的，過程當中消耗的時間也並不能保證在 16ms 之內。

The problem is in the RN render -> shadow -> yoga -> native loop. You have at least three runloop jumps (dispatch_async(dispatch_get_main_queue(), ...) as well as background thread work, which all work against the required goal.

那麼解決方案就是，在一些須要高性能的場景下，讓 RN 可以同步的調用 native 代碼。這個答案或許就是 ListView 性能問題的終極解決方案。

We are actually starting to experiment more and more with synchronous method calls for other modules, which would allow us to build a native list component that could call renderItem on demand and choose whether to make the call synchronously on the UI thread if it's hi-pri (including the JS, react, and yoga/layout calcs), or on a background thread if it's a low-pri pre-render further off-screen. This native list component might also be able to do proper recycling and other optimizations.