8

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

-

私の背景:通常の方法でManagedObjectsにバインドされた非常に複雑なview-based-tableViewがあります(つまり、table-content、-selection、-sortdescriptorはarraycontrollerにバインドされ、tableCellView-elementsはobjectValueにバインドされます)。

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

現在私が試しているのは、テーブルコンテンツをバインドするのではなく、NSDatasource-protocolを使用してビューを取得することです。そこに

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

キャッシュされたTableCellViewsが存在する場合は、それらを返したいのですが。それ以外の場合は、を介して新しいものを作成します

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

makeViewWithIdentifierは、すでにキャッシュされているビューを返す可能性があるため、テーブルの内容が間違ったセルで混乱します。

このアプローチを使用すると、パフォーマンスが大幅に向上します...

-

スクロールのパフォーマンスを向上させるための他のアイデアも適用されます。

4

1 に答える 1

11

tableView:viewForTableColumn: 実装で、返されたビューの .identifier を nil に設定します。これにより、テーブルがキャッシュされなくなります。その後、独自のキャッシュを管理できます。FWIW、 makeViewWithIdentifier: を使用する必要さえありません。その方法 (NIB から事前設定ビューをロードする) を使用する代わりに、ビューを最初から手動で作成することができます。

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

コービン

于 2015-05-28T03:54:44.347 に答える