iOS的OC對象創(chuàng)建的alloc原理

前言

在OC開發(fā)中最基本的就是對象的創(chuàng)建甲脏，也就是用alloc和init方法來初始化對象铅匹，但是在我們?nèi)粘ｉ_發(fā)中這個對象創(chuàng)建的最基本最簡單的操作我們只知道怎么使用，并不知道里面的底層到底做了什么，這就是這篇文章的以下需要介紹的alloc底層原理。

為了更好的介紹以下的內(nèi)容定義了一個TestObject的類

@interface TestObject : NSObject

@end

#import "TestObject.h"

@implementation TestObject

+ (void)initialize
{
    NSLog(@"%s",__func__);
}

+(instancetype)allocWithZone:(struct _NSzone *)zone{
    NSLog(@"%s",__func__);
    return [super allocWithZone:zone];
}
@end

在介紹之前先來一個簡單的例子

    TestObject *test = [TestObject alloc];
    TestObject *test1 = [test init];
    TestObject *test2 = [test1 init];
    NSLog(@"=========輸出結(jié)果============");
    NSLog(@"%@---%p",test,&test);
    NSLog(@"%@---%p",test1,&test1);
    NSLog(@"%@---%p",test2,&test2);
    
    =========輸出結(jié)果============
2020-04-28 09:45:04.657448+0800 AllocDemo[3448:65473] <TestObject: 0x600002dfdf70>---0x7ffee4081188
2020-04-28 09:45:04.657608+0800 AllocDemo[3448:65473] <TestObject: 0x600002dfdf70>---0x7ffee4081180
2020-04-28 09:45:04.657769+0800 AllocDemo[3448:65473] <TestObject: 0x600002dfdf70>---0x7ffee4081178

從例子可以看到卤档，這三個是同一個對象，但是指針的地址是不同的程剥，那么問題來了劝枣，為什么這三個對象地址是一樣的？alloc和init底層到底做了什么织鲸？

1.通過匯編來對alloc的探索

1.可以在Xcode上的Debug->Debug Workflow->Always show Disassembly舔腾，如圖：

Xcode開啟匯編

當(dāng)然，這種方式是對整個項目對全局操作的搂擦，那么就在需要用到的時候稳诚，先打斷點，然后再開啟盾饮。

2.配合系統(tǒng)斷點的形式來就可以一步一步看到alloc底層的每一步的流程采桃。通過這樣的方式可以找到alloc的底層的入口,是objc_alloc底層方法

alloc的入口

通過系統(tǒng)的斷點懒熙，知道objc_alloc方法是在libobjc.A.dylib的庫里面,并且它的下一步是alloc方法丘损。

objc_alloc的底層方法

雖然這種方式可以知道底層的流程走向。但是具體的各個函數(shù)的實現(xiàn)是不清楚的工扎，并且這種方式也比較麻煩不直觀徘钥。

2.源碼分析alloc底層

但是蘋果官方開源了這部分的源碼，可以在蘋果源碼列表找到objc4,在里面下載肢娘，可以配合這個大佬的配置iOS_objc4-756.2 最新源碼編譯調(diào)試讓源碼可以在Xcode上運(yùn)行呈础。接下來舆驶，我就是根據(jù)objc4-756.2的源碼來進(jìn)行探索的。

2.1 alloc的入口objc_alloc

通過上面的匯編可以知道objc_alloc是alloc的底層入口而钞，但是我們通過源碼的配置點擊進(jìn)去的話是會直接跳轉(zhuǎn)到

+ (id)alloc {
    return _objc_rootAlloc(self);
}

這是一個類方法沙廉，這是為什么呢？
因為第一次alloc跑到objc_alloc這種是只走一次臼节，原因就是sel實現(xiàn)imp函數(shù)地址撬陵，在macho的符號綁定(綁定symbol)的sel_alloc找到可以找到objc_alloc

image

通過源碼可以知道其中方法fixupMessageRef在正常的情況下不走，只有這個對象需要修復(fù)的時候才走网缝，所以正常的情況下這個對象就是已經(jīng)綁定了巨税，所以在正常情況下打斷點是不會跑到這里的。

image

所以通過源碼將斷點打在objc_alloc方法上粉臊，進(jìn)行下一步

image

2.2 callAlloc

// Call [cls alloc] or [cls allocWithZone:nil], with appropriate 
// shortcutting optimizations.
static ALWAYS_INLINE id
callAlloc(Class cls, bool checkNil, bool allocWithZone=false)
{
    if (slowpath(checkNil && !cls)) return nil;

#if __OBJC2__
    if (fastpath(!cls->ISA()->hasCustomAWZ())) {
        // No alloc/allocWithZone implementation. Go straight to the allocator.
        // fixme store hasCustomAWZ in the non-meta class and 
        // add it to canAllocFast's summary
        if (fastpath(cls->canAllocFast())) {
            // No ctors, raw isa, etc. Go straight to the metal.
            bool dtor = cls->hasCxxDtor();
            id obj = (id)calloc(1, cls->bits.fastInstanceSize());
            if (slowpath(!obj)) return callBadAllocHandler(cls);
            obj->initInstanceIsa(cls, dtor);
            return obj;
        }
        else {
            // Has ctor or raw isa or something. Use the slower path.
            id obj = class_createInstance(cls, 0);
            if (slowpath(!obj)) return callBadAllocHandler(cls);
            return obj;
        }
    }
#endif

    // No shortcuts available.
    if (allocWithZone) return [cls allocWithZone:nil];
    return [cls alloc];
}

第一次進(jìn)來是從objc_alloc里面進(jìn)來的草添，其中checkNil為true,allocWithZone為false，因為第一次進(jìn)來fastpath(!cls->ISA()->hasCustomAWZ())中的cls還沒有指針isa,所以為false扼仲，直接return [cls alloc],其中在調(diào)用了[cls alloc]方法會會觸發(fā)objc_msgSend調(diào)用initialize類方法远寸，因為這個方法在第一次初始化該類之前會被調(diào)用。

image

所以第一次的流程是最外面的alloc-->objec_alloc-->callAlloc(Class cls, true, false)

#define fastpath(x) (__builtin_expect(bool(x), 1))
#define slowpath(x) (__builtin_expect(bool(x), 0))
slowpath(bool)與fastpath(bool)：常用于if-else而晒，可以優(yōu)化判斷的速度。
應(yīng)用gcc指令__builtin_expect(EXP,N) ,通過此指令優(yōu)化編譯器在編譯時的代碼布局,減少指令跳轉(zhuǎn)帶來的性能消耗阅畴。

2.3 alloc的第二次流程

通過第一次的callAlloc返回倡怎，根據(jù)斷點跳轉(zhuǎn)到了

+ (id)alloc {
    return _objc_rootAlloc(self);
}

// Base class implementation of +alloc. cls is not nil.
// Calls [cls allocWithZone:nil].
id
_objc_rootAlloc(Class cls)
{
    return callAlloc(cls, false/*checkNil*/, true/*allocWithZone*/);
}

此時會再次調(diào)用callAlloc方法，但是此時的參數(shù)checkNil為false贱枣，allocWithZone為true监署。因為之前調(diào)用了initialize類方法，此時的bits是有值了纽哥，直接進(jìn)入到了if(fastpath(!cls->ISA()->hasCustomAWZ()))里面钠乏。

2.3.1 hasCustomAWZ()方法的解析

    bool hasCustomAWZ() {
        return ! bits.hasDefaultAWZ();
    }

hasCustomAWZ方法意思就是判斷是否實現(xiàn)自定義的allocWithZone方法，如果沒有實現(xiàn)就調(diào)用系統(tǒng)默認(rèn)的allocWithZone方法春塌。

因為fastpath(cls->canAllocFast())根據(jù)源碼返回的永遠(yuǎn)都是false

    bool canAllocFast() {
        assert(!isFuture());
        return bits.canAllocFast();
    }
#if FAST_ALLOC
    ·····
#else
    ····
    bool canAllocFast() {
        return false;
    }
#endif

#define FAST_ALLOC  (1UL<<2)

所以不會執(zhí)行if里面的代碼塊晓避，只會執(zhí)行else里面的代碼塊

2.3.2 類中實現(xiàn)allocWithZone類方法對流程的影響

1.類沒有實現(xiàn)allocWithZone方法的時候是需要運(yùn)行fastpath(!cls->ISA()->hasCustomAWZ())判斷里面的代碼，最終是通過class_createInstance的返回

            id obj = class_createInstance(cls, 0);
            if (slowpath(!obj)) return callBadAllocHandler(cls);
            return obj;

id class_createInstance(Class cls, size_t extraBytes)
{
    return _class_createInstanceFromZone(cls, extraBytes, nil);
}

所以這個的流程是：alloc->_objc_rootAlloc->callAlloc(cls,false,true)->class_createInstance->_class_createInstanceFromZone

2.類實現(xiàn)了allocWithZone方法的時候就不會運(yùn)行fastpath(!cls->ISA()->hasCustomAWZ())判斷里面的代碼只壳，直接跑

    if (allocWithZone) return [cls allocWithZone:nil];

并且這時候會執(zhí)行類中實現(xiàn)的allocWithZone方法

2020-04-28 23:55:18.173680+0800 LGTest[2370:69449] +[TestObject allocWithZone:]

通過斷點的形式得到的流程是：
alloc->_objc_rootAlloc->callAlloc(cls,false,true)->allocWithZone->_objc_rootAllocWithZone->class_createInstance->_class_createInstanceFromZone

最終這兩種情況下都會執(zhí)行到_class_createInstanceFromZone這個函數(shù)里面俏拱。

2.3.4 _class_createInstanceFromZone方法

這個方法的源代碼

static __attribute__((always_inline)) 
id
_class_createInstanceFromZone(Class cls, size_t extraBytes, void *zone, 
                              bool cxxConstruct = true, 
                              size_t *outAllocatedSize = nil)
{
    if (!cls) return nil;

    assert(cls->isRealized());

    // Read class's info bits all at once for performance
    //判斷當(dāng)前class或者superclass是否有.cxx_construct構(gòu)造方法的實現(xiàn)
    bool hasCxxCtor = cls->hasCxxCtor();
    //判斷當(dāng)前class或者superclass是否有.cxx——destruct析構(gòu)方法的實現(xiàn)
    bool hasCxxDtor = cls->hasCxxDtor();
    bool fast = cls->canAllocNonpointer();

    //通過進(jìn)行內(nèi)存對齊得到實例大小
    size_t size = cls->instanceSize(extraBytes);
    if (outAllocatedSize) *outAllocatedSize = size;

    id obj;
    if (!zone  &&  fast) {
        obj = (id)calloc(1, size);
        if (!obj) return nil;
        //初始化實例的isa指針
        obj->initInstanceIsa(cls, hasCxxDtor);
    } 
    else {
        if (zone) {
            obj = (id)malloc_zone_calloc ((malloc_zone_t *)zone, 1, size);
        } else {
            obj = (id)calloc(1, size);
        }
        if (!obj) return nil;

        // Use raw pointer isa on the assumption that they might be 
        // doing something weird with the zone or RR.
        obj->initIsa(cls);
    }

    if (cxxConstruct && hasCxxCtor) {
        obj = _objc_constructOrFree(obj, cls);
    }

    return obj;
}

下面是對_class_createInstanceFromZone的分析

1.cls->instanceSize(extraBytes)是進(jìn)行內(nèi)存對齊得到的實例大小,里面的流程分別如下：

size_t instanceSize(size_t extraBytes) {
    size_t size = alignedInstanceSize() + extraBytes;
    // CF requires all objects be at least 16 bytes.
    if (size < 16) size = 16;
    return size;
}
    
uint32_t alignedInstanceSize() {
    return word_align(unalignedInstanceSize());
}
    
uint32_t unalignedInstanceSize() {
    assert(isRealized());
    return data()->ro->instanceSize;
}
    
static inline uint32_t word_align(uint32_t x) {
    return (x + WORD_MASK) & ~WORD_MASK;
}

#ifdef __LP64__
#   define WORD_MASK 7UL
#else
#   define WORD_MASK 3UL
#endif

一開始進(jìn)來的時候extraBytes為0的，因為當(dāng)前的TestObject里面是沒有屬性的吼句，是不是覺得開辟的內(nèi)存空間是0呢锅必？并不是的，因為還有一個isa

@interface NSObject <NSObject> {
#pragma clang diagnostic push
#pragma clang diagnostic ignored "-Wobjc-interface-ivars"
    Class isa  OBJC_ISA_AVAILABILITY;
#pragma clang diagnostic pop
}

通過流程可以知道在unalignedInstanceSize方法中得到編譯進(jìn)去的實例的大小惕艳，因為isa是一個對象指針搞隐，所以這個的大小是一個8字節(jié)驹愚。所以傳到word_align方法里面的x為8。其中WORD_MASK在64位系統(tǒng)下是7劣纲，否則是3逢捺，因此，word_align()方法在64位系統(tǒng)下進(jìn)行計算是8字節(jié)對齊按照里面的算法就是相當(dāng)于8的倍數(shù)癞季。返回到instanceSize()方法中的size就是對象需要的空間大小為8蒸甜，因為里面有小于16的返回16。

2.calloc函數(shù)是初始化所分配的內(nèi)存空間的余佛。

3.initInstanceIsa函數(shù)是初始化isa,關(guān)聯(lián)cls的柠新，這部分內(nèi)容后續(xù)會進(jìn)行介紹。

2.4 init和new

1.介紹完alloc之后辉巡，init方法通過源碼

- (id)init {
    return _objc_rootInit(self);
}

id
_objc_rootInit(id obj)
{
    // In practice, it will be hard to rely on this function.
    // Many classes do not properly chain -init calls.
    return obj;
}

其實就是返回它的本身的恨憎。

2.new的方法通過源碼知道是 callAlloc方法和 init的方法的結(jié)合

+ (id)new {
    return [callAlloc(self, false/*checkNil*/) init];
}

3.最后

通過上面的流程得到了最終的alloc在底層的流程圖

alloc的流程圖