0. 环境准备
- 从GitHub下载可编译的objc4-818.2源码
- 在编译好的源码中添加
GLPerson类方便研究
1. 初探
为搞清研究方向，我们先来打印看看以下三个变量的值、内存地址、指针地址分别是什么
int main(int argc, const char * argv[]) {
@autoreleasepool {
GLPerson *p1 = [GLPerson alloc];
GLPerson *p2 = [p1 init];
GLPerson *p3 = [p1 init];
NSLog(@"p1 - %@, %p, %p", p1, p1, &p1);
NSLog(@"p2 - %@, %p, %p", p2, p2, &p2);
NSLog(@"p3 - %@, %p, %p", p3, p3, &p3);
}
return 0;
}
最终输出如下：
p1 - <GLPerson: 0x10060e850>, 0x10060e850, 0x7ffeefbff420
p2 - <GLPerson: 0x10060e850>, 0x10060e850, 0x7ffeefbff410
p3 - <GLPerson: 0x10060e850>, 0x10060e850, 0x7ffeefbff418
可以看出，三个对象的内存地址都是一致的，但指针地址不同。也就说明，alloc为对象分配了内存空间，init创建了新的指针指向这一片内存地址。
接下来让我们看看alloc和init在objc底层究竟做了些什么。
2. alloc流程分析
alloc流程图如下:
alloc流程
2.1 当调用[GLPerson alloc]方法时，通过断点调试，可发现，会进入objc_allc流程
// Calls [cls alloc].
id
objc_alloc(Class cls)
{
return callAlloc(cls, true/*checkNil*/, false/*allocWithZone*/);
}
此时传入callAlloc方法的allocWithZone为false，便会调用NSObject的+(id)alloc方法：
+ (id)alloc {
return _objc_rootAlloc(self);
}
最终会走回callAlloc方法，此时allocWithZone为true
// 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*/);
}
2.2 核心方法callAlloc：
static ALWAYS_INLINE id
callAlloc(Class cls, bool checkNil, bool allocWithZone=false)
{
#if __OBJC2__
if (slowpath(checkNil && !cls)) return nil;
// 若类中没有自定义的+allocWithZone方法，则走if中的实现
if (fastpath(!cls->ISA()->hasCustomAWZ())) {
return _objc_rootAllocWithZone(cls, nil);
}
#endif
// No shortcuts available.
// 没有编译器优化，或类中实现了+allocWithZone方法
if (allocWithZone) {
return ((id(*)(id, SEL, struct _NSZone *))objc_msgSend)(cls, @selector(allocWithZone:), nil);
}
return ((id(*)(id, SEL))objc_msgSend)(cls, @selector(alloc));
}
hasCustomAWZ()其实就是hasCustomAllocWithZone的缩写，来判断是否自己实现了allocWithZone方法。
2.3 无论类中是否实现了+allocWithZone方法，最终都会进入_objc_rootAllocWithZone，传入的额外需要的内存extraBytes为0
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);
}
2.4 跳转到_class_createInstanceFromZone方法的实现，这是整个alloc流程中最重要的部分，主要分为三步：
-
cls->instanceSize计算内存大小 -
calloc申请开辟内存空间 -
obj->initInstanceIsa初始化isa，关联到响应的类
//全局构造函数
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());
// 读取class bits中的缓存的位信息 以提高性能
// Read class's info bits all at once for performance
// hasCxxCtor() 是判断当前 class 或者 superclass 是否有 .cxx_construct 构造方法的实现。
bool hasCxxCtor = cxxConstruct && cls->hasCxxCtor();
// hasCxxDtor() 是判断判断当前 class 或者 superclass 是否有 .cxx_destruct 析构方法的实现
bool hasCxxDtor = cls->hasCxxDtor();
// 标记cls是否开启了isa指针优化
bool fast = cls->canAllocNonpointer();
size_t size;
// 计算内存大小，16字节对齐
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);
}
step 1. cls->instanceSize(extraBytes)
计算所需内存大小，这里传入的extraBytes为0
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.
// 最小16字节
if (size < 16) size = 16;
return size;
}
断点调试会进入cache.fastInstanceSize(extraBytes) 方法，快速计算内存大小
ize_t fastInstanceSize(size_t extra) const
{
ASSERT(hasFastInstanceSize(extra));
if (__builtin_constant_p(extra) && extra == 0) {
return _flags & FAST_CACHE_ALLOC_MASK16;
} else {
// 读取当前cls的实例大小
size_t size = _flags & FAST_CACHE_ALLOC_MASK;
// remove the FAST_CACHE_ALLOC_DELTA16 that was added
// by setFastInstanceSize
// 16字节内存对齐
return align16(size + extra - FAST_CACHE_ALLOC_DELTA16);
}
}
通过_flags & FAST_CACHE_ALLOC_MASK 获取存储在class的cache_t中的实例实际大小。
- 16字节的内存对齐
// size + extra - FAST_CACHE_ALLOC_DELTA16 删除在setFastInstanceSize方法中添加的FAST_CACHE_ALLOC_DELTA16 （8字节）
align16(size + extra - FAST_CACHE_ALLOC_DELTA16);
static inline size_t align16(size_t x) {
return (x + size_t(15)) & ~size_t(15);
}
内存对齐原则：
- 数据成员对齐规则：
结构体（struct）或联合体（union）的数据成员，第一个数据成员放在offset为0的地方，以后每个数据成员存储的起始位置要从该成员大小或成员的子成员大小（只要该成员有子成员，如数组、结构体等）的整数倍开始（如int为4字节，则要从4的整数倍的地址开始存储）。- 结构体作为成员：
如果一个结构体里有某些结构体成员，则结构体成员要从其内部最大元素大小的整数倍地址开始存储。- 最后：
结构体的总大小，也就是sizeof的结果，必须是其内部最大成员的整数倍，不足的要补齐。
为何在此流程中，使用的是16字节的内存对齐?
简单来说就是以时间换空间，保证CPU在读取的时候，按照块来读取就行，效率更高，同时不容易发生读取错乱。
苹果采取16字节对齐，是因为OC的对象中，第一位叫isa指针，它是必然存在的，而且它就占了8位字节，就算你的对象中没有其他的属性了，也一定有一个isa，那对象就至少要占用8位字节。如果以8位字节对齐的话，如果连续的两块内存都是没有属性的对象，那么它们的内存空间就会完全的挨在一起，是容易混乱的。
如果不对齐的话，在我们频繁的存取内存的时候，CPU就需要花费大量的精力去分辨你要读取多少字节，这就会造成CPU的效率低下，如果想要CPU又有效又不减少存取次数的话，那就需要找一个规范，这个规范就是字节对齐。
内存对齐算法
如GLPerson类中没有其它属性，则调用align16(8)方法：
(8 + size_t(15)) & ~size_t(15)
// 8 + 15 = 24 -> 0000 0000 0001 1000
// 15 -> 0000 0000 0000 1111
// ~15 -> 1111 1111 1111 0000
0000 0000 0001 1000
&1111 1111 1111 0000
=0000 0000 0001 0000 （16）
最终结果为16，即内存的大小是以16的倍数增加的。
step 2. calloc
由step 1中，获取到了当前cls需要开辟的内存大小，传入calloc方法:
obj = (id)calloc(1, size);
(lldb) po obj
0x0000000100705040
在此方法后，打印obj可以得到一个16进制的地址，calloc方法为对象分配了size大小的内存空间，并返回指向该内存地址的指针。
step 3. obj->initInstanceIsa
初始化isa，并与类进行关联
initInstanceIsa
-
isa结构
isa其实是一个
isa_t联合体，在联合体union中，所有成员共享一个内存地址，其内存大小取决于内部所占内存最大的那个成员，这也最大程度的优化了内存。
union isa_t {
isa_t() { }
isa_t(uintptr_t value) : bits(value) { }
uintptr_t bits;
private:
// Accessing the class requires custom ptrauth operations, so
// force clients to go through setClass/getClass by making this
// private.
Class cls;
public:
#if defined(ISA_BITFIELD)
struct {
ISA_BITFIELD; // defined in isa.h
};
bool isDeallocating() {
return extra_rc == 0 && has_sidetable_rc == 0;
}
void setDeallocating() {
extra_rc = 0;
has_sidetable_rc = 0;
}
#endif
void setClass(Class cls, objc_object *obj);
Class getClass(bool authenticated);
Class getDecodedClass(bool authenticated);
};
在上面这份isa_t定义中，有个结构体ISA_BITFIELD，其占8个字节，64位，下面看下这个结构体在arm64架构中都定义了些什么：
# define ISA_BITFIELD \
uintptr_t nonpointer : 1; /*是否开启指针优化*/ \
uintptr_t has_assoc : 1; /*关联对象标志位*/ \
uintptr_t has_cxx_dtor : 1; /*是否有OC\C++析构器*/ \
uintptr_t shiftcls : 33; /*存储类指针的值MACH_VM_MAX_ADDRESS 0x1000000000*/ \
uintptr_t magic : 6; /*调试器判断当前对象是真的对象还是没有初始化的空间*/ \
uintptr_t weakly_referenced : 1; /*该对象是否被弱引用*/ \
uintptr_t unused : 1; /*标志对象是否正在释放内存*/ \
uintptr_t has_sidetable_rc : 1; /*当对象引用计数大于 20 时，则需要借用该变量存储进位*/ \
uintptr_t extra_rc : 19 /*该对象的引用计数值-1*/
其中shiftcls、extra_rc在模拟器与真机架构中所占的位数并不一样。
在initInstanceIsa过程中，会对isa中的这些值进行赋值：
inline void
objc_object::initIsa(Class cls, bool nonpointer, UNUSED_WITHOUT_INDEXED_ISA_AND_DTOR_BIT bool hasCxxDtor)
{
ASSERT(!isTaggedPointer());
// 初始化isa
isa_t newisa(0);
if (!nonpointer) {
newisa.setClass(cls, this);
} else {
ASSERT(!DisableNonpointerIsa);
ASSERT(!cls->instancesRequireRawIsa());
#if SUPPORT_INDEXED_ISA
ASSERT(cls->classArrayIndex() > 0);
newisa.bits = ISA_INDEX_MAGIC_VALUE;
// isa.magic is part of ISA_MAGIC_VALUE
// isa.nonpointer is part of ISA_MAGIC_VALUE
newisa.has_cxx_dtor = hasCxxDtor;
newisa.indexcls = (uintptr_t)cls->classArrayIndex();
#else
newisa.bits = ISA_MAGIC_VALUE;
// isa.magic is part of ISA_MAGIC_VALUE
// isa.nonpointer is part of ISA_MAGIC_VALUE
# if ISA_HAS_CXX_DTOR_BIT
newisa.has_cxx_dtor = hasCxxDtor;
# endif
// 与cls进行关联
newisa.setClass(cls, this);
#endif
newisa.extra_rc = 1;
}
isa = newisa;
}
-
关联isa与cls
当完成上述
initInstanceIsa流程后，再来看打印下obj，发现可以得到当前的对象的指针了：
// initInstanceIsa前
(lldb) p obj
(id) $2 = 0x0000000100705040
// initInstanceIsa后
(lldb) p obj
(GLPerson *) $3 = 0x0000000100705040
3. init流程分析
init流程
+ (id)init {
return (id)self;
}
- (id)init {
return _objc_rootInit(self);
}
在_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;
}
在init的过程中，并未对传入的对象做处理，而是直接返回了对象自己。
4. new流程
当我们调用[GLPerson new]构造方法后，断点会进入：
+ (id)new {
return [callAlloc(self, false/*checkNil*/) init];
}
其内部其实就是相当于走了[alloc init]的流程
参考
https://juejin.cn/post/6844904020834779143
//www.greatytc.com/p/b72018e88a97
