前言
我们在开发过程中，接触最多的就是[[NSObjec alloc] init]或者[NSObject New]了，因此想要探究OC的底层原理，我们先从alloc&init&New入手，看看它们内部是如何实现的。
目录
image.png
简介
我们知道[[NSObejct alloc] init]是创建了一个对象并初始化，即申请为对象开辟申请一段内存，初始化对象的一些属性。所以我们在开始探究前抛出2个问题。
- 问题1：alloc内部如何申请开辟内存的？
- 问题2：alloc如何把申请的内存空间指针和类进行关联？
探究思路
- 方式一：通过符号断点跟踪调试分析
- 方式二：通过阅读源码分析，因为从官方下载的objc源码是无法编译调试运行的
- 方式三：配置objc源码，让其可以编译运行，通过运行可编译的源码结合demo进行调试分析
方式一比较麻烦，局限性很大，就不介绍了。
方式二能够让我们了解alloc的实现流程，但是OC底层源码实现有很多的分支，具体会走哪些分支我们不确定，也存在一定的局限性。
方式三能够就像我们学习一个三方库一样，通过配合断点或者日志来快速了解一个功能的实现流程，但是如何配置呢？官方下载的objc源码不能运行时因为依赖其他库的相关文件，这些文件没有不在我们下载的objc源码里，需要我们自己找到依赖文件配置到项目中。具体配置不在不在这里描述，这里提供了可编译的objc4源码：
objc4可编译调试源码项目
本文以objc4-750版本进行分析介绍。
我们可以先简单大致阅读一下alloc在objc源码的实现，然后运行demo结合断点、日志的方式来探究alloc的实现流程。
Person.h：
@interface Person : NSObject
@property (nonatomic, assign) NSUInteger age;
@property (nonatomic, assign) NSUInteger height;
@property (nonatomic, assign) NSUInteger weight;
@end
在main.m添加:
int main(int argc, const char * argv[]) {
@autoreleasepool {
// insert code here...
NSLog(@"Hello, World!");
Person *person = [Person alloc];
FHLog(@"[Person class] is %p ",[Person class]);
}
return 0;
}
NSObject.mm
+ (id)alloc {
print_D("self:%p",self);
return _objc_rootAlloc(self);
}
id
_objc_rootAlloc(Class cls)
{
print_D("cls:%p",cls);
return callAlloc(cls, false/*checkNil*/, true/*allocWithZone*/);
}
通过阅读源码我们发现alloc的主体函数调用流程如下：
image.png
callAlloc内部分支较多，会根据情况再调用不同的函数，这个我们先暂时不关注，后面会进行分析。
但实际是否如此？我们来验证一下：
- 解释一下FHLog(@"[Person class] is %p ",[Person class]);里面的%p为什么对应[Person class]，而不是&[Person class]，理解的可以跳过此处。
我们要打印的是Person类的地址，[Person class]返回的是一个Class，即我们说的类，根据源码
typedef struct objc_class *Class;
Class实际上就是struct objc_class*,是一个结构体指针
相当于把struct objc_class *p = [Person class];分解为
struct objc_class personClass = [Person class];
struct objc_class *p = &personClass;;
根据上面我们可以把FHLog(@"[Person class] is %p ",[Person class]);替换为
FHLog(@"[Person class] is %p ",&personClass)，这样大家就好理解了;
- 我们可以通过下断点方式进行验证，也可以通过Log方式验证。我采用在关键路径上添加Log，通过观察Log来分析函数的调用流程。
修改NSObject.mm文件，在相关方法入口添加日志”
+ (id)alloc {
print_D("self:%p",self);
return _objc_rootAlloc(self);
}
id
_objc_rootAlloc(Class cls)
{
print_D("cls:%p",cls);
return callAlloc(cls, false/*checkNil*/, true/*allocWithZone*/);
}
callAlloc(Class cls, bool checkNil, bool allocWithZone=false)
{
print_D("cls:%p,checkNil:%d,allocWithZone:%d",cls,checkNil,allocWithZone);
// 下面代码暂时省略.....
}
然后我们运行项目，观察日志的输出情况：
image.png
通过log分析，发现和我们从源码阅读分析的不一致，是按照[Person alloc]->objc_alloc->callAlloc->[NSObject alloc]->_objc_rootAlloc->callAlloc顺序调用。
那么问题来了，为什么在[Person alloc]后没有调用+ (id)alloc，而先走的是id
objc_alloc(Class cls)？
当我们调用一个OC方法，实际上就是发送一条消息SEL,而在系统会把SEL和真正的函数实现IMP进行关联。
由此又引申出其他的问题了，
- 问题3：那么SEL_alloc是在什么时候和IMP进行了绑定？
- 问题4：SEL_alloc如何实现和IMP_objc_alloc实现绑定？
通过全局搜索objc_alloc，一个个分析，发现在在objc-runtime-new.mm文件中有如下代码
fixupMessageRef方法中有一个判断
static void
fixupMessageRef(message_ref_t *msg)
{
msg->sel = sel_registerName((const char *)msg->sel);
if (msg->imp == &objc_msgSend_fixup) {
if (msg->sel == SEL_alloc) {
msg->imp = (IMP)&objc_alloc;
}
...
/**
* 以下代码省略
*/
}
}
发现这里有相关的代码把SEL_alloc和objc_alloc的函数地址进行了关联，于是添加相关日志，发现这里没有打印，说明我们在运行程序的时候并没有走到这里。
那么可以推断这里的fixupMessageRef不是在运行的时候执行的，可能在程序编译或者链接阶段的时候就执行了，从而完成了SEL和IMP的绑定操作。
全局搜索一下这个函数，发现这个函数的调用是在objc-runtime-new.mm文件(2624行处)的_read_images里，通过阅读方法注释
/***********************************************************************
* _read_images
* Perform initial processing of the headers in the linked
* list beginning with headerList.
*
* Called by: map_images_nolock
*
* Locking: runtimeLock acquired by map_images
**********************************************************************/
可以知道是在程序链接阶段执行的，所以我们推断SEL和IMP的绑定应该是在程序链接阶段的时候就完成了。
用MachOView打开我们刚刚编译的工程文件可以看到
原因是系统做了符号绑定，alloc方法会关联到一个名称为''alloc"的SEL（消息），而系统把SEL_alloc和真正的函数实现(IMP)&objc_alloc进行绑定。
image.png
所以[Person alloc]的实际的流程如下
image.png
不管从源码的分析和我们实际运行得到的流程上来看，目前的关键实现就在callAlloc函数，通过分析callAlloc源码我们得到如下流程
image.png
我们在修改callAlloc函数添加相应的日志如下：
static ALWAYS_INLINE id
callAlloc(Class cls, bool checkNil, bool allocWithZone=false)
{
print_D("cls:%p,checkNil:%d,allocWithZone:%d",cls,checkNil,allocWithZone);
if (slowpath(checkNil && !cls)) {
print_D("cls:%p,checkNil:%d,allocWithZone:%d,return nil",cls,checkNil,allocWithZone);
return nil;
};
#if __OBJC2__
if (fastpath(!cls->ISA()->hasCustomAWZ())) {
print_D("cls:%p,!cls->ISA()->hasCustomAWZ()) is true",cls);
// No alloc/allocWithZone implementation. Go straight to the allocator.
// fixme store hasCustomAWZ in the non-meta class and
// add it to canAllocFast's summary
if (fastpath(cls->canAllocFast())) {
print_D("cls:%p,cls->canAllocFast()) is true",cls);
// No ctors, raw isa, etc. Go straight to the metal.
bool dtor = cls->hasCxxDtor();
print_D("cls:%p,cls->canAllocFast()) is true,call calloc(1, cls->bits.fastInstanceSize());",cls);
id obj = (id)calloc(1, cls->bits.fastInstanceSize());
if (slowpath(!obj)) {
print_D("cls:%p,obj is null,call callBadAllocHandler(cls)",cls);
return callBadAllocHandler(cls);
};
print_D("cls:%p,obj is not nill,call obj->initInstanceIsa(cls, dtor),then return obj",cls);
obj->initInstanceIsa(cls, dtor);
return obj;
}
else {
// Has ctor or raw isa or something. Use the slower path.
print_D("cls:%p,cls->canAllocFast() is false,call class_createInstance(cls, 0)",cls);
id obj = class_createInstance(cls, 0);
if (slowpath(!obj)) {
print_D("cls:%p,cls->canAllocFast() is false,obj is null,call callBadAllocHandler(cls)",cls);
return callBadAllocHandler(cls);
}
print_D("cls:%p,cls->canAllocFast() is false,obj is not null,return obj",cls);
return obj;
}
}
#endif
// No shortcuts available.
if (allocWithZone) {
print_D("cls:%p,allocWithZone is true,call [cls allocWithZone:nil]",cls);
return [cls allocWithZone:nil];
}
print_D("cls:%p,allocWithZone is false,call [cls alloc]",cls);
return [cls alloc];
}
然后运行程序，打印日志如下：
image.png
- 通过日志我们可以清晰的看到callAlloc函数内部的执行情况
- 第一次执行callAlloc的时候，内部只调用了[cls alloc]，从而调用NSObject的+(id)alloc方法，接下来是_objc_rootAlloc
- _objc_rootAlloc内部调用callAlloc函数，传入checkNil:false,allocWithZone:true，完成了对callAlloc函数的第二次调用
- 分析callAlloc的第二次调用日志，调用了class_createInstance函数
id obj = class_createInstance(cls, 0);
return obj;
- 到这里说明class_createInstance是创建对象的关键，从命名上看这个函数创建了一个类的实例，那么我们继续探究class_createInstance内部做了什么。
id
class_createInstance(Class cls, size_t extraBytes)
{
print_D("cls:%p",cls);
return _class_createInstanceFromZone(cls, extraBytes, nil);
}
class_createInstance内部调用_class_createInstanceFromZone，_class_createInstanceFromZone顾名思义，从空间创建一个类的实例，继续看_class_createInstanceFromZone，我在方法里添加了一些注释
static __attribute__((always_inline))
id
_class_createInstanceFromZone(Class cls, size_t extraBytes, void *zone,
bool cxxConstruct = true,
size_t *outAllocatedSize = nil)
{
if (!cls) return nil;
assert(cls->isRealized());
// Read class's info bits all at once for performance
bool hasCxxCtor = cls->hasCxxCtor();
bool hasCxxDtor = cls->hasCxxDtor();
bool fast = cls->canAllocNonpointer();
// 1.根据extraBytes计算对象的内存空间大小
size_t size = cls->instanceSize(extraBytes);
if (outAllocatedSize) *outAllocatedSize = size;
id obj;
if (!zone && fast) {
// 2.根据计算的size为obj申请分配内存
obj = (id)calloc(1, size);
if (!obj) return nil;
// 3.初始化对象的isa指针,obj->initInstanceIsa(cls, hasCxxDtor)<==>initIsa(cls, true, hasCxxDtor);
obj->initInstanceIsa(cls, hasCxxDtor);
}
else {
if (zone) {
obj = (id)malloc_zone_calloc ((malloc_zone_t *)zone, 1, size);
} else {
// 2.根据计算的size为obj申请分配内存
obj = (id)calloc(1, size);
}
if (!obj) return nil;
// Use raw pointer isa on the assumption that they might be
// doing something weird with the zone or RR.
// 3.初始化对象的isa指针,initIsa(cls)==>initIsa(cls, true, hasCxxDtor)
obj->initIsa(cls);
}
if (cxxConstruct && hasCxxCtor) {
obj = _objc_constructOrFree(obj, cls);
}
return obj;
}
initInstanceIsa的实现
inline void
objc_object::initInstanceIsa(Class cls, bool hasCxxDtor)
{
assert(!cls->instancesRequireRawIsa());
assert(hasCxxDtor == cls->hasCxxDtor());
initIsa(cls, true, hasCxxDtor);
}
obj->initIsa(cls)的实现
inline void
objc_object::initIsa(Class cls)
{
initIsa(cls, false, false);
}
- 分析_class_createInstanceFromZone源码，里面主要完成2件事：
1.计算对象所占内存空间的大小并向系统申请分配内存空间
size_t size = cls->instanceSize(extraBytes);
...
obj = (id)calloc(1, size);
2.初始化对象的isa
obj->initInstanceIsa(cls, hasCxxDtor);
这里我们断点配合lldb命令来查看一下在执行obj->initInstanceIsa前后的变化
obj的description的
isa&cls.gif
-
可以看到，是obj->initInstanceIsa完成了申请的内存空间和类（传入的class）的关联。
-
calloc函数是来自malloc库，功能是开辟内存空间,相较于malloc函数，calloc函数会自动将内存初始化为0。参考百度百科-calloc
现在我们对前面提到的4个问题进行总结：
-
问题1：alloc内部如何申请开辟内存的？
答：通过前面的流程分析我们知道，是在第二次调用callAlloc函数的时候，在callAlloc内通过调用class_createInstance，在class_createInstance内部调用并返回_class_createInstanceFromZone，
在_class_createInstanceFromZone内部通过calloc函数将为我们的结构体指针申请开辟了内存。 -
问题2：alloc如何把申请的内存空间和类进行关联？
答：在_class_createInstanceFromZone函数内部申请开辟内存后，通过调用obj的initInstanceIsa函数，将传入class和申请到的空间指针关联到一起。 -
问题3：SEL_alloc是在什么时候和IMP进行了绑定？
答：是在程序链接阶段，读取镜像文件的时候完成了绑定。 -
问题4：SEL_alloc如何实现和IMP_objc_alloc实现绑定？
答：在fixupMessageRef内部里实现了绑定。fixupMessageRef内部有一个判断
if (msg->sel == SEL_alloc) {
msg->imp = (IMP)&objc_alloc;
}
完整的alloc流程如下：
image.png
init
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;
}
- 结合前面的alloc分析，alloc最终返回obj，再结合init源码，init内部并没有做其他的处理，直接把alloc后的obj返回。
- apple提供这么一个方法的意义在于，为提供一个接口让子类根据自身情况进行相应的重写init，可以理解是一种工厂设计。
概括一下alloc,init，New的实现流程和作用
image.png
New
New的实现如下：
+ (id)new {
return [callAlloc(self, false/*checkNil*/) init];
}
- 结合前面的alloc分析，callAlloc最终返回obj，相比[[XXCls alloc] init]少调用了_objc_rootAlloc和[NSObject alloc]和一次callAlloc，然后调用再init，减少了一些函数调用的开销，。
- 实际开发中考虑到可读性和编码规范,一般不会采用New的方式，大多采用alloc+init方式。
总结
image.png
- 本文探究了alloc&init&New的内部实现流程进行了详细的介绍。
- alloc后返回了一个id类型的obj，这个就是我们创建的对象。那么对象究竟是什么？对象里有什么？cls->instanceSize是如何计算对象所占的内存空间的？我会在下一篇继续分享。
网友评论