首先我們先看一段代碼:

    #ifdef DEBUG
    #define LGNSLog(format, ...) printf("%s\n", [[NSString stringWithFormat:format, ##     __VA_ARGS__] UTF8String]);
    #else
    #define LGNSLog(format, ...);
    #endif

    LGPerson *p1 = [LGPerson alloc];
    LGPerson *p2 = [p1 init];
    LGPerson *p3 = [p1 init];
    LGNSLog(@"%@ - %p - %p",p1,p1,&p1);
    LGNSLog(@"%@ - %p - %p",p2,p2,&p2);
    LGNSLog(@"%@ - %p - %p",p3,p3,&p3);

打印的三個(gè)數(shù)據(jù)分別為：對(duì)象,指針地址,對(duì)象地址。
查看打印結(jié)果如下:

打印數(shù)據(jù).png

LGPerson原理.png

原理

雖然創(chuàng)建了三個(gè)對(duì)象p1,p2,p3，但是他們的指針都指向同一個(gè)類(lèi)，所以第一、第二個(gè)參數(shù)一致，但是創(chuàng)建的3個(gè)對(duì)象分別在不同的地址，所以第三個(gè)參數(shù)不一致。

Tips：我們拿到p1,p2,p3的地址，進(jìn)行相減，可以看到，每個(gè)地址都是相差8個(gè)字節(jié)。這是因?yàn)闂?nèi)存是連續(xù)的，由于對(duì)象是一個(gè)結(jié)構(gòu)體，結(jié)構(gòu)體是一個(gè)指針，占8字節(jié)，所以每個(gè)對(duì)象之間差8個(gè)字節(jié)，可以節(jié)省內(nèi)存空間。

alloc原理

當(dāng)我們想查看alloc方法的具體執(zhí)行流程的時(shí)候，往往就會(huì)被蘋(píng)果給阻撓掉，因?yàn)樘O(píng)果完全給封裝死了，根本看不到，那么我們通過(guò)符號(hào)斷點(diǎn)可以大致查看流程的走向。
具體操作如下：

• 選擇Symbolic BreakPoint...
  
  Symbolic BreakPoint.png
• 輸入alloc
  
  alloc.png
• 運(yùn)行程序(注意alloc在ViewDidLoad斷點(diǎn)執(zhí)行完成時(shí)再打開(kāi)，否則其他的創(chuàng)建方法會(huì)一直調(diào)用這里),進(jìn)入到[NSObject alloc]方法,LGPerson繼承自NSObject方法
  
  image.png
• 點(diǎn)擊step into,進(jìn)入_objc_rootAlloc
  
  image.png
• 點(diǎn)擊step into,進(jìn)入_objc_rootAllocWithZone
  
  image.png
• 這就是alloc的大致執(zhí)行流程

但是，這樣還是看不到具體方法，那么我們就需要看objc的源碼了,我們下載最新的代碼objc4-781。

推薦大家去看Style_月月的iOS-底層原理 03：objc4-781 源碼編譯 & 調(diào)試這篇博客，里面對(duì)objc4-781的編譯調(diào)試講的非常仔細(xì)。

源碼解讀

alloc流程圖如下，其中最關(guān)鍵的步驟在虛線框里:

alloc.png

• alloc,我們點(diǎn)擊alloc可以看到，跳到了

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

• _objc_rootAlloc，第二步跳到_objc_rootAlloc

id _objc_rootAlloc(Class cls)
{
    return callAlloc(cls, false/*checkNil*/, true/*allocWithZone*/);
}

• callAlloc，第三步跳到callAlloc

static ALWAYS_INLINE id
callAlloc(Class cls, bool checkNil, bool allocWithZone=false)
{
#if __OBJC2__
    if (slowpath(checkNil && !cls)) return nil;
    if (fastpath(!cls->ISA()->hasCustomAWZ())) {
        return _objc_rootAllocWithZone(cls, nil);
    }
#endif

    // No shortcuts available.
    if (allocWithZone) {
        return ((id(*)(id, SEL, struct _NSZone *))objc_msgSend)(cls, @selector(allocWithZone:), nil);
    }
    return ((id(*)(id, SEL))objc_msgSend)(cls, @selector(alloc));
}

• _objc_rootAllocWithZone，第四步跳到_objc_rootAllocWithZone

NEVER_INLINE
id
_objc_rootAllocWithZone(Class cls, malloc_zone_t *zone __unused)
{
    // allocWithZone under __OBJC2__ ignores the zone parameter
    return _class_createInstanceFromZone(cls, 0, nil,
                                         OBJECT_CONSTRUCT_CALL_BADALLOC);
}

• _class_createInstanceFromZone

static ALWAYS_INLINE id
_class_createInstanceFromZone(Class cls, size_t extraBytes, void *zone,
                              int construct_flags = OBJECT_CONSTRUCT_NONE,
                              bool cxxConstruct = true,
                              size_t *outAllocatedSize = nil)
{
    ASSERT(cls->isRealized());

    // Read class's info bits all at once for performance
    bool hasCxxCtor = cxxConstruct && cls->hasCxxCtor();
    bool hasCxxDtor = cls->hasCxxDtor();
    bool fast = cls->canAllocNonpointer();
    size_t size;

    size = cls->instanceSize(extraBytes);
    if (outAllocatedSize) *outAllocatedSize = size;

    id obj;
    if (zone) {
        obj = (id)malloc_zone_calloc((malloc_zone_t *)zone, 1, size);
    } else {
        // alloc 開(kāi)辟內(nèi)存的地方
        obj = (id)calloc(1, size);
    }
    if (slowpath(!obj)) {
        if (construct_flags & OBJECT_CONSTRUCT_CALL_BADALLOC) {
            return _objc_callBadAllocHandler(cls);
        }
        return nil;
    }

    if (!zone && fast) {
        obj->initInstanceIsa(cls, hasCxxDtor);
    } else {
        // Use raw pointer isa on the assumption that they might be
        // doing something weird with the zone or RR.
        obj->initIsa(cls);
    }

    if (fastpath(!hasCxxCtor)) {
        return obj;
    }

    construct_flags |= OBJECT_CONSTRUCT_FREE_ONFAILURE;
    return object_cxxConstructFromClass(obj, cls, construct_flags);
}

上面這個(gè)方法有3個(gè)方法比較重要

cls->instanceSize

cls->instanceSize，這個(gè)方法是分配對(duì)象的內(nèi)存。

size_t instanceSize(size_t extraBytes) const {
        if (fastpath(cache.hasFastInstanceSize(extraBytes))) {
            return cache.fastInstanceSize(extraBytes);
        }

        size_t size = alignedInstanceSize() + extraBytes;
        // CF requires all objects be at least 16 bytes.
        if (size < 16) size = 16;
        return size;
    }

具體進(jìn)入cache.fastInstanceSize(extraBytes)

size_t fastInstanceSize(size_t extra) const
    {
        ASSERT(hasFastInstanceSize(extra));

        if (__builtin_constant_p(extra) && extra == 0) {
            return _flags & FAST_CACHE_ALLOC_MASK16;
        } else {
            size_t size = _flags & FAST_CACHE_ALLOC_MASK;
            // remove the FAST_CACHE_ALLOC_DELTA16 that was added
            // by setFastInstanceSize
            return align16(size + extra - FAST_CACHE_ALLOC_DELTA16);
        }
    }

經(jīng)過(guò)斷點(diǎn)，我們可以看到extra為0，所以走到

size_t size = _flags & FAST_CACHE_ALLOC_MASK;

這一步，通過(guò)取與運(yùn)算后size = 16，接下來(lái)，

static inline size_t align16(size_t x) {
    return (x + size_t(15)) & ~size_t(15);
}

這一步是干嘛呢？我們繼續(xù)斷點(diǎn)調(diào)試,size_t x = 8,通過(guò)

// 8 + 15 = 23
x + size_t(15)

得到23,那么23用二進(jìn)制表示為

// 23轉(zhuǎn)換成2進(jìn)制
0000 0000 0001 0111

而15的二進(jìn)制表示為

// 15轉(zhuǎn)換成2進(jìn)制
0000 0000 0000 1111

然后~size_t(15)表示15的二進(jìn)制取反

// 15二進(jìn)制取反
1111 1111 1111 0000

最后(x + size_t(15)) & ~size_t(15)表示23和15取反的結(jié)果去與，得到

//23轉(zhuǎn)換成2進(jìn)制
0000 0000 0001 0111
//與運(yùn)算
&
// 15二進(jìn)制取反
1111 1111 1111 0000
//&運(yùn)算得到的結(jié)果
= 0000 0000 0001 0000

最終得到0000 0000 0001 0000,最后結(jié)果轉(zhuǎn)換為十進(jìn)制為16，把后4位都抹掉了，只剩下第5位開(kāi)始，都為16的倍數(shù)。
所以，align16()方法就是16字節(jié)的對(duì)齊，這就是所謂的字節(jié)對(duì)齊。

字節(jié)對(duì)齊

• 字節(jié)對(duì)齊的解釋
  現(xiàn)代計(jì)算機(jī)中內(nèi)存空間都是按照byte劃分的，從理論上講似乎對(duì)任何類(lèi)型的變量的訪問(wèn)可以從任何地址開(kāi)始，但實(shí)際情況是在訪問(wèn)特定類(lèi)型變量的時(shí)候經(jīng)常在特 定的內(nèi)存地址訪問(wèn)，這就需要各種類(lèi)型數(shù)據(jù)按照一定的規(guī)則在空間上排列，而不是順序的一個(gè)接一個(gè)的排放，這就是對(duì)齊。
• 為什么要16字節(jié)對(duì)齊?
  • 一個(gè)對(duì)象有isa指針，占8字節(jié)，如果是8字節(jié)對(duì)齊，會(huì)因?yàn)闆](méi)有預(yù)留空間導(dǎo)致一個(gè)isa緊挨著另一個(gè)isa，造成訪問(wèn)混亂。所以需要進(jìn)行內(nèi)存預(yù)留。
  • 一個(gè)對(duì)象最小為8字節(jié)，所以預(yù)留的空間最小為16的倍數(shù)，方便讀寫(xiě)。
  • 16字節(jié)對(duì)齊后，可以加快CPU讀取速度，同時(shí)使訪問(wèn)更安全，不會(huì)產(chǎn)生訪問(wèn)混亂的情況

內(nèi)存開(kāi)辟的影響因素

現(xiàn)在我們給LGPerson添加幾個(gè)屬性

//名稱(chēng)
@property (nonatomic,strong) NSString *name;     
//昵稱(chēng)
@property (nonatomic,strong) NSString *nickName; 
//愛(ài)好
@property (nonatomic) int hobby; 

再看我們當(dāng)前的size

size.png

obj = (id)calloc(1, size)

這個(gè)方法就是向內(nèi)存中申請(qǐng) 大小 為 size的內(nèi)存，并賦值給obj，因此 obj是指向內(nèi)存地址的指針

obj = (id)calloc(1, size)

我們可以驗(yàn)證一下

i calloc.png

obj->initInstanceIsa(cls, hasCxxDtor)

這個(gè)方法就是將類(lèi)和指針進(jìn)行綁定，通過(guò)打印

initInstanceIsa

init方法

從上面的alloc方法可以看到，我們通過(guò)alloc方法已經(jīng)可以拿到得到一個(gè)指向LGPerson類(lèi)的指針。那么alloc方法是干嘛的呢？
我們通過(guò)流程圖查看。

• 點(diǎn)擊init,進(jìn)入_objc_rootInit方法

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

• 點(diǎn)擊_objc_rootInit，返回obj自己

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;
}

可以看到,其實(shí)init方法就是返回了對(duì)象本身。所以init是一個(gè)構(gòu)造方法 ，是通過(guò)工廠方法,主要是用于給用戶(hù)提供構(gòu)造方法入口。
這里能使用id強(qiáng)轉(zhuǎn)的原因，主要還是因?yàn)?code>內(nèi)存字節(jié)對(duì)齊后，可以使用類(lèi)型強(qiáng)轉(zhuǎn)為你所需的類(lèi)型。

new方法

通過(guò)代碼可以看到,new方法會(huì)調(diào)用callAlloc

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

所以，new等同于alloc init方法。
但是，一般我們不建議直接使用new方法，因?yàn)?init方法可以自定義參數(shù)等操作，而new方法不行。