为什么要使用 ivar？

Question

我通常看到这个问题以另一种方式提出，例如 必须每个 ivar 都是一个属性？（我喜欢 bbum 对这个问题的回答）。

我几乎只在代码中使用属性。然而，我经常与一位长期从事 iOS 开发并且是传统游戏程序员的承包商合作。他编写的代码几乎没有声明任何属性，并且依赖于 ivars。我认为他这样做是因为 1.) 他已经习惯了，因为直到 Objective C 2.0（2007 年 10 月）为止属性并不总是存在，2.) 为了不通过 getter/setter 获得最小的性能增益。

虽然他编写的代码不会泄漏，但我仍然更喜欢他使用属性而不是 ivars。我们讨论过这个问题，他或多或少认为没有理由使用属性，因为我们没有使用 KVO，而且他在处理内存问题方面经验丰富。

我的问题是更多...为什么你想要使用 ivar period - 有经验的或没有经验的。使用 ivar 真的有那么大的性能差异吗？

另外，作为澄清一点，我根据需要重写 setter 和 getter，并使用与 getter/setter 内部的该属性相关的 ivar 。但是，在 getter / setter 或 init 之外，我总是使用 self.myProperty 语法。

---

编辑 1

我感谢所有好的回应。我想解决的一个似乎不正确的问题是，使用 ivar，你会得到封装，但属性却没有。只需在类延续中定义属性即可。这将使财产不被外人看到。您还可以在接口中声明该属性为只读，并在实现中将其重新定义为读写，例如：

// readonly for outsiders
@property (nonatomic, copy, readonly) NSString * name;

并在类延续中拥有：

// readwrite within this file
@property (nonatomic, copy) NSString * name;

要使其完全“私有”，只需在类延续中声明它。

Answer 1

封装

如果 ivar 是私有的，则程序的其他部分就无法轻松获取它。有了声明的属性，聪明的人就可以通过访问器很容易地访问和改变。

性能

是的，这在某些情况下会产生影响。有些程序有限制，不能在程序的某些部分使用任何 objc 消息传递（想想实时）。在其他情况下，您可能希望直接访问它以提高速度。在其他情况下，这是因为 objc 消息传递充当优化防火墙。最后，它可以减少引用计数操作并最大限度地减少峰值内存使用（如果做得正确）。

重要类型

示例：如果您有 C++ 类型，有时直接访问是更好的方法。该类型可能不可复制，或者复制可能并不简单。

多线程

您的许多 ivar 都是相互依赖的。您必须确保多线程上下文中的数据完整性。因此，您可能倾向于直接访问关键部分中的多个成员。如果您坚持使用相互依赖数据的访问器，那么您的锁通常必须是可重入的，并且您通常最终会进行更多的获取（有时会明显更多）。

程序正确性

由于子类可以重写任何方法，因此您最终可能会发现写入接口与适当管理状态之间存在语义差异。直接访问程序正确性在部分构造的状态中尤其常见 - 在初始化程序和dealloc中，最好使用直接访问。您还可能会发现这种情况在访问器、便捷构造函数、复制、mutableCopy 和归档/序列化实现的实现中很常见。

当人们从“一切都有公共读写访问器”的心态转变为隐藏其实现细节/数据的心态时，这种情况也更加频繁。有时，您需要正确地解决子类重写可能引入的副作用，以便做正确的事情。

二进制大小

当您考虑一下程序的执行时，默认情况下将所有内容声明为可读可写通常会导致许多您永远不需要的访问器方法。所以它会增加你的程序和加载时间。

最小化复杂性

在某些情况下，完全没有必要为简单变量（例如在一种方法中编写并在另一种方法中读取的私有 bool）添加+类型+维护所有额外的脚手架。

---

这并不是说使用属性或访问器不好 - 每个属性或访问器都有重要的优点和限制。与许多 OO 语言和设计方法一样，您还应该支持 ObjC 中具有适当可见性的访问器。有时你需要偏离。出于这个原因，我认为通常最好限制对声明 ivar 的实现的直接访问（例如声明它@private）。

---

重新编辑 1：

我们大多数人都记住了如何动态调用隐藏的访问器（只要我们知道名称......）。与此同时，我们大多数人没有记住如何正确访问不可见的ivars（超出KVC）。类延续有帮助，但它确实引入了漏洞。

这个解决方法很明显：

if ([obj respondsToSelector:(@selector(setName:)])
  [(id)obj setName:@"Al Paca"];

现在尝试仅使用 ivar，而不使用 KVC。

Answer 2

对我来说，通常是表现。访问对象的 ivar 与使用指向包含此类结构的内存的指针访问 C 中的结构成员一样快。事实上，Objective-C 对象基本上是位于动态分配内存中的 C 结构体。这通常是您的代码所能达到的最快速度，即使是手工优化的汇编代码也不能比这更快。

通过 getter/setting 访问 ivar 涉及 Objective-C 方法调用，这比“普通”C 函数调用慢得多（至少 3-4 倍），甚至普通 C 函数调用也已经比“普通”C 函数调用慢几倍。访问结构体成员。根据属性的属性，编译器生成的 setter/getter 实现可能涉及对函数 objc_getProperty/objc_setProperty 的另一个 C 函数调用，因为这些函数必须 <根据需要 code>retain/copy/autorelease 对象，并在必要时进一步对原子属性执行自旋锁定。这很容易变得非常昂贵，而且我并不是说慢 50%。

让我们试试这个：

CFAbsoluteTime cft;
unsigned const kRuns = 1000 * 1000 * 1000;

cft = CFAbsoluteTimeGetCurrent();
for (unsigned i = 0; i < kRuns; i++) {
    testIVar = i;
}
cft = CFAbsoluteTimeGetCurrent() - cft;
NSLog(@"1: %.1f picoseconds/run", (cft * 10000000000.0) / kRuns);

cft = CFAbsoluteTimeGetCurrent();
for (unsigned i = 0; i < kRuns; i++) {
    [self setTestIVar:i];
}
cft = CFAbsoluteTimeGetCurrent() - cft;
NSLog(@"2: %.1f picoseconds/run", (cft * 10000000000.0) / kRuns);

输出：

1: 23.0 picoseconds/run
2: 98.4 picoseconds/run

速度慢了 4.28 倍，并且这是一个非原子原始 int，几乎是最佳情况；大多数其他情况甚至更糟（尝试原子 NSString * 属性！）。因此，如果您可以接受每个 ivar 访问速度比实际速度慢 4-5 倍的事实，那么使用属性就很好（至少在性能方面），但是，在很多情况下，这种性能下降是很严重的。完全不能接受。

更新2015-10-20

有些人认为，这不是一个现实世界的问题，上面的代码纯粹是合成的，你永远不会在真正的应用程序中注意到这一点。好吧，让我们尝试一下现实世界的示例。

下面的代码定义了 Account 对象。帐户具有描述其所有者的姓名 (NSString *)、性别 (enum) 和年龄 (unsigned) 的属性，以及余额 (int64_t)。帐户对象具有 init 方法和 compare: 方法。 compare: 方法定义为：女性顺序在男性之前，姓名按字母顺序排列，年轻人在老年人之前，平衡顺序从低到高。

实际上存在两个帐户类：AccountA 和AccountB。如果您查看它们的实现，您会发现它们几乎完全相同，但有一个例外：compare: 方法。 AccountA 对象通过方法（getter）访问自己的属性，而 AccountB 对象通过 ivar 访问自己的属性。这确实是唯一的区别！它们都通过 getter 访问另一个对象的属性来进行比较（通过 ivar 访问它是不安全的！如果另一个对象是子类并且覆盖了 getter 怎么办？）。另请注意，访问您自己的属性作为 ivars 不会破坏封装（ivars 仍然不公开）。

测试设置非常简单：创建 1 个 Mio 随机帐户，将它们添加到一个数组中并对该数组进行排序。就是这样。当然，有两个数组，一个用于 AccountA 对象，一个用于 AccountB 对象，并且两个数组都填充了相同的帐户（相同的数据源）。我们计算对数组进行排序所需的时间。

以下是我昨天执行的几次运行的输出：

runTime 1: 4.827070, 5.002070, 5.014527, 5.019014, 5.123039
runTime 2: 3.835088, 3.804666, 3.792654, 3.796857, 3.871076

如您所见，对 AccountB 对象数组进行排序总是比对 AccountA 数组进行排序要快得多代码>对象。

谁声称运行时间差异最多 1.32 秒没有什么区别，最好永远不要进行 UI 编程。例如，如果我想更改一个大表的排序顺序，这样的时间差异确实会给用户带来巨大的差异（可接受的 UI 和缓慢的 UI 之间的差异）。

同样在这种情况下，示例代码是此处执行的唯一实际工作，但是您的代码有多少次只是复杂发条装置的一个小齿轮？如果每个齿轮都像这样减慢整个过程，那么最终对整个发条装置的速度意味着什么？特别是如果一个工作步骤依赖于另一工作步骤的输出，这意味着所有低效率都会累积起来。大多数效率低下本身并不是问题，而是它们的总和才成为整个流程的问题。分析器不会轻易显示这样的问题，因为分析器的目的是查找关键热点，但这些低效率本身都不是热点。 CPU 时间只是平均分布在它们之间，但它们每个都只占很小的一部分，优化它似乎完全是浪费时间。确实，仅优化其中一个绝对没有任何帮助，优化所有这些则可以带来巨大帮助。

即使你不考虑CPU时间，因为你认为浪费CPU时间是完全可以接受的，毕竟“它是免费的”，那么功耗带来的服务器托管成本又如何呢？移动设备的电池运行时间怎么样？如果您将同一个移动应用程序编写两次（例如自己的移动网络浏览器），一次是所有类仅通过 getter 访问自己的属性的版本，一次是所有类仅通过 ivars 访问它们的版本，则不断使用第一个肯定会耗尽资源电池比使用第二块电池快得多，尽管它们的功能相同，而且对于用户来说，第二块电池甚至可能感觉更快一点。

现在，这是 main.m 文件的代码（该代码依赖于启用 ARC，并且一定要在编译时使用优化才能看到完整的效果）：

#import <Foundation/Foundation.h>

typedef NS_ENUM(int, Gender) {
    GenderMale,
    GenderFemale
};


@interface AccountA : NSObject
    @property (nonatomic) unsigned age;
    @property (nonatomic) Gender gender;
    @property (nonatomic) int64_t balance;
    @property (nonatomic,nonnull,copy) NSString * name;

    - (NSComparisonResult)compare:(nonnull AccountA *const)account;

    - (nonnull instancetype)initWithName:(nonnull NSString *const)name
        age:(const unsigned)age gender:(const Gender)gender
        balance:(const int64_t)balance;
@end


@interface AccountB : NSObject
    @property (nonatomic) unsigned age;
    @property (nonatomic) Gender gender;
    @property (nonatomic) int64_t balance;
    @property (nonatomic,nonnull,copy) NSString * name;

    - (NSComparisonResult)compare:(nonnull AccountB *const)account;

    - (nonnull instancetype)initWithName:(nonnull NSString *const)name
        age:(const unsigned)age gender:(const Gender)gender
        balance:(const int64_t)balance;
@end


static
NSMutableArray * allAcocuntsA;

static
NSMutableArray * allAccountsB;

static
int64_t getRandom ( const uint64_t min, const uint64_t max ) {
    assert(min <= max);
    uint64_t rnd = arc4random(); // arc4random() returns a 32 bit value only
    rnd = (rnd << 32) | arc4random();
    rnd = rnd % ((max + 1) - min); // Trim it to range
    return (rnd + min); // Lift it up to min value
}

static
void createAccounts ( const NSUInteger ammount ) {
    NSArray *const maleNames = @[
        @"Noah", @"Liam", @"Mason", @"Jacob", @"William",
        @"Ethan", @"Michael", @"Alexander", @"James", @"Daniel"
    ];
    NSArray *const femaleNames = @[
        @"Emma", @"Olivia", @"Sophia", @"Isabella", @"Ava",
        @"Mia", @"Emily", @"Abigail", @"Madison", @"Charlotte"
    ];
    const NSUInteger nameCount = maleNames.count;
    assert(maleNames.count == femaleNames.count); // Better be safe than sorry

    allAcocuntsA = [NSMutableArray arrayWithCapacity:ammount];
    allAccountsB = [NSMutableArray arrayWithCapacity:ammount];

    for (uint64_t i = 0; i < ammount; i++) {
        const Gender g = (getRandom(0, 1) == 0 ? GenderMale : GenderFemale);
        const unsigned age = (unsigned)getRandom(18, 120);
        const int64_t balance = (int64_t)getRandom(0, 200000000) - 100000000;

        NSArray *const nameArray = (g == GenderMale ? maleNames : femaleNames);
        const NSUInteger nameIndex = (NSUInteger)getRandom(0, nameCount - 1);
        NSString *const name = nameArray[nameIndex];

        AccountA *const accountA = [[AccountA alloc]
            initWithName:name age:age gender:g balance:balance
        ];
        AccountB *const accountB = [[AccountB alloc]
            initWithName:name age:age gender:g balance:balance
        ];

        [allAcocuntsA addObject:accountA];
        [allAccountsB addObject:accountB];
    }
}


int main(int argc, const char * argv[]) {
    @autoreleasepool {
        @autoreleasepool {
            NSUInteger ammount = 1000000; // 1 Million;
            if (argc > 1) {
                unsigned long long temp = 0;
                if (1 == sscanf(argv[1], "%llu", &temp)) {
                    // NSUIntegerMax may just be UINT32_MAX!
                    ammount = (NSUInteger)MIN(temp, NSUIntegerMax);
                }
            }
            createAccounts(ammount);
        }

        // Sort A and take time
        const CFAbsoluteTime startTime1 = CFAbsoluteTimeGetCurrent();
        @autoreleasepool {
            [allAcocuntsA sortedArrayUsingSelector:@selector(compare:)];
        }
        const CFAbsoluteTime runTime1 = CFAbsoluteTimeGetCurrent() - startTime1;

        // Sort B and take time
        const CFAbsoluteTime startTime2 = CFAbsoluteTimeGetCurrent();
        @autoreleasepool {
            [allAccountsB sortedArrayUsingSelector:@selector(compare:)];
        }
        const CFAbsoluteTime runTime2 = CFAbsoluteTimeGetCurrent() - startTime2;

        NSLog(@"runTime 1: %f", runTime1);
        NSLog(@"runTime 2: %f", runTime2);
    }
    return 0;
}



@implementation AccountA
    - (NSComparisonResult)compare:(nonnull AccountA *const)account {
        // Sort by gender first! Females prior to males.
        if (self.gender != account.gender) {
            if (self.gender == GenderFemale) return NSOrderedAscending;
            return NSOrderedDescending;
        }

        // Otherwise sort by name
        if (![self.name isEqualToString:account.name]) {
            return [self.name compare:account.name];
        }

        // Otherwise sort by age, young to old
        if (self.age != account.age) {
            if (self.age < account.age) return NSOrderedAscending;
            return NSOrderedDescending;
        }

        // Last ressort, sort by balance, low to high
        if (self.balance != account.balance) {
            if (self.balance < account.balance) return NSOrderedAscending;
            return NSOrderedDescending;
        }

        // If we get here, the are really equal!
        return NSOrderedSame;
    }

    - (nonnull instancetype)initWithName:(nonnull NSString *const)name
        age:(const unsigned)age gender:(const Gender)gender
        balance:(const int64_t)balance
    {
        self = [super init];
        assert(self); // We promissed to never return nil!

        _age = age;
        _gender = gender;
        _balance = balance;
        _name = [name copy];

        return self;
    }
@end


@implementation AccountB
    - (NSComparisonResult)compare:(nonnull AccountA *const)account {
        // Sort by gender first! Females prior to males.
        if (_gender != account.gender) {
            if (_gender == GenderFemale) return NSOrderedAscending;
            return NSOrderedDescending;
        }

        // Otherwise sort by name
        if (![_name isEqualToString:account.name]) {
            return [_name compare:account.name];
        }

        // Otherwise sort by age, young to old
        if (_age != account.age) {
            if (_age < account.age) return NSOrderedAscending;
            return NSOrderedDescending;
        }

        // Last ressort, sort by balance, low to high
        if (_balance != account.balance) {
            if (_balance < account.balance) return NSOrderedAscending;
            return NSOrderedDescending;
        }

        // If we get here, the are really equal!
        return NSOrderedSame;
    }

    - (nonnull instancetype)initWithName:(nonnull NSString *const)name
        age:(const unsigned)age gender:(const Gender)gender
        balance:(const int64_t)balance
    {
        self = [super init];
        assert(self); // We promissed to never return nil!

        _age = age;
        _gender = gender;
        _balance = balance;
        _name = [name copy];

        return self;
    }
@end

Answer 3

语义

• @property 可以表达 ivars 不能表达的内容：nonatomic 和 copy。
• ivars 可以表达 @property 不能表达的内容：
  • @protected：在子类上公开，在外部私有。
  • @package：在 64 位框架上公开，在外部私有。与 32 位上的 @public 相同。请参阅 Apple 的 64 位类和实例变量访问控制。
  • 预选赛。例如，强对象引用数组：id __strong *_objs。

性能

简短的故事：ivars 更快，但对于大多数用途来说并不重要。 nonatomic 属性不使用锁，但直接 ivar 速度更快，因为它跳过了访问器调用。有关详细信息，请阅读以下列表中的电子邮件。苹果网站。

主题：回复：什么时候使用属性和 ivars？
发件人：John McCall 
日期：2013年3月17日星期日15:10:46 -0700

属性在很多方面影响性能：

1. 正如已经讨论过的，发送消息来执行加载/存储比仅内联执行加载/存储要慢。

2. 发送消息来执行加载/存储也是相当多的代码，需要保存在 i-cache 中：即使 getter/setter
   除了加载/存储之外添加了零个额外指令，会有一个
   调用者中有六条额外的指令来设置
   消息发送并处理结果。

3. 发送消息会强制将该选择器的条目保留在方法缓存中，并且该内存通常会保留在
   d 缓存。这会增加启动时间，增加静态内存
   使用您的应用程序，并使上下文切换更加痛苦。自从
   方法缓存特定于对象的动态类，这
   您使用 KVO 的次数越多，问题就越严重。

4. 发送消息强制函数中的所有值溢出到堆栈（或保存在被调用者保存寄存器中，这意味着
   在不同的时间溢出）。

5. 发送消息可能会产生任意副作用，因此

   • 强制编译器重置所有关于非本地内存的假设
   • 无法提升、沉没、重新排序、合并或消除。

6. 在 ARC 中，消息发送的结果将始终被被调用者或调用者保留，即使返回 +0：即使
   方法不保留/自动释放其结果，调用者不知道
   并且必须尝试采取行动来防止结果出现
   自动释放。这永远无法消除，因为消息发送是
   不可静态分析。

7. 在 ARC 中，由于 setter 方法通常在 +0 处获取其参数，因此无法“转移”该对象的保留（如
   上面讨论的，ARC通常有）进入ivar，所以值
   通常需要保留/释放两次。

当然，这并不意味着它们总是不好的——有一个
使用属性有很多充分的理由。请记住，就像
许多其他语言功能，它们都不是免费的。

约翰。

Answer 4

最重要的原因是信息隐藏的 OOP 概念：如果您通过属性公开所有内容，从而允许外部对象窥视另一个对象的内部，那么您将利用这些内部，从而使更改对象变得复杂。执行。

“最小性能”增益很快就会累积起来，然后成为一个问题。我从经验中知道；我正在开发一个真正将 iDevices 发挥到极限的应用程序，因此我们需要避免不必要的方法调用（当然只有在合理可能的情况下）。为了帮助实现这一目标，我们还避免使用点语法，因为它让人很难第一眼看到方法调用的数量：例如，表达式 self.image.size.width 执行了多少个方法调用触发？相比之下，您可以通过 [[self image] size].width 立即判断。

另外，通过正确的 ivar 命名，KVO 无需属性也是可能的（IIRC，我不是 KVO 专家）。

Answer 5

属性与实例变量是一种权衡，最终的选择取决于应用程序。

封装/信息隐藏从设计角度来看，这是一件好事（TM），狭窄的接口和最少的链接使得软件易于维护和理解。在 Obj-C 中隐藏任何东西都非常困难，但是在实现中声明的实例变量已经非常接近了。

性能 虽然“过早优化”是一件坏事 (TM)，但仅仅因为可以而编写性能不佳的代码至少同样糟糕。很难否认方法调用比加载或存储更昂贵，并且在计算密集型代码中，成本很快就会增加。

在具有属性的静态语言（例如 C#）中，对 setter/getter 的调用通常可以由编译器优化。然而 Obj-C 是动态的，删除此类调用要困难得多。

抽象 反对 Obj-C 中实例变量的争论传统上是内存管理。对于 MRC 实例变量，需要在整个代码中传播对保留/释放/自动释放的调用，属性（无论是否合成）将 MRC 代码保留在一个位置 - 抽象原则是一件好事 (TM)。然而，对于 GC 或 ARC，这个论点消失了，因此内存管理的抽象不再是实例变量的论点。

Answer 6

属性将您的变量暴露给其他类。如果您只需要一个仅与您正在创建的类相关的变量，请使用实例变量。下面是一个小例子：用于解析 RSS 等的 XML 类通过一堆委托方法等进行循环。使用 NSMutableString 的实例来存储每个不同的解析过程的结果是很实用的。外部类没有理由需要访问或操作该字符串。因此，您只需在标头或私有中声明它，然后在整个类中访问它。为其设置属性可能仅对确保不存在内存问题有用，使用 self.mutableString 调用 getter/setter。

Answer 7

向后兼容性对我来说是一个因素。我无法使用任何 Objective-C 2.0 功能，因为我正在开发必须在 Mac OS X 10.3 上运行的软件和打印机驱动程序，这是一项要求的一部分。我知道你的问题似乎是针对 iOS 的，但我想我仍然会分享我不使用属性的原因。