ネイティブアプリケーションは、ビュー内の多数のノードをどのように処理しますか？

Question

私はウェブ開発者です。現在の課題の1つは、シングルページアプリケーション（SPA）への移行とこれがもたらす課題です。たとえば、無限のスクロールを実装すると、ブラウザにレンダリングされた何百ものドキュメントオブジェクトモデル（DOM）ノードで簡単に見つけることができます。

その後、すべてを変更する必要がある場合は、パフォーマンスが大幅に低下する可能性があります。これは、Reactのようなライブラリが人気を得た理由、つまり仮想DOMを部分的にもたらす理由です。

仮想DOMはDOMツリー全体の仮想表現を作成し、変更が行われるたびに古い状態と新しい状態を比較し、変更されたノードのみを更新します。ハイブリッドアプリケーションフレームワークであるIonicは、パフォーマンスを向上させるためには見えないノードを隠す、無限のスクロールのための独自のソリューションを備えています。

私は、ネイティブのアプリケーションは、ビュー内の多数のノードにどのように対処しているのだろうと思いましたか？フィードを持つソーシャルアプリは、数秒間スクロールするとその数に達することができます。それはOSによって処理されますか？それはまったく問題なのでしょうか？

Answer 1

ベストプラクティスを遵守しないと問題になります。可変イメージを非同期にロードするか、レイアウトを可能な限りフラットに保つこと。リストビューについては、ViewHolderテクニック。

AndroidのList実装は、通常、提供されたデータセットのコンテンツの数だけインスタンス化するのではなく、画面に収まるように多くの（そして余分な）部分をインスタンス化します。ビューが画面から消えると、ListViewはそのインスタンスをキャッシュし、データセットからの新しいエントリが表示されるべきときにそれを返します。次に、モデルからの値を、提供されたビュー（またはそれに関連するViewHolderの方が良い）に配置し、それを完了します。

データセットが頻繁に変更されたり、単純に巨大になる場合は、他の問題が発生する可能性があります。データセット内の項目が変更された場合は、ListView全体が再描画されず、変更されたビューのみが再描画されることになります。古いリストの実装ではこれを処理できません。何かが変更された場合、リスト内のすべての表示可能なビューが再描画されます。 RecyclerViewのような現代的なリストの実装には、この制限はありません。 ViewHolder技術を強化するだけでなく、RecyclerViewにどのアイテムが変更されたかを伝えるメソッドを提供し、効率的な再描画魔法を引き出すことができます。

データセットが大きい場合は、メモリまたはパフォーマンスの制限を回避する最も良い方法は、データセットから最新のアイテムをロードして、より多くのデータを読み込むようにすることです。またはページング。

だから、フレームワークはほとんどの場合に役立ちます。しかし、物事を混乱させるだけの十分な余裕があります。