在項目開發中，很多地方用到了列表，而 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張圖片時的效果）：

使用前：

MacDown Screenshot

MacDown Screenshot

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，來達到重用的目的