NSTableViewを再利用しないようにする方法TableCellViews

Question

ビューベースのNSTableviewは、以前に生成された範囲外にスクロールされたTableCellViewを再利用しないようにしたいと思います。私はdequeueReusableCellWithIdentifier：を上書きしてnilを返すことで、これがUITableViewで可能になると考えています。私はNSTableView同様のソリューションですか？

-

私の背景：私は（つまりテーブル内容、-selectionと-sortdescriptorがarraycontrollerとtableCellView要素にバインドされている通常の方法でManagedObjectsに結合している、非常に複雑なビューベース-のtableViewを持っていますobjectValueにバインドします）。

表には、約20列ありますが、最大400行です。スクロールは実際には遅いですが、時間プロファイリングは、単一の遅れの原因が存在しないことを示します（最大の単一メソッド呼び出しには約5％の時間がかかります）。私のManagedObjectの派生した/カスタムのプロパティをパフォーマンスを大幅に向上させることなくキャッシュした後、ビューがキャッシュに入れようとしています（ビューがスコープに入ったときにtablecellViewの頻繁な再バインドを避けるため）。

私は現時点ではテーブルコンテンツをバインドしないようにしていますが、NSDatasource-protocolを使用してビューを取得しています。そこに

-(NSView*) tableView:(NSTableView *)tableView viewForTableColumn:(NSTableColumn *)tableColumn row:(NSInteger)row 

私は存在する場合、キャッシュされたTableCellViewsを返したいと思います。そうでなければ私は

[self.table makeViewWithIdentifier:... owner:self]; 

を経由して新しいものを作成makeViewWithIdentifierはすでに私がキャッシュされているビューを返すことがありますので、テーブル・コンテンツが間違った細胞を台無しにされます。

パフォーマンスが...このアプローチで有意に良好

ある - よりパフォーマンススクロール作ることに

他のアイデアもにappriciatedされています。

Answer 1

あなたのtableView：viewForTableColumn：実装では、返されたビューの.identifierをnilに設定します。これにより、テーブルにキャッシュされません。自分のキャッシュを管理することができます。 FWIWでは、makeViewWithIdentifierを使用する必要はありません。その方法を使用する代わりに手動でビューを手動で作成することができます（NIBからプレセットアップビューをロードする）。

ただし、パフォーマンスに問題がある場合は、遅い理由と理由を確認して対処する方がよいでしょう。あなたはなぜそれが遅いのかに関する情報を提供しなかったので、何をすべきかを言うのは難しいです。 20列はたくさんあります。 canDrawSubviewsIntoLayer、NSTableCellView、またはNSTableRowViewを使用してレイヤー数を減らすと、パフォーマンスが向上する場合があります。しかし、これを行うときに注意すべきことがたくさんあります。

コービン