对于读取操作使用self.fooBar,我觉得这是浪费时间。这会导致不必要的Objective-C消息传递。getter通常只是简单地传递ivar,所以只要可以确定不会编写合理的getter方法,那么绕过这个重量级的东西是完全可以的。
Objective-C消息传递比直接调用慢大约20倍。因此,如果有一些高性能、高频率的代码正在使用数百个属性,也许避免不必要的Objective-C消息传递确实会有很大帮助?
还是说我在浪费时间思考这个问题?
使用属性getter比直接访问要慢得多。属性getter在self类(和类别)以外的封装中很有用,但是我认为除非你已经将getter重写为其他内容,否则使用self.ivar
getter没有任何好处。
(而且你为什么要首先使用self.ivar
?)
唯一的情况是self.ivar
与self->ivar
不同的情况:
The property is atomic
, so self.ivar
will be similar to
spin_lock(&ivar_lock);
id retval = [ivar retain];
spin_unlock(&ivar_lock);
return [retval autorelease];
for an id
property, and
spin_lock(&ivar_lock);
spin_lock(&destination_lock);
memcpy(&destination, &ivar, sizeof(ivar));
spin_unlock(&ivar_lock);
spin_unlock(&destination_lock);
for a struct. There is no difference between the two when the property is nonatomic
.
When the class is not final. A category of the class or a subclass can override the property getter to something else. But I think overriding a concrete property is not a good style.
就像其他人所说的那样,除非您已经测试了getter是一个热点,否则将其改回直接ivar访问不会有太大帮助。
不冒犯,但你可能在浪费时间思考这个问题。除非你的代码每秒访问该属性数千次,否则你不会看到任何性能差异。
它的效率略微降低了一点,但通常你仍然不应该将对象状态公开。虽然在大多数面向对象语言中,公共成员被认为是不好的,但在Objective-C中实际上有一个实用的原因:框架使用您的“getter”和“setter”方法来使某些事情自动化,例如内存管理和KVO通知。对于从多个地方访问的ivars,每个客户端代码都需要完全理解访问器方法承担的所有责任,并以完全相同的方式执行这些职责。
所以并不是“绝对不要访问自己的ivars”,而是要确保您充分了解在特定情况下它所涉及的内容。