笔记-OC对象的本质
笔记-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字节对齐
