一、对象的指针地址和内存
先看下面的代码：
HPerson * p1 = [HPerson alloc];
HPerson * p2 = [p1 init];
HPerson * p3 = [p1 init];
NSLog(@"%@-%p", p1, p1);
NSLog(@"%@-%p", p2, p2);
NSLog(@"%@-%p", p3, p3);
请问这3者的会有什么不同吗？
执行代码就会发现p1，p2，p3打印的内存地址是完全一样的:
所以在这个过程我们可以得出一个结论：
1、alloc让对象有了内存空间，有了指针指向。
2、init后内存没有变化，证明init没有对指针做什么操作。
再来看下面的代码：
HPerson * p1 = [HPerson alloc];
HPerson * p2 = [p1 init];
HPerson * p3 = [p1 init];
NSLog(@"%@-%p-%p", p1, p1, &p1);
NSLog(@"%@-%p-%p", p2, p2, &p2);
NSLog(@"%@-%p-%p", p3, p3, &p3);
执行：
发现3个不同的指针地址指向了同一块内存空间，而且是3个连续的指针地址。
那么alloc是怎么分配内存空间的呢？init真的什么都没有做吗？
二、探索底层的三种方法
如果我们直接进行代码跳转：
就会进入到NSObject的alloc方法：
发现找不到方法的实现！
为什么没有实现呢？我们应该如何去查看alloc方法的实行呢？
方法一：断点调试
我们先在alloc处打上断点：
然后按住ctrl点击step into：
即可看到，
alloc方法调用的是objc_alloc方法：
然后我们打上符号断点：
再点击继续执行程序:
然后我们就会发现objc_alloc来源于libobjc.A.dylib，即objc动态库底层方法：
方法二：利用汇编一步一步跟进
在debug选择栏打开进入汇编：
依旧在alloc处打上断点：
运行程序就会进入到汇编页面：
在该页面就会发现是调用了objc_alloc方法，然后用符号断点去查看该方法使用的哪个动态库。
方法三：通过已知方法进行符号断点
当程序停在我们的断点处时：
添加已知方法的符号断点：
然后进入：
就会发现alloc是来自libobjc.A.dylib动态库：
以上就是3中基本的探索底层的方式，还有反汇编、lldb、堆栈等等。
三、汇编结合源码调试分析
1、下载源码
我们已经定位到了alloc是在libobjc这个动态库里面，接下来就是进入源码进行调试。
先在苹果开源网站下载源码，或者在苹果的源代码目录进行下载，源代码目录更加方便。
以源代码目录为例：
进入网站后搜索objc：
找到objc4，点进去：
最新的objc4-824.tar.gz有问题，无法下载，所以使用的是objc4-818.2.tar.gz。
2、查看源码
打开下载的objc4-818.2，搜索alloc {:
发现alloc方法里面调用的是_objc_rootAlloc方法。
再点_objc_rootAlloc方法进去：
// 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*/);
}
发现_objc_rootAlloc方法里面是callAlloc方法。
再点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 __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));
}
这里就是alloc的核心方法。
__OBJC2__指的是2.0版本，现在用的都是2.0版本。
那么到了这里，是执行_objc_rootAllocWithZone呢？还是执行objc_msgSend呢？
3、汇编调试
我们可以通过汇编来查看，回到最开始的代码，在alloc处打上断点，于此再加上_objc_rootAlloc的符号断点：
运行：
运行后确实进入了_objc_rootAlloc方法，但是进入却是HPerson的父类NSObject的_objc_rootAlloc方法，我们应该进入的HPerson的方法才对！
所以需要先取消_objc_rootAlloc的断点重新运行，当断到了HPerson的alloc方法时，再加上_objc_rootAlloc的断点：
断住后，发现先执行_objc_rootAllocWithZone方法，再执行objc_msgSend方法。
4、源码调试
先按照iOS_objc4-756.2 最新源码编译调试配置下载下来的objc4-818.2。
在objc源码里面创建HObjectBuild这个targets，并创建HPerson这个类：
在main.m里面打上断点，并运行程序：
进入上面查看到的_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方法里：
/***********************************************************************
* class_createInstance
* fixme
* Locking: none
*
* Note: this function has been carefully written so that the fastpath
* takes no branch.
**********************************************************************/
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 {
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);
}
在_class_createInstanceFromZone方法内，发现返回的是obj这个对象，所以我们在obj这里打上断点：
继续执行程序：
发现obj已经有地址了，因为当前内存并未使用过，是脏内存地址！
点击step over，到calloc方法，内存地址没有发生变化：
在点击step over，执行完calloc方法后，发现obj的内存地址不一样了：
说明在calloc方法中对obj进行了内存地址赋值。
在打印中发现obj对象的类型是id，这是因为这个地址还没有绑定到我们的HPerson这类里面去，关联类的是isa！
继续执行，过了initInstanceIsa方法后再打印发现obj已经关联了HPerson类：
所以在initInstanceIsa方法内让isa关联了HPerson以及c++的方法和函数！
接下来就是返回obj，所有的alloc方法流程已经走完了！
四、字节对齐
重新运行，在_class_createInstanceFromZone方法的
size = cls->instanceSize(extraBytes);
打上断点：
发现需要额外增加的字节为
0。
然后进入到instanceSize方法：
inline 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;
}
在return处打上断点，继续：
发现进入到第一个return，说明有缓存。
然后进入fastInstanceSize方法：
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);
}
}
在return处打上断点，继续：
走的是第二个
return，而且size为16。
那么这个数据怎么来的呢？
如果没有缓存的话，就会走alignedInstanceSize方法，然后返回字节对齐的内存大小：
那么，一个对象的内存大小由什么来确定呢？
只有成员变量决定！
我们进入unalignedInstanceSize方法：
// May be unaligned depending on class's ivars.
uint32_t unalignedInstanceSize() const {
ASSERT(isRealized());
return data()->ro()->instanceSize;
}
发现大小是有instanceSize来决定的，即实例变量的大小！
depending on class's ivars.-->取决于类的ivars。
并且是编译完成的干净内存的大小！
所以是依赖于成员变量的大小！
当前的HPerson对象没有成员变量，所以这里返回的大小是8：
为什么是8呢？因为NSObject有一个成员变量isa：
为什么isa的大小是8呢？
因为Class是一个结构体！isa是一个结构体指针，所以是8字节！
我们可以在源码里搜索objc_class：
发现Class是一个结构体指针类型！
而且objc_class继承于objc_object，即万物皆对象！即类也是一个对象！
返回大小8字节后，如果小于16字节则等于16：
所以得出16字节！
如果大于16呢？
就会进行字节对齐！
进入到alignedInstanceSize方法：
// Class's ivar size rounded up to a pointer-size boundary.
uint32_t alignedInstanceSize() const {
return word_align(unalignedInstanceSize());
}
里面有word_align方法：
static inline uint32_t word_align(uint32_t x) {
return (x + WORD_MASK) & ~WORD_MASK;
}
这个就是字节对齐算法！
点进WORD_MASK：
#ifdef __LP64__
# define WORD_SHIFT 3UL
# define WORD_MASK 7UL
# define WORD_BITS 64
#else
# define WORD_SHIFT 2UL
# define WORD_MASK 3UL
# define WORD_BITS 32
#endif
发现WORD_MASK等于7！
按照(x + WORD_MASK) & ~WORD_MASK这个算法，x为8：
(x + WORD_MASK) & ~WORD_MASK
= (8 + 7) & ~7
= 15 & ~7
转为二进制：
15 为：0000 1111
7 为：0000 0111
~7 为：1111 1000
所以：
15 & ~7
= 0000 1111 & 1111 1000
= 0000 1000
转为十进制为：8
但是为9的时候则为16！
所以这是一个以8字节对齐，向上取8的整数的方法！
为什么是8的倍数呢？
因为最大就是指针，8字节！同时也是为了空间换时间，方便内存读取！
五、对象的内存空间
先给HPerson添加对象：
打上断点，运行，然后在lldb中输入x p，显示对象p的内存分布:
0x108f079c0是对象p的内存首地址，接下来就是对象p的内存。
iOS端为小端模式，所有需要倒着读取：
内存打印出来是什么呢？
是isa！
为什么没有打印出isa呢？
因为要&ISA_MASK:
# if __arm64__
// ARM64 simulators have a larger address space, so use the ARM64e
// scheme even when simulators build for ARM64-not-e.
# if __has_feature(ptrauth_calls) || TARGET_OS_SIMULATOR
# define ISA_MASK 0x007ffffffffffff8ULL
# else
# define ISA_MASK 0x0000000ffffffff8ULL
# endif
这里使用的是模拟器，所以&0x0000000ffffffff8:
现在就正确的打印出
isa了！
后面的0则为对象的属性的存储空间！
进入debug查看一下内存：
输入内存首地址：
发现即使没有给属性赋值，依旧会开辟内存！
给属性赋值后再运行：
x/5gx为格式化输出！
如果把height改为BOOL类型：
就会发现age和height放在了一起！
这是苹果的底层对内存进行了优化，即内存对齐！
