1

Web サービスからのデータを入力する UITableView があります。循環バッファを使用して新しいデータをキャッシュし、古いデータを削除するため、メモリが過負荷になることはありません。すべての魔法は、テーブル ビューが cellForRowAtIndexPath を呼び出し、ビュー コントローラーがバッファーを参照してデータを取得するときに発生します。また、正しい実装は、セルが画面に表示されるときにのみテーブル ビューがそのメソッドを呼び出すという事実に依存しています。データが利用可能な場合はビュー コントローラーに返し、そうでない場合は nil を返します。ビュー コントローラーは処理方法を認識しており、必要なデータのフェッチを開始します。フェッチが完了したら、テーブルで「reloadData」を呼び出すと、データが表示されます。

ユーザーが200行目までスクロールしたとしても、テーブルビューはビューコントローラーにインデックスパス0または1の行を要求します。その時点で、バッファの実装とサイズを考えると、表示される内容は間違っています。

説明のために、 cellForRowAtIndexPath 内からのデバッガー出力を使用します。

 po indexPath <NSIndexPath: 0xb02b100> {length = 2, path = 0 - 0}

 po [self.tableView indexPathsForVisibleRows] <__NSArrayM 0x9b8f7f0>( <NSIndexPath: 0x9b42910> {length = 2, path = 0 - 19}, <NSIndexPath: 0x9b82080> {length = 2, path = 0 - 20}, <NSIndexPath: 0x9b6e2a0> {length = 2, path = 0 - 21}, <NSIndexPath: 0x9b39010> {length = 2, path = 0 - 22}, <NSIndexPath: 0x9b42d80> {length = 2, path = 0 - 23}, <NSIndexPath: 0x9b98a20> {length = 2, path = 0 - 24}, <NSIndexPath: 0x9b9dc50> {length = 2, path = 0 - 25}, <NSIndexPath: 0x9b9e4d0> {length = 2, path = 0 - 26}, <NSIndexPath: 0x9b40740> {length = 2, path = 0 - 27}, <NSIndexPath: 0x9b40750> {length = 2, path = 0 - 28}, <NSIndexPath: 0x9b88150> {length = 2, path = 0 - 29}, <NSIndexPath: 0x9b88160> {length = 2, path = 0 - 30}, <NSIndexPath: 0x9b97120> {length = 2, path = 0 - 31}, <NSIndexPath: 0x9b97130> {length = 2, path = 0 - 32}, <NSIndexPath: 0x9b44cf0> {length = 2, path = 0 - 33}, <NSIndexPath: 0x9b44d00> {length = 2, path = 0 - 34}, <NSIndexPath: 0x9b8d580> {length = 2, path = 0 - 35}, <NSIndexPath: 0x9b8d590> {length = 2, path = 0 - 36} )

誰もそのような奇妙な問題に遭遇したことがありますか?

4

1 に答える 1

0

テーブル ビューの cellForRowAtIndexPath: は、表示する必要があるセルのみを取得するために呼び出されるわけではありません。テーブル ビューは通常、いくつかの余分なセルを取得して、ユーザーがスクロールしたときに準備ができるようにします。

自分自身を納得させるために、cellForRowAtIndexPath: の戻り値をログに記録します。6 つのセルが表示されている場合は、cellForRowAtIndexPath: が 6 回以上呼び出されているに違いありません。

于 2013-11-01T23:51:29.133 に答える