runtime-闲聊内存管理

前言

ARC作为一个老生常谈的话题，基本被网上的各种博客说尽了。但是前段时间朋友通过某些手段对YYModel进行了优化，提高了大概1/3左右的效率，在观赏过他改进的源码之后我又重新看了一遍ARC相关的实现源码，主要体现ARC机制的几个方法分别是retain、release以及dealloc，主要与strong和weak两者相关

ARC的内存管理

来看看一段ARC环境下的代码
- (void)viewDidLoad {
NSArray * titles = @[@"title1", @"title2"];
}
在编译期间，代码就会变成这样：

- (void)viewDidLoad {
    NSArray * titles = @[@"title1", @"title2"];
    [titles retain];
    ///  .......
    [titles release];
}

简单来说就是ARC在代码编译阶段，会自动在代码的上下文中成对插入retain以及release，保证引用计数能够正确管理内存。如果对象不是强引用类型，那么ARC的处理也会进行相应的改变

下面会分别说明在这几个与引用计数相关的方法调用中发生了什么

retain

强引用有retain、strong以及__strong三种修饰，默认情况下，所有的类对象会自动被标识为__strong强引用对象，强引用对象会在上下文插入retain以及release调用，从runtime源码处可以下载到对应调用的源代码。在retain调用的过程中，总共涉及到了四次调用：

• id _objc_rootRetain(id obj)
  对传入对象进行非空断言，然后调用对象的rootRetain()方法
• id objc_object::rootRetain()
  断言非GC环境，如果对象是TaggedPointer指针，不做处理。TaggedPointer是苹果推出的一套优化方案，具体可以参考深入了解Tagged Pointer一文
• id objc_object::sidetable_retain()
  增加引用计数，具体往下看
• id objc_object::sidetable_retain_slow(SideTable& table)
  增加引用计数，具体往下看

在上面的几步中最重要的步骤就是最后两部的增加引用计数，在NSObject.mm中可以看到函数的实现。这里笔者剔除了部分不相关的代码：

#define SIDE_TABLE_WEAKLY_REFERENCED (1UL<<0)
#define SIDE_TABLE_DEALLOCATING      (1UL<<1)
#define SIDE_TABLE_RC_ONE            (1UL<<2)
#define SIDE_TABLE_RC_PINNED         (1UL<<(WORD_BITS-1))

typedef objc::DenseMap,size_t,true> RefcountMap;
struct SideTable {
    spinlock_t slock;
    RefcountMap refcnts;
    weak_table_t weak_table;
}

id objc_object::sidetable_retain()
{
    // 获取对象的table对象
    SideTable& table = SideTables()[this];

    if (table.trylock()) {

        // 获取 引用计数的引用
        size_t& refcntStorage = table.refcnts[this];
        if (! (refcntStorage & SIDE_TABLE_RC_PINNED)) {
            // 如果引用计数未越界，则引用计数增加
            refcntStorage += SIDE_TABLE_RC_ONE;
        }
        table.unlock();
        return (id)this;
    }
    return sidetable_retain_slow(table);
}

• SideTable这个类包含着一个自旋锁slock来防止操作时可能出现的多线程读取问题、一个弱引用表weak_table以及引用计数表refcnts。另外还提供一个方法传入对象地址来寻找对应的SideTable对象

• RefcountMap对象通过散列表的结构存储了对象持有者的地址以及引用计数，这样一来，即便对象对应的内存出现错误，例如Zombie异常，也能定位到对象的地址信息

• 每次retain后以后引用计数的值实际上增加了(1 << 2) == 4而不是我们所知的1，这是由于引用计数的后两位分别被弱引用以及析构状态两个标识位占领，而第一位用来表示计数是否越界。

由于引用计数可能存在越界情况（SIDE_TABLE_RC_PINNED位的值为1），因此散列表refcnts中应该存储了多个引用计数，sidetable_retainCount()函数也证明了这一点：

#define SIDE_TABLE_RC_SHIFT 2
uintptr_t objc_object::sidetable_retainCount()
{
    SideTable& table = SideTables()[this];
    size_t refcnt_result = 1;

    table.lock();
    RefcountMap::iterator it = table.refcnts.find(this);
    if (it != table.refcnts.end()) {
        refcnt_result += it->second >> SIDE_TABLE_RC_SHIFT;
    }
    table.unlock();
    return refcnt_result;
}

引用计数总是返回1 + 计数表总计这个数值，这也是为什么经常性的当对象被释放后，我们获取retainCount的值总不能为0。至于函数sidetable_retain_slow的实现和sidetable_retain几乎一样，就不再介绍了

release

release调用有着跟retain类似的四次调用，前两次调用的作用一样，因此这里只放上引用计数减少的函数代码：

uintptr_t objc_object::sidetable_release(bool performDealloc)
{
#if SUPPORT_NONPOINTER_ISA
    assert(!isa.indexed);
#endif
    SideTable& table = SideTables()[this];

    bool do_dealloc = false;

    if (table.trylock()) {
        RefcountMap::iterator it = table.refcnts.find(this);
        if (it == table.refcnts.end()) {
            do_dealloc = true;
            table.refcnts[this] = SIDE_TABLE_DEALLOCATING;
        } else if (it->second < SIDE_TABLE_DEALLOCATING) {
            // SIDE_TABLE_WEAKLY_REFERENCED may be set. Don't change it.
            do_dealloc = true;
            it->second |= SIDE_TABLE_DEALLOCATING;
        } else if (! (it->second & SIDE_TABLE_RC_PINNED)) {
            it->second -= SIDE_TABLE_RC_ONE;
        }
        table.unlock();
        if (do_dealloc  &&  performDealloc) {
            ((void(*)(objc_object *, SEL))objc_msgSend)(this, SEL_dealloc);
        }
        return do_dealloc;
    }

    return sidetable_release_slow(table, performDealloc);
}

在release中决定对象是否会被dealloc有两个主要的判断

• 如果引用计数为计数表中的最后一个，标记对象为正在析构状态，然后执行完成后发送SEL_dealloc消息释放对象
• 即便计数表的值为零，sidetable_retainCount函数照样会返回1的值。这时计数小于宏定义SIDE_TABLE_DEALLOCATING == 1，就不进行减少计数的操作，直接标记对象正在析构

看到release的代码就会发现在上面代码中宏定义SIDE_TABLE_DEALLOCATING体现出了苹果这个心机婊的用心之深。通常而言，即便引用计数只有8位的占用，在剔除了首位越界标记以及后两位后，其最大取值为2^5-1 == 31位。通常来说，如果不是项目中block不加限制的引用，是很难达到这么多的引用量的。因此占用了SIDE_TABLE_DEALLOCATING位不仅减少了额外占用的标记变量内存，还能以作为引用计数是否归零的判断

weak

最开始的时候没打算讲weak这个修饰，不过因为dealloc方法本身涉及到了弱引用对象置空的操作，以及retain过程中的对象也跟weak有关系的情况下，简单的说说weak的操作

bool objc_object::sidetable_isWeaklyReferenced()
{
    bool result = false;

    SideTable& table = SideTables()[this];
    table.lock();

    RefcountMap::iterator it = table.refcnts.find(this);
    if (it != table.refcnts.end()) {
        result = it->second & SIDE_TABLE_WEAKLY_REFERENCED;
    }

    table.unlock();

    return result;
}

weak和strong共用一套引用计数设计，因此两者的赋值操作都要设置计数表，只是weak修饰的对象的引用计数对象会被设置SIDE_TABLE_WEAKLY_REFERENCED位，并且不参与sidetable_retainCount函数中的计数计算而已

void objc_object::sidetable_setWeaklyReferenced_nolock()
{
#if SUPPORT_NONPOINTER_ISA
    assert(!isa.indexed);
#endif

    SideTable& table = SideTables()[this];

    table.refcnts[this] |= SIDE_TABLE_WEAKLY_REFERENCED;
}

另一个弱引用设置方法，相比上一个方法去掉了自旋锁加锁操作

dealloc

dealloc是重量级的方法之一，不过由于函数内部调用层次过多，这里不多阐述。实现代码在objc-object.h的798行，可以自行到官网下载源码后研读

__unsafe_unretained

其实写了这么多，终于把本文的主角给讲出来了。在iOS5的时候，苹果正式推出了ARC机制，伴随的是上面的weak、strong等新修饰符，当然还有一个不常用的__unsafe_unretained

• weak
  修饰的对象在指向的内存被释放后会被自动置为nil
• strong
  持有指向的对象，会让引用计数+1
• __unsafe_unretained
  不引用指向的对象。但在对象内存被释放掉后，依旧指向内存地址，等同于assign，但是只能修饰对象

在机器上保证应用能保持在55帧以上的速率会让应用看起来如丝绸般顺滑，但是稍有不慎，稍微降到50~55之间都有很大的可能展现出卡顿的现象。这里不谈及图像渲染、数据大量处理等耳闻能详的性能恶鬼，说说Model所造成的损耗。

如前面所说的，在ARC环境下，对象的默认修饰为strong，这意味着这么一段代码：

@protocol RegExpCheck

@property (nonatomic, copy) NSString * regExp;

- (BOOL)validRegExp;

@end

- (BOOL)valid: (NSArray> *)params {
    for (id item in params) {
        if (![item validRegExp]) { return NO; }
    }
    return YES;
}

把这段代码改为编译期间插入retain和release方法后的代码如下：

- (BOOL)valid: (NSArray> *)params {
    for (id item in params) {
        [item retain];
        if (![item validRegExp]) { 
            [item release];
            return NO;
        }
        [item release];
    }
    return YES;
}

遍历操作在项目中出现的概率绝对排的上前列，那么上面这个方法在调用期间会调用params.count次retain和release函数。通常来说，每一个对象的遍历次数越多，这些函数调用的损耗就越大。如果换做__unsafe_unretained修饰对象，那么这部分的调用损耗就被节省下来，这也是笔者朋友改进的手段

尾话

首先要承认，相比起其他性能恶鬼改进的优化，使用__unsafe_unretained带来的收益几乎微乎其微，因此笔者并不是很推荐用这种高成本低回报的方式优化项目，起码在性能恶鬼大头解决之前不推荐，但是去学习内存管理底层的知识可以帮助我们站在更高的地方看待开发。

ps:在朋友的坚持下，可耻的取消了代码链接

上一篇：消息机制
下一篇：分类为什么不生成setter和getter

转载请注明本文作者和地址