cellForRowAtIndexPath は可視セルのみをロードすることを知っています。その上下の3つのセルをロードするように強制する方法はありますか?
2 に答える
いいえ、cellForRowAtIndexPath
現在のセルのみをロードします。
あなたの質問は、あなたがあなたの中で計算的に高価であるか遅い何かをしていることを示唆していますcellForRowAtIndexPath
。たとえば、画像の遅延読み込みを実行しているが、ユーザーの遅延読み込みのエクスペリエンスを低下させるために、候補の「次の」セルに必要な画像の一部を「プリフェッチ」したい場合があります。ただし、一般的には、実際にはUITableViewCell
オブジェクト自体をプリフェッチするのではなく、それらのセルに必要なデータの断片だけをプリフェッチします。
プリフェッチする必要があると感じるものの種類について、より多くの情報を提供する必要があるかもしれません。私たちはより良い助言を提供することができます。これは重要な問題であり、ビューを表示するときにコントローラーが使用する適切に設計されたモデルがあることを条件としています。モデルと、前の3つのセルと次の3つのセルに用意されていることを確認したいものの性質について少し共有することをお勧めします。
UITableViews usually take care themselves of the whole process of deciding when to load specific cells. They automatically remove invisible cells from it, sometimes storing those cells in an internal reusability queue.
UITableView provides a mechanism you can use to speed up the cell creation process by retrieving pre-alloc'd cells when available. If you use this method properly you should have no trouble with the scrolling speed in your table views. To do so, you need to configure the reusabilityIdentifier for a cell on creation, and call the method -[UITableView dequeueReusableCellWithIdentifier:]
when you need a new cell in your cellForRowAtIndexPath:
implementation.
It should be feasible for you to have your own queue of reusable and preconfigured cells if you still need more speed - although the advantages you can get from implementing something like this remain to be seen (you'd have more rows ready to use, but would also slow down cellForRowAtIndexPath:
for the cell being requested). You would also need to be very careful not to clash with UITableView's standard queue.
Check out Apple's UITableView reference for more info on the reusability mechanism.