比較的「重い」カスタム テーブル ビュー セルを含むテーブル ビューを使用します。たとえば、1 つのセル (完全な階層) に約 100 のサブビューがあるとします。それにもかかわらず、私は非常にスムーズなスクロールに到達できました-不透明なビューのみで作業する、未使用のサブビューを非表示にする(またはビュー階層から削除する)、セルの高さを事前にロードするなどの標準的な方法を使用します.
問題は、単一のセル インスタンスを作成するのにまだ比較的コストがかかることです。標準の UITableView のセル再利用ロジックがどのように機能するかにより、この問題は特定の条件でのみ顕著になります。
通常、テーブル ビューが読み込まれると (そして最初のコンテンツが表示されると)、必要なほとんどすべてのセル インスタンスが作成されます。しかし、何らかの理由で最初にいくつかのセルしか表示されない場合は、スクロールが開始されたときに明らかにより多くのセルを作成する必要があります。私の場合、これは、幅の広いテーブル ビュー ヘッダーがある場合、または最初のセルが十分に大きい場合に顕著です。スクロールを開始すると、それが発生すると、新しいセル インスタンスが作成されることが原因であることが明らかな、しばらくの間顕著な遅延が発生します。その後の完全にスムーズなスクロールと比較して、特に醜いものは何もありませんが、それでも目立ちます。
そのための明らかな解決策は、セルを「軽く」することです。たとえば、セルをより具体的なさまざまなタイプに分割して、それぞれに含まれるサブビューを減らすことができます。しかし、私のコンテンツが整理されているため、非常に複雑なソリューションになります。
だから私の質問は - 実際に表示されているセルの数にもかかわらず、特定の数の再利用可能なセルインスタンスのロードとキャッシュをすぐに強制するためにテーブルビューロジックを「だます」良い方法はありますか?
私が考えているオプションの 1 つは、セルの明示的なキャッシュを独自に用意し、必要に応じてセルを事前に取り込むことです (-viewDidLoad など)。このアプローチで私が抱えている問題は、必要な細胞の正確なタイプを事前に知っておく必要があることです-私にとってはうまくいきません. 改善は、初期データがロードされるときにキャッシュを構築することです (したがって、少なくともコンテンツの正確なタイプがわかっています) が、単純なオプションがあるかどうか疑問に思っていました。