高性能のReact Native ListViewのための文字列の再利用

スクロール時に画面を越えるメモリに以前に保存された行の再利用は、iOSおよびAndroidで最初に実装されたListViewコンポーネントの使用を最適化するための広範な技術です。 React NativeのコンポーネントとしてのListViewの実装は、デフォルトではこの最適化を直接含んでいませんが、他にも多くの利点があります。 ただし、これは調査する価値のある素晴らしい例です。 Reactスタディの一部としてこの実装を検討することも興味深い思考実験になります。

リストはモバイルアプリ開発の重要な部分です

リストは、モバイルアプリの核心です。 多くのアプリケーションは、リストを表示します。これは、Facebookアプリケーションフィードの出版物のリスト、メッセンジャーのチャットリスト、Gmailメールのリスト、Instagramの写真のリスト、Twitterのツイートのリストなどです。



膨大な数のデータソース、数千行、大量のメモリを必要とするメディアファイルなど、リストがより複雑になると、その開発も難しくなります。



一方では、アプリケーションの速度を維持する必要があります。なぜなら、 60 FPSスクロールは、ネイティブエンゲージメントエクスペリエンス（UX）のゴールドスタンダードになりました。 一方、モバイルデバイスには過剰なリソースがないため、メモリの消費を低く抑える必要があります。 これらの両方の条件を満たすことは必ずしも容易ではありません。

ListViewの完璧な実装を見つける

ソフトウェア開発の基本的なルールは、どのシナリオでも最適化を予測できないことです。 別の分野の例を見てみましょう。データを保存するのに理想的なデータベースはありません。 一部のユースケースに最適なSQLデータベース、および他の状況に最適なNoSQLデータベースに精通している場合があります。 独自のデータベースを開発する可能性は低いため、ソフトウェア開発者として、特定の問題を解決するための適切なツールを選択する必要があります。



リストの表示にも同じルールが適用されます。リストの表示を実装する方法は、どのユースケースにも適しているだけでなく、同時に高いFPS速度と低メモリ要件を維持する方法を見つける可能性は低いです。



大まかに言えば、モバイルアプリケーションでリストを使用するためのオプションには2つのタイプがあります。



•非常に大きなデータソースを持つほぼ同一の行。 連絡先リストの行は同じように見え、構造も同じです。 ユーザーが探しているものが見つかるまで、文字列をすばやく閲覧できるようにしてください。 例：アドレス帳。

•非常に異なる行と小さなデータソース。 ここでは、すべての行が異なり、異なる量のテキストが含まれています。 一部にはメディアが含まれています。 ほとんどの場合、ユーザーはストリーム全体を表示するのではなく、メッセージを順番に読み取ります。 例：チャットメッセージ。

異なるユースケースに分割することの利点は、オプションごとに異なる最適化手法を提供できることです。

既製のReact Nativeリスト

React Nativeには、すぐに使えるListView実装が付属しています。 スクロール時に画面に表示される行の「遅延読み込み」、再描画の回数を最小限に抑える、さまざまなイベントループで線を描画するなど、非常に合理的な最適化が含まれています。



ListViewの完成した実装のもう1つの興味深い特性は、React Nativeの一部であるネイティブScrollViewコンポーネントを介してJavaScriptで完全に実装されていることです。 iOSまたはAndroidの開発経験がある場合、この事実は奇妙に思えるかもしれません。 ネイティブ開発キット（SDK）は、iOS用のUITableViewとAndroid用のListViewのリストビューの実績のある実装に基づいています。 React Nativeチームが使用しないと決めたものはないことは注目に値します。



これにはさまざまな理由があるかもしれませんが、これは以前に定義されたユースケースによるものと思われます。 iOSのUITableViewとAndroidのListViewは、最初のユースケースにほぼ完全に機能する類似の最適化手法を使用します-ほとんど同一の行と非常に大きなデータソースのリスト。 完成したListView React Nativeは、2番目のオプション用に最適化されています。



Facebookエコシステムの主なリストは、Facebook投稿フィードです。 Facebookアプリケーションは、React Nativeが登場するかなり前にiOSとAndroidに実装されました。 おそらくテープの元の実装は、iOSのUITableViewとAndroidのListViewのネイティブ実装に実際に基づいていたため、想像できるように、期待どおりに機能しませんでした。 テープは、2番目のユースケースの典型的な例です。 行は非常に異なっています、なぜなら すべての出版物は異なります-それらはコンテンツの量が異なり、異なる種類のメディアファイルを含み、異なる構造を持っています。 ユーザーはフィード内の出版物を順番に読み、通常は一度に何百行もスクロールしません。

では、なぜ再利用を検討しないのですか？

2番目のユースケース（非常に異なる行と小さなデータソースを持つリスト）がケースに適している場合は、既製のListView実装を選択することを検討する必要があります。 最初のユースケースでケースが説明されていて、完成した実装の作業に満足できない場合は、代替オプションを試してみることをお勧めします。



最初のユースケースは、ほとんど同一の行と非常に大きなデータソースを持つリストであることを思い出してください。 このシナリオでは、有効であることが証明されている主な最適化手法は文字列の再利用です。

データソースは非常に大きい可能性があるため、すべての行を同時にメモリに格納できないことは明らかです。 メモリ消費を最小限に抑えるために、現在画面に表示されている行のみを保存します。 スクロールの結果として表示されなくなった行は解放され、表示される新しい行はメモリに配置されます。



ただし、スクロール中に常にメモリ内の行を解放して配置するには、非常に集中的なプロセッサ作業が必要です。 このネイティブアプローチを使用すると、60 FPSの望ましい速度を達成できない場合があります。 幸いなことに、この使用例では、文字列はほとんど同じです。 つまり、画面からスクロールされた行を解放する代わりに、表示されているデータを新しい行のデータで置き換えるだけで新しい行を作成し、新しいメモリ位置を回避できます。



実用的な部分に移りましょう。 このユースケースを試すために例を用意します。 この例には、同じ構造の3,000行のデータが含まれます。

import React, { Component } from 'react'; import { Text, View, Dimensions } from 'react-native'; import RecyclingListView from './RecyclingListView'; const ROWS_IN_DATA_SOURCE = 3000; const dataSource = []; for (let i=0; i<ROWS_IN_DATA_SOURCE; i++) dataSource.push(`This is the data for row # ${i+1}`); export default class RecyclingExample extends Component { render() { return ( <View style={{flex: 1, paddingTop: 20,}}> <RecyclingListView renderRow={this.renderRow} numRows={dataSource.length} rowHeight={50} /> </View> ); } renderRow(rowID) { return ( <Text style={{ width: Dimensions.get('window').width, height: 50, backgroundColor: '#ffffff' }}>{dataSource[rowID]}</Text> ); view rawRecyclingExample.js hosted with by GitHub } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

UITableViewのネイティブ実装を使用する

前述のように、iOSおよびAndroidのネイティブSDKには、文字列を書き換える堅牢な実装があります。 iOSに焦点を合わせ、UITableViewを使用します。



このテクニックをJavaScriptで完全に実装しようとしない理由を疑問に思うかもしれません。 これは興味深い質問であり、いくつかの個別のブログエントリの詳細な説明に値します。 ただし、要するに、行を適切に上書きするには、現在のスクロールオフセットを常に知っている必要があります。スクロールするときに行を上書きする必要があるからです。 スクロールイベントはネイティブゾーンで発生し、 RNブリッジを通過するトランジションの数を減らすために、イベントを追跡することは理にかなっています。

 Objective-C: #import "RNTableViewManager.h" #import "RNTableView.h" @implementation RNTableViewManager RCT_EXPORT_MODULE() - (UIView *)view { return [[RNTableView alloc] initWithBridge:self.bridge]; } RCT_EXPORT_VIEW_PROPERTY(rowHeight, float) RCT_EXPORT_VIEW_PROPERTY(numRows, NSInteger) @end
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ラッパー自体はRNTableView.mで実行され、主にプロパティの転送と適切な場所でのプロパティの使用を処理します。 次の実装の詳細に立ち入る必要はありません。まだ興味深い部分が欠けているからです。

 #import "RNTableView.h" #import "RCTConvert.h" #import "RCTEventDispatcher.h" #import "RCTUtils.h" #import "UIView+React.h" @interface RNTableView()<UITableViewDataSource, UITableViewDelegate> @property (strong, nonatomic) UITableView *tableView; @end @implementation RNTableView RCTBridge *_bridge; RCTEventDispatcher *_eventDispatcher; NSMutableArray *_unusedCells; - (instancetype)initWithBridge:(RCTBridge *)bridge { RCTAssertParam(bridge); if ((self = [super initWithFrame:CGRectZero])) { _eventDispatcher = bridge.eventDispatcher; _bridge = bridge; while ([_bridge respondsToSelector:NSSelectorFromString(@"parentBridge")] && [_bridge valueForKey:@"parentBridge"]) { _bridge = [_bridge valueForKey:@"parentBridge"]; } _unusedCells = [NSMutableArray array]; [self createTableView]; } return self; } RCT_NOT_IMPLEMENTED(-initWithFrame:(CGRect)frame) RCT_NOT_IMPLEMENTED(-initWithCoder:(NSCoder *)aDecoder) - (void)layoutSubviews { [self.tableView setFrame:self.frame]; } - (void)createTableView { _tableView = [[UITableView alloc] initWithFrame:CGRectZero style:UITableViewStylePlain]; _tableView.dataSource = self; _tableView.delegate = self; _tableView.backgroundColor = [UIColor whiteColor]; [self addSubview:_tableView]; } - (void)setRowHeight:(float)rowHeight { _tableView.estimatedRowHeight = rowHeight; _rowHeight = rowHeight; } - (NSInteger)numberOfSectionsInTableView:(UITableView *)theTableView { return 1; } - (NSInteger)tableView:(UITableView *)theTableView numberOfRowsInSection:(NSInteger)section { return self.numRows; } -(CGFloat)tableView:(UITableView *)tableView heightForRowAtIndexPath:(NSIndexPath *)indexPath { return self.rowHeight; } //       @end
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

重要な概念-ネイティブ環境とJSの接続

行全体がビジネスロジックであるため、JavaScriptで定義されたReactコンポーネントにする必要があります。 しかし、それらを簡単に構成できるようにしたいのです。 実際の書き換えロジックはネイティブ環境で機能するため、これらのコンポーネントを何らかの方法でJSから「転送」する必要があります。



Reactコンポーネントをネイティブコンポーネントに子として渡すことをお勧めします。 JSのネイティブコンポーネントを使用して、子コンポーネントとしてJSXに文字列を追加すると、React Nativeはそれらをネイティブコンポーネントに表示されるUIViewビューに強制的に変換します。



秘Theは、データソースのすべての行からコンポーネントを作成する必要がないことです。 私たちの主な目標は文字列を再利用することなので、画面に表示するのに必要なのはごくわずかです。 画面に20行が同時に表示されると仮定します。 この値は、画面の高さ（iPhone 6 Plusの場合は736の論理ポイント）を各行の高さ（この場合は50）で除算し、約15の値を取得してから、いくつかの行を追加することで取得できます。



これらの20行が初期化のためにサブビューの子としてコンポーネントに渡されるとき、それらはまだ表示されていません。 私たちはそれらを「未使用のセル」のバンクに保管します。



以下が最も興味深いです。 UITableViewのネイティブ書き換えは、「dequeueReusableCell」メソッドを使用して機能します。 セルが（画面に表示されていない行から）上書きできる場合、この方法を使用して、書き換えられたセルを返すこともできます。 セルを上書きできない場合、新しいコードをメモリに配置する必要があります。 新しいセルの配置は、目に見える線で画面を埋める前の最初にのみ行われます。 では、新しいセルをメモリに配置する方法は？ 銀行の未使用のセルの1つを取得します。

  - (void)insertReactSubview:(UIView *)subview atIndex:(NSInteger)atIndex { //        subview,        // [super insertSubview:subview atIndex:atIndex]; [_unusedCells addObject:subview]; } - (UIView*) getUnusedCell { UIView* res = [_unusedCells lastObject]; [_unusedCells removeLastObject]; if (res != nil) { res.tag = [_unusedCells count]; } return res; } - (UITableViewCell *)tableView:(UITableView *)theTableView cellForRowAtIndexPath:(NSIndexPath *)indexPath { static NSString *cellIdentifier = @"CustomCell"; TableViewCell *cell = (TableViewCell *)[theTableView dequeueReusableCellWithIdentifier:cellIdentifier]; if (cell == nil) { cell = [[TableViewCell alloc] initWithStyle:UITableViewCellStyleDefault reuseIdentifier:cellIdentifier]; cell.cellView = [self getUnusedCell]; NSLog(@"Allocated childIndex %d for row %d", (int)cell.cellView.tag, (int)indexPath.row); } else { NSLog(@"Recycled childIndex %d for row %d", (int)cell.cellView.tag, (int)indexPath.row); } //      … return cell; }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

パズルの最後の要素は、データソースからのデータで新しい上書き/作成されたセルを埋めることです。 シリーズはReactコンポーネントであるため、このプロセスをReactの用語に変換します。表示するデータソースの正しい行に基づいて、行のコンポーネントに新しいプロパティを割り当てる必要があります。



プロパティの変更はJS環境で発生するため、JavaScriptで直接これを行う必要があります。 これは、いずれかのシリーズのバインディングを返す必要があることを意味します。 これを行うには、イベントをネイティブ環境からJSに渡します。



これは、関数の完全な実装であり、不足している部分がすべて含まれています。

  - (UITableViewCell *)tableView:(UITableView *)theTableView cellForRowAtIndexPath:(NSIndexPath *)indexPath { static NSString *cellIdentifier = @"CustomCell"; TableViewCell *cell = (TableViewCell *)[theTableView dequeueReusableCellWithIdentifier:cellIdentifier]; if (cell == nil) { cell = [[TableViewCell alloc] initWithStyle:UITableViewCellStyleDefault reuseIdentifier:cellIdentifier]; cell.cellView = [self getUnusedCell]; NSLog(@"Allocated childIndex %d for row %d", (int)cell.cellView.tag, (int)indexPath.row); } else { NSLog(@"Recycled childIndex %d for row %d", (int)cell.cellView.tag, (int)indexPath.row); } //     JS NSDictionary *event = @{ @"target": cell.cellView.reactTag, @"childIndex": @(cell.cellView.tag), @"rowID": @(indexPath.row), @"sectionID": @(indexPath.section), }; [_eventDispatcher sendInputEventWithName:@"onChange" body:event]; return cell; }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

すべてまとめて

さらに、RecyclingListView.jsの最終的な実装には、JavaScriptのネイティブコンポーネントのバインディングが必要です。

 import React, { Component } from 'react'; import { requireNativeComponent, View } from 'react-native'; import ReboundRenderer from './ReboundRenderer'; const RNTableViewChildren = requireNativeComponent('RNTableViewChildren', null); const ROWS_FOR_RECYCLING = 20; export default class RecyclingListView extends Component { constructor(props) { super(props); const binding = []; for (let i=0; i<ROWS_FOR_RECYCLING; i++) binding.push(-1); this.state = { binding: binding // childIndex -> rowID }; } render() { const bodyComponents = []; for (let i=0; i<ROWS_FOR_RECYCLING; i++) { bodyComponents.push( <ReboundRenderer key={'r_' + i} boundTo={this.state.binding[i]} render={this.props.renderRow} /> ); } return ( <View style={{flex: 1}}> <RNTableView style={{flex: 1}} onChange={this.onBind.bind(this)} rowHeight={this.props.rowHeight} numRows={this.props.numRows} > {bodyComponents} </RNTableView> </View> ); } onBind(event) { const {target, childIndex, rowID, sectionID} = event.nativeEvent; this.state.binding[childIndex] = rowID; this.setState({ binding: this.state.binding }); } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

追加したい別の最適化は、再描画の回数を最小限にすることです。 つまり 行が上書きされ、バインディングが変更された場合にのみ、行を再描画する必要があります。



このためには、ReboundRendererが必要です。 この単純なJSコンポーネントのパラメーターとして、このコンポーネントが現在バインドされているデータソースの行のインデックスが取得されます（パラメーター "boundTo"）。 バインディングを変更するときにのみ再描画します（標準の最適化shouldComponentUpdateを使用）：

 var React = require('React'); var ReboundRenderer = React.createClass({ propTypes: { boundTo: React.PropTypes.number.isRequired, render: React.PropTypes.func.isRequired, }, shouldComponentUpdate: function(nextProps): boolean { return nextProps.boundTo !== this.props.boundTo; }, render: function(): ReactElement<any> { console.log('ReboundRenderer render() boundTo=' + this.props.boundTo); return this.props.render(this.props.boundTo); }, }); module.exports = ReboundRenderer;
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ここにコードを含む大部分の完全に機能する例は、 このリポジトリにあります 。

リポジトリには、興味のある他のいくつかの実験の説明も含まれています。 tableview-children.ios.js実験もこのケースに適用されます。



Tal Kolは、iOSおよびAndroid用のネイティブモバイルアプリの開発を専門とするフルスタックの開発者です。 React Nativeは彼の新しい趣味です。 Talは2つのテクノロジー企業の共同設立者であり、そのうちの1つは現在Wix.com サイトを作成するためのプラットフォームに属しています 。



元の記事： Wix Engineers Blog