0

この記事のGitHub プロジェクトを確認してください。カスタムセル(JKCallbacksTableViewCellクラス)のprepareForReuseメソッドにより、 tableViewCellIsPreparingForReuseメソッドで監視するテーブル(RootViewControllerクラス)に通知が送信されます。このメソッドは、関連付けキーとセルのイメージ ビューをリセットします。

では、テーブルのdequeueReusableCellWithIdentifierメソッドから nil 以外のセルを取得した後に、作成者がセルをリセットするのではなく、通知を通じて送信することを好んだのはなぜですか?

UITableViewCell のドキュメントによると、 prepareForReuse は dequeueReusableCellWithIdentifier の直前に呼び出されます。

UITableViewCell オブジェクトが再利用可能な場合 (つまり、再利用識別子がある場合)、このメソッドは、オブジェクトが UITableView メソッド dequeueReusableCellWithIdentifier: から返される直前に呼び出されます。

テストしたところ、dequeueReusableCellWithIdentifier が非 nill 値を返す場合、prepareForReuse の呼び出しと結合されます。

著者は JKCallbacksTableViewCell.h でアプリケーション ロジックの分離についてコメントしましたが、それはやり過ぎだと思います。非同期ディスパッチでパフォーマンスを最適化しますが、それらの遅い通知を送信していくつかのプロパティをリセットします...または、GCDについて何か不足していますか?

4

1 に答える 1

0

ほとんどのプログラミングの問題には、無限に近い解決策があります。疎結合であるという事実以外に、通知を選択する特別な理由はありませんでした。

通知の速度に関するコメントについて: アプリを遅くする原因は画像の読み込みであるため、それを最適化しようとしてます。それ以外の場合、通知はアプリの使用に違いをもたらすほど遅くないため、純粋なパフォーマンス上の理由で他のものを使用することはここでは保証されません.

とはいえ、GitHub にあるので、通知を使用しないプル リクエストを送信してください。もっと気に入ったら、それを使用します。

于 2012-09-12T19:21:03.373 に答える