关于NSCELL

  作为一个初学者,我一直很弄不明白NSCell的子类,比如,NSButtonCellNSImageCell及其对应的控件之间的关系。今天,在做一个TableView实现的时候,我终于开始有点悟了——好吧,你大可以鄙视我,我的脑袋是不灵光。尽管这是一个简单的问题,但是我还是简单的记录一下我的理解。

  问题的起源是“Cocoa Programming For Mac OS X”上一段关于NSCell的叙述:

NSControl inherits from NSView. With its graphics context, NSView is a relatively large and expensive object to create. When the NSButton class was created, the first thing someone did was to create a calculator with 10 rows and 10 columns of buttons. The performance was less than it could have been because of the 100 tiny views. Later, someone had the clever idea of moving the brains of the button into another object (not a view) and creating one big view (called an NSMatrix) that would act as the view for all 100 button brains. The class for the button brains was called NSButtonCell.

— Chapter 17. Custom Views, “For the More Curious: Cells”

现在在此阅读这句话,我似乎已经能够基本理解,不过当时那叫一个困惑啊。为什么用Cell就比Button性能高呢?为什么Cell可以替代Button呢?

我的理解如下(可能并不是很精确):

  • NSButton的继承关系是:NSButton –> NSControl –> NSView –> NSResponder –> NSObject。应该说,是一个很长的继承链了。
  • NSButtonCell的继承关系是:NSButtonCell –> NSCell –> NSObject

比之NSButton,少了两层继承关系。光凭这一点大致就能够解释为什么Cell的性能比Control高很多了。

但是既然Cell和Control都代表了“控件”,那么两者又是怎样的关系呢?

查阅了苹果的文档之后,就发现里面有这么一句话:“The NSButton class uses NSButtonCell to implement its user interface.”

这么一来,一切都清楚了,NSCell是控件的UI显示部分。但是NSCell不是NSView的子类,它又怎么显示自己呢?在NSButton的文档里,又有下面的一段话:

NSButton and NSMatrix both provide a control view, which is needed to display an NSButtonCell object. However, while NSMatrix requires you to access the NSButtonCell objects directly, most of the NSButton class’ methods are “covers” for identically declared methods in NSButtonCell. (In other words, the implementation of the NSButton method invokes the corresponding NSButtonCell method for you, allowing you to be unconcerned with the existence of the NSButtonCell.)

这段话的大意是:

NSButtonNSMatrix能够为NSButtonCell提供一个控制视图,用来实现Cell的显示。不过NSMatrix需要直接操作NSButtonCell对象,而NSButton则不需要。因为它已经“封装”了所有NSButtonCell的同名方法。也就是说,对NSButton调用方法(不是所有的方法),实际上是对NSButtonCell调用方法,调用的时候,我们甚至可以无需知道NSButtonCell的存在。

至此,问题解决。甚至,以前没有联系起来的一个问题也解决了:那就是,为什么在Interface Builder中,NSButton总是和NSButtonCell同时存在的——原因,当然也是上面的那段话啦~另外,在Interface Builder里,NSButtonNSButtonCell的Inspector里的属性也基本相同,也是因为上述原因。

一点题外话:

UIKit里没有NSCell的对应类。原因并不是很清楚。不过UIKit里的类的继承结构也与AppKit有所不同。比如,NSTableView的列:NSTableColumn采用的是Cell的显示机制;而UITableView则采用的是UITableViewCell。前者继承自NSObject,后者继承自UIView

关于这样的区别在性能上的差别,我不敢妄下结论,也没法随便比较——毕竟是两个不同平台。似乎在iOS平台上,UITableView的Cell会在离开显示区域的时候被release掉——这可能是为什么iOS平台没有采用UICell(没有这个类的!!!)的原因之一。

不过,我感觉UITableViewNSTableView更加灵活,自定义也更加方便——因为每个UITableViewCell可以很方便的用一个Custom View来做界面;而NSTableColumn则依赖于NSCell,要自定义,需要用自定义NSCell的子类,这样会复杂很多。

本文转载自 http://cocoa.venj.me/blog/about-nscell/

关于NSCELL

时间: 2024-10-07 05:14:37

关于NSCELL的相关文章

消息传递机制

每个应用或多或少都由一些需要相互传递消息的对象结合起来以完成任务.在这篇文章里,我们将介绍所有可用的消息传递机制,并通过例子来介绍怎样在苹果的框架里使用.我们还会选择一些最佳范例来介绍什么时候该用什么机制. 虽然这一期的主题是关于 Foundation 框架的,但是我们会超出 Foundation 的消息传递机制 (KVO 和 通知) 来讲一讲 delegation,block 和 target-action 几种机制. 当然,有些情况下该使用什么机制没有唯一的答案,所以应该按照自己的喜好去试试

iOS中消息的传递机制(KVO、Notification、delegation、block以及target-action)---转载

注1:本文由破船[博客]译自Communication Patterns. 本文目录如下所示: 可用的机制 做出正确的选择 Framework示例 小结 每个应用程序或多或少,都由一些松耦合的对象构成,这些对象彼此之间要想很好的完成任务,就需要进行消息传递.本文将介绍所有可用的消息传递机制,并通过示例来介绍这些机制在苹果的Framework中如何使用,同时,还介绍了一些最佳实践建议,告诉你什么时机该选择使用什么机制. 虽然这一期的主题是关于Foundation Framework的,不过本文中还

iOS:Cocoa编码规范 -[译]Coding Guidelines for Cocoa

--原文地址:https://developer.apple.com/library/mac/documentation/Cocoa/Conceptual/CodingGuidelines/Articles/FrameworkImpl.html Cocoa编码规范 --前言 用公共API开发一个Cocoa框架,插件,或其他可执行目标,里面的命名编写和规范不同于一般应用程序的开发.因为你开发出来东西是给开发者用的看的,并且他们不熟悉你的编程接口.这个时候API的命名约定就派上用场了,因为它使你的写

ios面试题整理(答案有的是网上找的,有的是根据理解自己做的)

1.ViewController的生命周期 按结构可以对iOS的所有ViewController分成两类: 1.主要用于展示内容的ViewController,这种ViewController主要用于为用户展示内容,并与用户交互,如UITableViewController,UIViewController. 2.用于控制和显示其他ViewController的ViewController.这种ViewController一般都是一个ViewController的容器.如UINavigation

iOS开发(OC)中的命名规范

开小差:最近发现自己有一个经验主义的毛病,不太容易接受新的知识,这对从事技术研发的人来说不太合理,需要改之. 正文:通过读写大量代码我有自己的一套编程思路和习惯,自认为自己的编码习惯还是不错的,代码结构也算清晰,因为我一直以来都是代码看的多写的多,但是总结的比较少,知识经常不成体系.以后多花点时间把自己的经验和学习知识加以总结一下吧,这样有利于去指导新人,也更有利于加深自己的知识认知.今天就从代码规范入手总结一下iOS开发中好的编码规范吧.我们在开发中看别人的代码的时候经常会去抱怨至少内心里骂娘

IOS OS X 中集中消息的传递机制

1 KVO (key-value Observing) 是提供对象属性被改变是的通知机制.KVO的实现实在Foundation中,很多基于 Foundation 的框架都依赖与它.如果只对某一个对象的值的改变感兴趣的话.就可以使用KVO消息传递.满足KVO的前提条件:1接受者(接受对象改变的通知的对象)需要知道发送者(值会改变的对象):2,接受者需要知道发送者的生命周期,因为它需要在发送者被销毁前注销观察者身份.如果这两个要求都符合的话,这个消息传递机制可以一对多(多个观察者可以注册同一个对象的

macOS开发之NSTableView的应用详解 - 转

传送门:https://my.oschina.net/u/2340880/blog/886861 摘要: NSTableView是AppKit中的表视图控件,是macOS开发中非常重要的一种视图控件.熟练应用NSTableView控件对mac软件开发十分重要. NSTableView的应用详解 一.引言 和iOS开发中的UITableView有很大差别,NSTableView并非是一个可滚动的列表视图,其是一个不可滚动.支持多列多行的原始列表视图.若要使NSTableView支持滚动,通常会将其

iOS消息机制

每个应用程序或多或少,都由一些松耦合的对象构成,这些对象彼此之间要想很好的完成任务,就需要进行消息传递. 一下是所有可用的消息传递机制: Core Data managed object context是notification的发送者,而获取这些notification的主体则是接收者.一个滑块(slider)是action消息的发送者,而在代码里面对应着实现这个action的responder就是接收者.对象中的某个属性支持KVO,那么谁修改这个值,谁就是发送者,对应的观察者(observe

ios下划线变量:为什么变量前要加下划线才有用?

先看一段代码. 复制代码 appdelegate.h @property (weak) IBOutlet NSMatrix *StockType; @property (weak) IBOutlet NSMatrix *market; appdelegate.m NSCell *st=[market selectedCell]; 编译时,总是提示,找不到market变量,但是StockType却没问题. 如果根据系统建议,在market前加上下划线,变成_market却可以正常编译和执行.  但