第二节课 OC对象原理(中)

底层LLVM优化

上篇文章我们说到，实际代码查看的流程是 alloc->_objc_rootAlloc->callAlloc->_objc_rootAllocWithZone,但是，我们通过断点发现实际流程却是alloc->objc_alloc->callAlloc->objc_msgSend->alloc->_objc_rootAlloc-callAlloc,这个到底是为啥呢？

原因是苹果觉得alloc是比较特殊的方法，只要是alloc，就先走objc_alloc(类似hook),执行了一些底层优化、标记，再执行alloc方法，具体需要探索LLVM的源码，这个我们后续再进行补充。
LLVM下载地址

所以实际的alloc流程应该为:
alloc->objc_alloc->LLVM底层优化、标记等等->objc_alloc->objc_msgSend->alloc->LLVM判断标记过->_objc_rootAlloc
这也是为什么callalloc走两次的原因，所以我们将之前的流程图再次补充一下。

alloc主线流程图补充.png

对象的内存的影响因素

上篇文章我们讨论了一下字节对齐，字节对齐的最终又是以内存的方式展现，所以我们来探究一下能影响内存的因素。
先看下我们上篇文章写的例子

02-内存影响因素.png

正常的class_getInstanceSize,是32，那我们干掉一些属性后呢？发现有减少

02-属性变量影响内存.png

这证明我们的属性是对内存有影响的，那成员变量应该也是一样的，我们添加后发现，确实影响了内存大小。

02-成员变量影响内存.png

02-成员变量影响内存2.png

那么方法呢？添加了一个方法后发现并没有变化，因为方法不占用内存，这个我们后续会再详细进行讲解。对于内存的理解我们可以先看下面的图。

02-内存画图举例.png

Person通过alloc开辟了一块堆的空间，外部通过对象的地址(栈里)来进行指向。这个内存空间里的就是Person里面的各项成员变量以及isa。

02-x:8gx输出.png

我们新增几条属性后，通过x/8gx输出看到，左边0x60000336b6c0为首地址，对应的第一个对象是0x0000000101968888，也就是isa。后面按顺序排列的依次是各个属性变量，每8字节一个对象，这也就是我们对齐原则。
需要注意的一点是我们的190.5是po不出来，我们可以使用e -f f-- 0x4067d00000000000,或者p/f 0x4067d00000000000.因为我们正常的po打印不出来，double与float类型需要单独输出打印

结构体内存对齐

刚才的例子中，我们发现第二个变量，0x0000001200006261实际上是3个变量组成的，0x12、0x62、0x61，这个是由于进行了响应的内存对齐，那我们就来看看结构体的内存对齐原则

1:数据成员对齐规则：结构(struct)(或联合(union))的数据成员，第一个数据成员放在offset为0的地方，以后每个数据成员存储的起始位置要从该成员大小或者成员的子成员大小（只要该成员有子成员，比如说是数组，结构体等）的整数倍开始(比如int在３２位机为４字节,则要从４的整数倍地址开始存储。

2:结构体作为成员:如果一个结构里有某些结构体成员,则结构体成员要从其内部最大元素大小的整数倍地址开始存储.(struct a里存有struct b,b里有char,int ,double等元素,那b应该从8的整数倍开始存储.)

3:收尾工作:结构体的总大小,也就是sizeof的结果,.必须是其内部最大成员的整数倍.不足的要补齐。

我们先来看两个结构体

struct HZMStruct1 {
    double a;      
    char b;        
    int c;          
    short d;        
}struct1;

struct HZMStruct2 {
    double a;       
    int b;          
    char c;        
    short d;        
}struct2;

这两个结构体的成员变量完全一样，只是顺序不一样，这样的两个结构体的sizeof会一样嘛？直接上结果

02-结构体的sizeof.png

Why？

    double a;       // 8字节    存储位置[0 7]
    char b;         // 1字节    [8]
    int c;          // 4字节    (9 10 11 [12 13 14 15]不是整数倍数的位置pass掉 
    short d;        // 2字节    [16 17] 24
}struct1;

struct HZMStruct2 {
    double a;       // 8字节    [0 7]
    int b;          // 4字节    [8 9 10 11]
    char c;         // 1字节    [12]
    short d;        // 2字节    (13 [14 15] 16
}struct2;

在我们存储的过程中，其实苹果会自动帮我们进行最优化排序

在上面的过程中，我们将不是当前对象的整数倍的存储位置pass掉了，这是为什么？我们通过画图来理解

02-内存对齐原因.png

当我们看到第一种取法，发现每次变化取值长度，一共需要3次才取完，而第二种取法直接按照最大长度去取，不够的位置空出来，后续如果有满足条件的在优化的过程中插进去(1+4+3->1+3+4)这样我们只需要两次就全部取完了，这与我们第一篇文章讲的字节对齐，以空间换时间，是异曲同工之妙。

下面我们再做一个练习巩固下

struct LGStruct3 {
    double a;     // 8字节    [0 7]
    int b;        // 4字节    [8 9 10 11]
    char c;       // 1字节    [12]
    short d;      // 2字节    (13 [14 15]   
    int e;        // 4字节    [16 17 18 19]   24
    struct HZMStruct1 str;    (20 21 22 23 [24~ 41]  ->48
}struct3;

malloc源码引入

02-LGPerson.png

02-malloc.png

第一个：<LGPerson: 0x100542960>应该不用过多解释了
第二个：我们可以理解为person是个对象，对象的本质就是指针地址，指针大小为8字节
第三个：LGPerson的各个成员变量相加，8+8+4+8=28 ->32 但是要注意还有一个isa，所以32+8=40
第四个：40->48是因为啥呢？我们看看malloc_size我们只能通过源码进行分析
接下来就就还是进入我们的源码文件进行分析

malloc分析探索思路

首先从alloc进入objc的源码，找到obj = (id)calloc(1, size);
操作，涉及的方法顺序是alloc --> _objc_rootAlloc --> callAlloc --> _objc_rootAllocWithZone --> _class_createInstanceFromZone

02-alloc源码探索.png

这里calloc的探索需要切换到 libmalloc源码中，可以在opensource下载最新版，接着往下走

1、在可编译的libmalloc中定义一个可编译的target，在main中使用calloc创建一个指针

02-libmalloc源码.png

2、进入_malloc_zone_calloc的源码实现，关键代码是1560行的zone->calloc(zone, num_items, size);

02-_malloc_zone_calloc.png

3、进入zone->alloc的源码，源码就无法继续跟进了

02-zone->alloc.png

重点：为了继续深入了解，我们在ptr = zone->calloc(zone, num_items, size);处，加一个断点，然后运行。
断住后，通过打印得知zone->calloc的源码实现在default_zone_calloc方法，然后全局搜索default_zone_calloc方法，找到具体实现