欢迎阅读iOS底层系列(建议按顺序)
本文概述
本文主要分析方法在底层的本质,方法发送的几种情况,方法查找流程等,结合cache_t,对消息发送流程有一个更宏观的理解。
面试坑点
先抛出一个面试题:
为什么子类可以调用类方法来实现NSObject的对象方法?
如果不深入了解方法查找流程,可能会有被卡住。下面就是对方法查找流程的分析(最后附加答案)。
runtime简述
上篇文章iOS底层-cache_t流程分析说明了cache_t缓存的是方法,那方法是什么,调用方法实际是在做什么。这些都和runtime
有密切关系。
a.runtime是什么
我们都知道oc
具有运行时特性,可是oc
底层是编译成c
,c++
这样的静态语言,是不具备运行时的。这时候iOS
底层就封装了一套由c
,c++
,汇编
写的api
,用来给oc
提供运行时功能,这就是runtime
。
b.runtime版本
runtime
是有个两个版本的:
-
legacy
-
modern
底层源码中使用!__OBJC2__
和__OBJC2__
来区分它们。现在使用的一般都是__OBJC2__
,所以我们基本可以忽略legacy
版本。
c.runtime的调用类型
runtime的调用只有三种类型
-
Objective - C Code (例:@Selector())
-
NSObject的方法 (例:performSelector())
-
runtime api(例:sel_registerName())
方法的本质
方法其实只是静静躺在class_rw_t
中的代码段,严格来说,这里应该是调用方法的本质。
先创建一个CJPerson类,初始化并调用方法,下面同时调用一个自定义函数。
void play(){
NSLog(@"%s",__func__);
}
int main(int argc, const char * argv[]) {
@autoreleasepool {
CJPerson *person = [CJPerson alloc];
[person work];
play();
}
return 0;
}
之前探索类的本质时,使用了clang
编译,这里也故技重施
clang -rewrite-objc main.m -o main.cpp
打开main.cpp
,直接来到最后
int main(int argc, const char * argv[]) {
/* @autoreleasepool */ { __AtAutoreleasePool __autoreleasepool;
CJPerson *person = ((CJPerson *(*)(id, SEL))(void *)objc_msgSend)((id)objc_getClass("CJPerson"), sel_registerName("alloc"));
((void (*)(id, SEL))(void *)objc_msgSend)((id)person, sel_registerName("work"));
play();
}
return 0;
}
整理下,去掉强转
int main(int argc, const char * argv[]) {
/* @autoreleasepool */ { __AtAutoreleasePool __autoreleasepool;
CJPerson *person = objc_msgSend(objc_getClass("CJPerson"), sel_registerName("alloc"));
objc_msgSend(person, sel_registerName("work"));
play();
}
return 0;
}
可以看到,调用方法就是通过objc_msgSend
来发送消息,可是调用play()
函数却没有发送消息。
其实,发送消息就是在找函数实现imp
的过程,paly()函数指针
直接对标到了函数实现,也就不需要发送消息了
objc_msgSend
这里有两个参数
- id 消息接收者
- sel 方法编号
假设存在缓存的情况,有了这两个参数就可以用id
在对应的cls
中的cache_t
,把sel
生成的key&mask
得到哈希下标,通过了解过iOS底层-cache_t流程分析,这里会比较清晰。
消息发送的几种区别
根据开发经验,方法一般有四种调用情况:本类对象方法,本类类方法,父类对象方法,父类类方法。
依次验证下,在创建一个CJStudent
类,继承于CJPerson
,两者声明各自的对象方法和类方法。在CJStudent
中调用,然后clang
编译(不要在意这里递归死循环,只看编译结果,不运行)
- (void)study{
[super work];//父类对象方法
[self study];//本类对象方法
}
+ (void)play{
[super buy];//父类类方法
[CJStudent play];//本类类方法
}
对应clang的结果部分(简化后):
static void _I_CJStudent_study(CJStudent * self, SEL _cmd) {
//父类对象方法
objc_msgSendSuper({self, class_getSuperclass(objc_getClass("CJStudent"))}, sel_registerName("work"));
//本类对象方法
objc_msgSend(self, sel_registerName("study"));
}
static void _C_CJStudent_play(Class self, SEL _cmd) {
//父类类方法
objc_msgSendSuper({self, class_getSuperclass(objc_getMetaClass("CJStudent"))}, sel_registerName("buy"));
//本类类方法
objc_msgSend(objc_getClass("CJStudent"), sel_registerName("play"));
}
综合结果如下:
方法类型 | 底层调用 | 消息接收者 | 传递父类 |
---|---|---|---|
本类对象方法 | objc_msgSend | self | 无 |
本类类方法 | objc_msgSend | self.class | 无 |
父类对象方法 | objc_msgSendSuper | self | 类的父类 |
父类类方法 | objc_msgSendSuper | self | 元类的父类 |
可以看出,这里最明显的区别在于,objc_msgSend和objc_msgSendSuper
基本可以确认,导致消息发送不一致的主要原因在于objc_msgSendSuper
,我们经常说的都是objc_msgSend
,那objc_msgSendSuper
又是怎么回事,只能点击它看下:
可以看到,和
objc_msgSend
的主要区别在于第一个参数objc_super
struct objc_super {
__unsafe_unretained _Nonnull id receiver;
#if !defined(__cplusplus) && !__OBJC2__
__unsafe_unretained _Nonnull Class class;
#else
__unsafe_unretained _Nonnull Class super_class;
#endif
};
objc_super
是个结构体,需要两个参数,一个是id receiver
,因为现在runtime
是__OBJC2__
版本,所以第二个是Class super_class
。
明白了参数的意思,上面的结论也就好理解了:
- 父类对象方法要去父类的方法列表查找
- 父类类方法要去父类的元类的方法列表查找
- 本类类方法对调用者主体是
class
- 需要注意,
super
调用objc_msgSendSuper
告诉系统 去父类方法列表里面去找,但是调用者主体还是self
方法查找流程
1.寻找切入点
到了这里,一切的源头都指向objc_msgSend
,老规矩,还是要去源码看一看。可是问题又来了,这源码这么多份,要去哪份里看呢?
提供一个思路:
根据目前已知条件,调用方法会执行objc_msgSend
,那在工程下一个objc_msgSend
符号断点,等跑到调用方法那一步时开启符号断点。断点来到:
居然发现,objc_msgSend
在objc
源码里面,总算定位到了一个小范围。
开开心心打开objc
源码,还是尝试搜索下objc_msgSend
,
有600多个相关,直接奔溃,看来此路不通,还要再想想换个搜索关键字。
换个角度想,objc_msgSend
是要被调用的方法,调用方法的一般格式为方法名()
,那就可以搜索下objc_msgSend(
,
搜索结果只有两个部分,
.h部分
和汇编部分
,首先,.h
可以排除,源码实现和调用不可能在.h
,那只剩下汇编
了,难道objc_msgSend
在底层是用汇编来实现的嘛。
回头想想,objc_msgSend
是可变参数的,对于静态语言c来说,不能有效识别,确实很有可能使用汇编来实现。
经过各方面资料研究后,确认了objc_msgSend
的快速查找由汇编实现,并得出两个原因:
- 在c语言中不可能通过函数来保留未知参数并跳转到任意的函数指针
objc_msgSend
在底层属于高频事件,对性能要求较高,必须足够快- 使用汇编可以有效防止系统函数被hook,更加安全
2.快速查找
既然知道了objc_msgSend
是汇编实现,那只能硬着头皮去看看汇编了。
这里选择从常用的
arm64
着手,一般看汇编是从入口ENTRY
开始,直接找到类似 ENTRY objc_msgSend
的地方就是要开始探索的地方
小知识点:x0 ~ x7存放参数,并且x0还存放返回值
1.对比第一个参数是否为空,也就是接收者self
2.判断self是否是TaggedPoint类型,此类型无需发送消息.
3.拿到第一个参数id的x0地址的值放在p13,也就是isa(参照对象和类的结构,首地址都是isa)
4.通过isa_mask得到class,这是p16等于class的原因,也就是获取方法所在的地方
5.查找isa完毕,先看看缓存里面有没有,也就是快速查找流程开始
这里扩展下④和⑤
④:GetClassFromIsa_p16
内部通过isa_mask得到class
⑤:CacheLookup NORMAL
* CacheLookup NORMAL|GETIMP|LOOKUP
*
* Locate the implementation for a selector in a class method cache.
*
* Takes:
* x1 = selector //第二个参数sel
* x16 = class to be searched //通过isa得到
*
CacheLookup
三种类型:正常(快速)查找|GETIMP|慢速查找
#define SUPERCLASS __SIZEOF_POINTER__
#define CACHE (2 * __SIZEOF_POINTER__)
1.x16平移CACHE(这里CACHE是定义为16字节的宏)得到cache_t,将cache_t的值取出来放在p10和p11。p10放buckets独占8位,p11放occupied和mask各占前后四位。
struct cache_t {
struct bucket_t *_buckets;//前8位
mask_t _mask;//4位
mask_t _occupied;//4位
}
2.用w1的_cmd & w11的mask 得到w12,也就是找方法的哈希下标。这里用w,因为mask类型是32位就够了,并且因为小端模式取后四位即为mask。
static inline mask_t cache_hash(cache_key_t key, mask_t mask) {
return (mask_t)(key & mask);
}
3.通过平移得到bucket的有效地址,然后从x12的bucket拿出imp放p17和sel放p9
4.开始对比bucket内的sel和传进来的cmd,NoEqual时候走2fCheckMiss流程和循环查找buckets,否则CacheHit缓存命中。
5,虽然调用了CheckMiss,但是CheckMiss有cbz判断sel是否为0,若不为0,则判断bucket ==buckets,Equal时候开始跳转到3f,否则开始循环递减查找buckets,循环递减查找buckets时,为了防止多线程更新缓存,有跳转1b重新查找流程;如果为0,也就是没有缓存,就开始__objc_msgSend_uncached慢速流程
.macro CheckMiss
// miss if bucket->sel == 0
.if $0 == GETIMP。
cbz p9, LGetImpMiss
.elseif $0 == NORMAL
cbz p9, __objc_msgSend_uncached
.elseif $0 == LOOKUP
cbz p9, __objc_msgLookup_uncached
6.重复上面③④⑤的查找流程,如果都找完了还是没有找到缓存,则直接跳转到JumpMiss,再强制跳转__objc_msgSend_uncached。
.macro JumpMiss
.if $0 == GETIMP
b LGetImpMiss
.elseif $0 == NORMAL
b __objc_msgSend_uncached
.elseif $0 == LOOKUP
b __objc_msgLookup_uncached
__objc_msgLookup_uncached
目前已知,如果缓存未命中,会来到__objc_msgLookup_uncached
,那看看其流程:
STATIC_ENTRY __objc_msgLookup_uncached
UNWIND __objc_msgLookup_uncached, FrameWithNoSaves
MethodTableLookup
ret
__objc_msgLookup_uncached流程内,只有MethodTableLookup
,看字面意思是方法列表查找,那么是直接就开始查找方法列表了嘛?也是用汇编进行查找嘛?只能继续往下看:
.macro MethodTableLookup
// push frame
SignLR
stp fp, lr, [sp, #-16]!
mov fp, sp
// save parameter registers: x0..x8, q0..q7
sub sp, sp, #(10*8 + 8*16)
stp q0, q1, [sp, #(0*16)]
stp q2, q3, [sp, #(2*16)]
stp q4, q5, [sp, #(4*16)]
stp q6, q7, [sp, #(6*16)]
stp x0, x1, [sp, #(8*16+0*8)]
stp x2, x3, [sp, #(8*16+2*8)]
stp x4, x5, [sp, #(8*16+4*8)]
stp x6, x7, [sp, #(8*16+6*8)]
str x8, [sp, #(8*16+8*8)]
// receiver and selector already in x0 and x1
mov x2, x16
bl __class_lookupMethodAndLoadCache3
挺长,前面一大段具体不太明白,但可以看出是地址操作,不影响我们阅读整体流程,准备完地址参数后,直接来到__class_lookupMethodAndLoadCache3
。
老规矩继续搜索__class_lookupMethodAndLoadCache3
,
会发现全部都是调用,尽然没有类似的实现过程,可能会觉得是苹果没有开源吧,如果是这样,到这里探索似乎就走到了尽头。
绝望的时候冷静下来想想,__class_lookupMethodAndLoadCache3
是在__objc_msgLookup_uncached
后,__objc_msgLookup_uncached又是在objc_msgSend
后。继续走刚才的objc_msgSend
符号断点,看看汇编调用是不是这样吧。
objc_msgSend
之后确实会来到__objc_msgLookup_uncached
,可是细看却是_objc_msgLookup_uncached
,前面少了个下划线。再去_objc_msgLookup_uncached
里面看看是否有调用__class_lookupMethodAndLoadCache3
_objc_msgLookup_uncached内确实调用了__class_lookupMethodAndLoadCache3,可是细看却是_class_lookupMethodAndLoadCache3
,前面也少了个下划线。并且标注了是在objc-runtime-new.mm的4846行
看到这里,好像发现了新大陆,难道底层是调用_class_lookupMethodAndLoadCache3
,直接搜索,
先找到标注所定位的地方,果然就找到了_class_lookupMethodAndLoadCache3
的实现。
这里从汇编跳转到c,因为慢速查找流程将要开始,这里也反向解释了为什么在调用_class_lookupMethodAndLoadCache3
前,有一段地址参数处理:
- 因为慢速查找流程要开始去c,c++,静态语言需要确定确定参数列表,所以需要准备工作)
以上就是objc_msgSend
的快速查找流程,也就是缓存查找。总的来说,快速查找就是在cache_t
中查找缓存,缓存命中则直接结束;查找完所有还未找到,就开始做慢速查找前的准备工作,并跳转到慢速查找流程。
3.慢速查找
直接来到_class_lookupMethodAndLoadCache3
,里面只调用了lookUpImpOrForward
。
IMP _class_lookupMethodAndLoadCache3(id obj, SEL sel, Class cls)
{
return lookUpImpOrForward(cls, sel, obj,
YES/*initialize*/, NO/*cache*/, YES/*resolver*/);
}
lookUpImpOrForward
方法较长,分为准备部分和查找部分给出,最后并给出验证和结论部分
a.准备部分
1.判断缓存是否存在,存在则直接通过cls和sel直接获取imp,并返回。
2.相关类信息判断
a.根据所有已知类的列表检查给定的类,有问题直接内部抛出异常。
b.判断类是否已经被实现,未实现则去实现,这部分后面类的加载章节会详细分析,主要是按照superclass和isa走向去递归实现父类和元类,同时准备好对象方法和类方法的查找链。
c.判断类是否被初始化,未初始化则去初始化。
b.查找部分
查找部分代码还是比较长,一个屏幕都容不下,因此分为上下两张
1.类准备好后,再次判断是否存在缓存(因为OC动态语言,随时随地都能操作修改),存在则直接通过cls和sel直接获取imp,并返回。
2.通过本类的方法列表查找(使用二分查找),如果找到meth,则先填充到缓存,然后返回。这里外层多用类一个{},形成局部作用域,防止meth重名。
3.递归查找父类的缓存
a.存在且不为消息转发类型的imp,则先填充到缓存,然后返回
b.存在且为消息转发类型的imp,则停止搜索,不会缓存这个方法,但会调用
4.找父类缓存结束且未找到时,查找父类的方法列表,如果找到meth,则先填充到缓存,然后返回。
5.递归查找完所有父类依然找不到imp时,开始方法转发流程,且只有一次。方法转发在下一章进行详细分析,
以上就是objc_msgSend
的慢速查找流程。总的来说,慢速查找就是从本类到父类最后到NSObject的方法查找链。先找本类的method_list
,找到则填充缓存;找不到在找父类的cache
和method_list
,找到则填充缓存;都找不到最后进行转发。
c.验证和结论部分
这里根据开发经验直接给出结论,只验证一个面试坑点
对象方法:
1.对象方法 - 自己有 - 成功;
2.对象方法 - 自己没有 - 找老爸的 - 成功;
3.对象方法 - 自己没有 - 老爸没有 - 找老爸的老爸 - NSObject - 成功;
4.对象方法 - 自己没有 - 老爸没有 - 找老爸的老爸 -> NSObject 也没有 - 崩溃;
类方法:
1.类方法 - 自己有 - 成功;
2.类方法 - 自己没有 - 老爸有 - 成功;
3.类方法 - 自己没有 - 老爸没有 - 找老爸的老爸 -> NSObject 也没有 - 没有有对象方法 - 奔溃
4.类方法 - 自己没有 - 老爸没有 - 找老爸的老爸 -> NSObject 也没有 - 有对象方法 - 成功
以上都符合我们认知中的查找流程,只有类方法的3
和4
,居然最后会去调用对象方法?天啦,这不符合oc世界观,调用类方法,居然去实现了对象方法。
提供一个验证方法:
在NSObject的分类中定义一个对象方法并实现,然后用任意类的类名调用此定义的对象方法。
分类声明
- (void)instanceMethod{
NSLog(@"%s--我是对象方法",__func__);
}
类名调用
int main(int argc, const char * argv[]) {
@autoreleasepool {
[CJPerson instanceMethod];
}
return 0;
}
执行后,果然成功了。这不符合常理的情况要怎么解释,其实从
isa
和supclass
的走位图,可以一探究竟。
回到开始的面试题:为什么子类可以调用类方法来实现NSObject的对象方法?
解释:通过类名调用,会依次走元类的方法列表,最后找到根元类的方法列表,但是都找不到对应的类方法;这时候,根元类的supclass指向了根类NSObject,所以去查找了NSObject的方法列表,因为NSObject的方法列表存放的是对象方法,因此找到了名为instanceMethod的对象方法。
写在最后
objc_msgSend
是iOS开发绕不过去的坎,其流程与cache_t流程分析有紧密联系。下一章是发送消息的最后一个部分--消息转发流程分析。敬请关注。