笔记-OC对象的本质

课堂引入

Q：p1和p2是同一个对象吗？

A：从打印结果看，显然p1和p2指向同一块内存地址

Q：同一块内存地址就一定是同一个对象吗？那么给p赋值再看

A：显然，p1和p2是同一个对象。且可以看出init方法并没有做什么，可以直接去掉，即alloc后p已经可以正常使用。那么alloc方法到底做了什么？

A：跳转到alloc的方法看一下，先去看一下官方文档中alloc方法的实现

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

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

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

看下实际调用代码的步骤，先在Person *p = [Person alloc];打个断点，跳转到22行objc_alloc

打个symbolic breakpoint(sb) ：alloc看一下alloc中的汇编实现

利用寄存器打印x0，确认是Person对象

点击向下按钮，进入_objc_rootAlloc函数的汇编里

在_objc_rootAlloc中并没有看到b跳转到源代码callAlloc函数中，这里是因为编译器优化掉一次函数调用，直接使用callAlloc的下级函数_objc_rootAllocWithZone的代码。

使用向下箭头跳转到ojbc_rootAllocWithZone里，找到23行ret指令，跳转到23行

ret指令表示return，此处返回的是个指针，使用寄存器命令register read x0在lldb中查看x0存储的参数，po打印出来是Person对象，说明创建了一个Person对象，说明alloc才是真正创建实例对象的方法，oc对象本身就是个结构体指针。

接下来看看init做了什么？

断点到init方法，直接看30行objc_msgSend，利用register查看x8，发现调用的是init方法

设置symbolic breakpoint: init断点，进入init，发现直接ret返回

查看oc源码，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;
}

发现init确实没做什么直接返回对象，所以其实继承NSObject后alloc就可以使用对象了。init是留给开发者进行重写的方法。

拓展知识点

寄存器的指令跟硬件有关，5s以后都是ARM64架构

64位？ 32位？和CPU有关-->数据吞吐量

一根电线 1个bit

32根电线 4个字节

64根电线 8个字节

理论上64位的效率是32位的2倍

真机debug，汇编知识点

• bl指令：跳转，调用函数
• 寄存器，在ARM64中有32个，用来暂存数据。X0-X7存放函数的参数，如objc_sendMsg(self, SEL)中self存放在X0，SEL存放在X1。lldb调试中使用register read x1命令查看寄存器x1内容
• b相当于bl，ret相当于return

编译器优化 ，跳过bl到下级函数，直接使用下级函数的代码，优化掉函数调用。bl需要访问内存，影响效率。编译器优化对应Build Settings中的Optimization Level设置。

演示Optimization Level设置

正常debug模式下，上面QA环节中debug模式配置也是如下，w0=1，w1=2，调用sum函数

w0和w1寄存器比x0和x1寄存器短，是32位的，有4个字节32bit位，用来节约性能。如传递int型，在64位中占用4个字节32bit，需要w寄存器就可以。

修改Debug的编译器优化

发现汇编代码量减少，且sum函数已经被优化掉了，直接算出结果w8=3，这就是编译器优化。

alloc到底是怎么创建对象的？？

查询oc源码alloc最终实现在_class_createInstanceFromZone函数

size算出要初始化对象的大小，其中extraBytes传入的是0

说明一个oc对象最小占用16个字节

word_align实现==>字节对齐：内存空间按照Byte字节划分，理论上任何数据的访问可以从任何的地址值开始，实际上访问特殊类型时经常进行空间排列。例如

内存地址	数据类型
001	short
002
003
004
005	int
006	int
007	int
008	int

一个short数据占据一个字节在001，假设有一个int数据，它在内存中占用4个字节。因为硬件问题，int数据并不是紧挨着short类型排列在002，可能是在005。CPU在访问时，如果是按照4个字节来访问，int按照这样对齐放置在005-008的话访问没问题。可是如果int型放在004-007，CPU先访问001-004获取部分int数据，再去访问005-008才能读取完整的int数据，效率较低，所以采用字节对齐。字节对齐的目的是兼容硬件，提高效率，利用空间换时间。

8字节对齐开辟空间肯定是8的倍数，如果有个9个字节的数据需要16个字节空间来存放。

word_align的实现：8的倍数的二进制低三位都是000，~按位取反

通过宏定义可以看出，64位下8字节对齐，32位下4字节对齐

资料

腾讯课堂-iOS底层进阶-OC对象的本质