NSCell vs NSView：当需要很多控件时答案

【问题标题】：NSCell vs NSView: when many controls are neededNSCell vs NSView：当需要很多控件时
【发布时间】：2014-11-28 13:54:17
【问题描述】：

我知道 Apple 不赞成使用 NSCell 以支持 NSView（请参阅 AppKit 10.10 发行说明）。以前建议在需要许多控件时使用 NSCell 以提高性能。

我花了相当多的时间来实现一个需要许多子视图的自定义控件，并且使用 NSView 类型的子视图的性能并不好。请参阅related stackoverflow discussion 就一个窗口中可以拥有的 NSView 类型实例的数量而言，实际限制是什么？我一直在努力处理 1000-2000 个内存对象（这似乎不是很多）。 造成这种限制的真正原因是什么？

上面让我感到困惑的是基于视图的 Cocoa NSTableViews。您可以创建超过 1000-2000 个单元格的 tableViews，而且它们似乎没有很差的加载和滚动性能？ 如果每个单元格都是一个 NSView，那么这是如何实现的？

如果有实际限制，那么当 Apple 说他们不赞成使用 NSCell 时，他们在想什么？我相信他们知道某些控件需要大量的子视图。

此外，（可能已过时）Apple Developer Guide 对 NSView 和 NSCell 之间的区别给出了以下解释，我需要进一步解释：

“由于单元格比控件更轻，因此在继承数据和行为方面，使用多单元格控件比使用多个控件更有效。”

继承的数据：这肯定只会在使用数据时导致“膨胀”=>并且只会在您需要时使用它？

继承的行为：你不在类/对象中使用的方法肯定不会造成任何开销？

轻量级 NSCell 与重量级 NSView 之间的真正区别是什么？（我真的很想知道。）

【问题讨论】：

NSCell 的“亮度”与他们的许多绘图为重用而优化有关，而不是实例的大小。
@CodaFi 他们的绘图如何优化以供重复使用？每个都有自己的“draw”方法，类似于 NSView 的 drawRect。
别太担心。如果杀死 NSCell，仍然有很多代码会中断。它只是口头上非正式地弃用。 NSTableView 尝试在重用池中回收视图。绘图曾经是功能不如 iPhone (Next cube) 的机器的天意，但现在已经不是这样了。
@uchuugaka 我听到你关于 NSCell 弃用的消息。如果机器现在如此强大，那么为什么我的计算机会为 1000-2000 个 NSView 子视图而苦苦挣扎？这是否表明使用 NSViews 的方法很好但我做错了什么？
可能。这将是一次大量的视图。特别是如果他们经常绘制或布局。虽然其中一部分很容易成为绘图代码。但是有这么多视图可以优化任意数量的区域。

标签： objective-c cocoa swift nscell

【解决方案1】：

上面让我感到困惑的是基于视图的 Cocoa NSTableViews。您可以创建超过 1000-2000 个单元格的 tableViews，并且它们似乎没有很差的加载和滚动性能？如果每个单元格都是一个 NSView 那么这是如何实现的呢？

NSTableViews 重用视图。实际生成的唯一视图是那些可见的，再加上可见区域上方的一行视图和可见区域下方的一行。滚动表格时，与给定视图行关联的对象值更改为该行中的视图将显示不同的内容

【讨论】：

【解决方案2】：

一个简短且不完整的答案：

NSCells 是关于绘制状态的，仅此而已。 NSView 必须绘制，还必须维护和更新各种其他信息，例如它们的布局、响应用户输入事件等。

考虑调整包含数百个子视图的视图大小时必须发生的计算量：必须根据视图布局的现有约束来维护每个子视图的位置和大小。仅此一项很快就会进行大量的处理。

相比之下，NSCell 不以这种方式存在于布局中。他们唯一的工作是在被要求时在给定的矩形中绘制信息。

【讨论】：

我遇到了同样的问题，我认为 Apple 不再关心具有大量视图的高密度信息显示。这一切都针对低密度网络进行了优化，例如现在寻找移动应用程序。 NSCell 没有死。即使是 6 年后。