2

動的コンテンツに基づいてUITableViewCellの高さを設定しようとしています。ビューコントローラのheightForRowAtIndexPathデリゲートメソッドを使用して高さを「設定」できることは知っていますが、それはできません。

問題は、cellForRowAtIndexPathが呼び出されるまでセルの高さがわからず、cellForRowAtIndexPathの前にheightForRowAtIndexPathが呼び出されることです。

したがって、これら2つのメソッドが呼び出される順序を逆にするか、セルの高さを設定する別の方法を見つける必要があります。

何か案は？

4

1 に答える 1

0

申し訳ありませんが、これらのメソッドなどを逆にする組み込みの方法はありません。理由の1つは、テーブルビューがさまざまな理由で行の高さを知りたい場合があることです。そのすべてにセルの表示が含まれるわけではありません-tableView:heightForRowAtIndexPath:。複数回呼び出されたり-tableView:cellForRowAtIndexPath:、呼び出し後にまったく呼び出されなかったりする場合があります。高さ法。

あなたができることは、事前に適切な高さを計算し、それをキャッシュし、そのキャッシュされた値に依存する別の方法を見つけることです-tableView:heightForRowAtIndexPath:。「ダミー」のUITableViewCellインスタンスを作成し、それを通常の再利用キューから除外し、レイアウトと高さの決定の目的で使用することで、同様のことを行うことができました。このようなソリューションは、次のようになります。

  1. 取得し-tableView:heightForRowAtIndexPath:ます。
  2. 高さキャッシュでインデックスパスを検索します。値がある場合は、それを返します。
  3. それ以外の場合は、ダミーセルを使用して、そのインデックスパスに表示されるコンテンツをレイアウトします。セルの高さを測定し、キャッシュします。
  4. 呼び出される量に応じて、手順1〜3を数回繰り返す可能性があります-tableView:heightForRowAtIndexPath:。
  5. 取得し-tableView:cellForRowAtIndexPath:ます。
  6. 通常の再利用キューからセルをデキューし、データを入力してレイアウトし、返却します。（テーブルビューが期待どおりに動作するように、その高さが事前に計算された高さと一致することを確認することを選択できます。）

セルの内容とユースケースでの「レイアウト」というフレーズの複雑さによっては、最初のいくつかの高さを計算したり、ユーザーがテーブルビューをすばやくスクロールしたりすると、パフォーマンスが大幅に低下する可能性があります。ただし、キャッシュがウォームアップするにつれて、アプリの実行を継続するにつれて、計算する高さはますます少なくなるはずです。

tableView.rowHeight最後のポイント：デフォルトの高さのセル（テーブルに表示される場合と表示されない場合があります）の場合、表示されるたびにデフォルトの高さを計算するのではなく、を返すことで早期に終了できることを覚えておいてください。これにより、上記のアプローチの計算負荷をいくらか軽減できます。

于 2013-01-17T23:16:42.310 に答える