前面咱们讨论了Runtime中对类和对象的处理,及对成员变量与属性的处理。这一章,咱们就要开始讨论Runtime中最有意思的一部分:消息处理机制。咱们将详细讨论消息的发送及消息的转发。不过在讨论消息以前,咱们先来了解一下与方法相关的一些内容。html
SEL又叫选择器,是表示一个方法的selector的指针,其定义以下:ios
typedef struct objc_selector *SEL;
objc_selector结构体的详细定义没有在<objc/runtime.h>头文件中找到。方法的selector用于表示运行时方法的名字。Objective-C在编译时,会依据每个方法的名字、参数序列,生成一个惟一的整型标识(Int类型的地址),这个标识就是SEL。以下代码所示:git
SEL sel1 = @selector(method1); NSLog(@"sel : %p", sel1);
上面的输出为:github
2014-10-30 18:40:07.518 RuntimeTest[52734:466626] sel : 0x100002d72
两个类之间,无论它们是父类与子类的关系,仍是之间没有这种关系,只要方法名相同,那么方法的SEL就是同样的。每个方法都对应着一个SEL。因此在Objective-C同一个类(及类的继承体系)中,不能存在2个同名的方法,即便参数类型不一样也不行。相同的方法只能对应一个SEL。这也就致使Objective-C在处理相同方法名且参数个数相同但类型不一样的方法方面的能力不好。如在某个类中定义如下两个方法:objective-c
- (void)setWidth:(int)width; - (void)setWidth:(double)width;
这样的定义被认为是一种编译错误,因此咱们不能像C++, C#那样。而是须要像下面这样来声明:xcode
-(void)setWidthIntValue:(int)width; -(void)setWidthDoubleValue:(double)width;
固然,不一样的类能够拥有相同的selector,这个没有问题。不一样类的实例对象执行相同的selector时,会在各自的方法列表中去根据selector去寻找本身对应的IMP。缓存
工程中的全部的SEL组成一个Set集合,Set的特色就是惟一,所以SEL是惟一的。所以,若是咱们想到这个方法集合中查找某个方法时,只须要去找到这个方法对应的SEL就好了,SEL实际上就是根据方法名hash化了的一个字符串,而对于字符串的比较仅仅须要比较他们的地址就能够了,能够说速度上无语伦比!!可是,有一个问题,就是数量增多会增大hash冲突而致使的性能降低(或是没有冲突,由于也可能用的是perfect hash)。可是无论使用什么样的方法加速,若是可以将总量减小(多个方法可能对应同一个SEL),那将是最犀利的方法。那么,咱们就不难理解,为何SEL仅仅是函数名了。数据结构
本质上,SEL只是一个指向方法的指针(准确的说,只是一个根据方法名hash化了的KEY值,能惟一表明一个方法),它的存在只是为了加快方法的查询速度。这个查找过程咱们将在下面讨论。架构
咱们能够在运行时添加新的selector,也能够在运行时获取已存在的selector,咱们能够经过下面三种方法来获取SEL:app
IMP其实是一个函数指针,指向方法实现的首地址。其定义以下:
id (*IMP)(id, SEL, ...)
这个函数使用当前CPU架构实现的标准的C调用约定。第一个参数是指向self的指针(若是是实例方法,则是类实例的内存地址;若是是类方法,则是指向元类的指针),第二个参数是方法选择器(selector),接下来是方法的实际参数列表。
前面介绍过的SEL就是为了查找方法的最终实现IMP的。因为每一个方法对应惟一的SEL,所以咱们能够经过SEL方便快速准确地得到它所对应的IMP,查找过程将在下面讨论。取得IMP后,咱们就得到了执行这个方法代码的入口点,此时,咱们就能够像调用普通的C语言函数同样来使用这个函数指针了。
经过取得IMP,咱们能够跳过Runtime的消息传递机制,直接执行IMP指向的函数实现,这样省去了Runtime消息传递过程当中所作的一系列查找操做,会比直接向对象发送消息高效一些。
介绍完SEL和IMP,咱们就能够来说讲Method了。Method用于表示类定义中的方法,则定义以下:
typedef struct objc_method *Method; struct objc_method { SEL method_name OBJC2_UNAVAILABLE; // 方法名 char *method_types OBJC2_UNAVAILABLE; IMP method_imp OBJC2_UNAVAILABLE; // 方法实现 }
咱们能够看到该结构体中包含一个SEL和IMP,实际上至关于在SEL和IMP之间做了一个映射。有了SEL,咱们即可以找到对应的IMP,从而调用方法的实现代码。具体操做流程咱们将在下面讨论。
objc_method_description定义了一个Objective-C方法,其定义以下:
struct objc_method_description { SEL name; char *types; };
Runtime提供了一系列的方法来处理与方法相关的操做。包括方法自己及SEL。本节咱们介绍一下这些函数。
方法操做相关函数包括下以:
// 调用指定方法的实现 id method_invoke ( id receiver, Method m, ... ); // 调用返回一个数据结构的方法的实现 void method_invoke_stret ( id receiver, Method m, ... ); // 获取方法名 SEL method_getName ( Method m ); // 返回方法的实现 IMP method_getImplementation ( Method m ); // 获取描述方法参数和返回值类型的字符串 const char * method_getTypeEncoding ( Method m ); // 获取方法的返回值类型的字符串 char * method_copyReturnType ( Method m ); // 获取方法的指定位置参数的类型字符串 char * method_copyArgumentType ( Method m, unsigned int index ); // 经过引用返回方法的返回值类型字符串 void method_getReturnType ( Method m, char *dst, size_t dst_len ); // 返回方法的参数的个数 unsigned int method_getNumberOfArguments ( Method m ); // 经过引用返回方法指定位置参数的类型字符串 void method_getArgumentType ( Method m, unsigned int index, char *dst, size_t dst_len ); // 返回指定方法的方法描述结构体 struct objc_method_description * method_getDescription ( Method m ); // 设置方法的实现 IMP method_setImplementation ( Method m, IMP imp ); // 交换两个方法的实现 void method_exchangeImplementations ( Method m1, Method m2 );
● method_invoke函数,返回的是实际实现的返回值。参数receiver不能为空。这个方法的效率会比method_getImplementation和method_getName更快。
● method_getName函数,返回的是一个SEL。若是想获取方法名的C字符串,可使用sel_getName(method_getName(method))。
● method_getReturnType函数,类型字符串会被拷贝到dst中。
● method_setImplementation函数,注意该函数返回值是方法以前的实现。
选择器相关的操做函数包括:
// 返回给定选择器指定的方法的名称 const char * sel_getName ( SEL sel ); // 在Objective-C Runtime系统中注册一个方法,将方法名映射到一个选择器,并返回这个选择器 SEL sel_registerName ( const char *str ); // 在Objective-C Runtime系统中注册一个方法 SEL sel_getUid ( const char *str ); // 比较两个选择器 BOOL sel_isEqual ( SEL lhs, SEL rhs );
● sel_registerName函数:在咱们将一个方法添加到类定义时,咱们必须在Objective-C Runtime系统中注册一个方法名以获取方法的选择器。
在Objective-C中,消息直到运行时才绑定到方法实现上。编译器会将消息表达式[receiver message]转化为一个消息函数的调用,即objc_msgSend。这个函数将消息接收者和方法名做为其基础参数,如如下所示:
objc_msgSend(receiver, selector)
若是消息中还有其它参数,则该方法的形式以下所示:
objc_msgSend(receiver, selector, arg1, arg2, ...)
这个函数完成了动态绑定的全部事情:
消息的关键在于咱们前面章节讨论过的结构体objc_class,这个结构体有两个字段是咱们在分发消息的关注的:
当咱们建立一个新对象时,先为其分配内存,并初始化其成员变量。其中isa指针也会被初始化,让对象能够访问类及类的继承体系。
下图演示了这样一个消息的基本框架:
当消息发送给一个对象时,objc_msgSend经过对象的isa指针获取到类的结构体,而后在方法分发表里面查找方法的selector。若是没有找到selector,则经过objc_msgSend结构体中的指向父类的指针找到其父类,并在父类的分发表里面查找方法的selector。依此,会一直沿着类的继承体系到达NSObject类。一旦定位到selector,函数会就获取到了实现的入口点,并传入相应的参数来执行方法的具体实现。若是最后没有定位到selector,则会走消息转发流程,这个咱们在后面讨论。
为了加速消息的处理,运行时系统缓存使用过的selector及对应的方法的地址。这点咱们在前面讨论过,再也不重复。
objc_msgSend有两个隐藏参数:
这两个参数为方法的实现提供了调用者的信息。之因此说是隐藏的,是由于它们在定义方法的源代码中没有声明。它们是在编译期被插入实现代码的。
虽然这些参数没有显示声明,但在代码中仍然能够引用它们。咱们可使用self来引用接收者对象,使用_cmd来引用选择器。以下代码所示:
- strange { id target = getTheReceiver(); SEL method = getTheMethod(); if ( target == self || method == _cmd ) return nil; return [target performSelector:method]; }
固然,这两个参数咱们用得比较多的是self,_cmd在实际中用得比较少。
Runtime中方法的动态绑定让咱们写代码时更具灵活性,如咱们能够把消息转发给咱们想要的对象,或者随意交换一个方法的实现等。不过灵活性的提高也带来了性能上的一些损耗。毕竟咱们须要去查找方法的实现,而不像函数调用来得那么直接。固然,方法的缓存必定程度上解决了这一问题。
咱们上面提到过,若是想要避开这种动态绑定方式,咱们能够获取方法实现的地址,而后像调用函数同样来直接调用它。特别是当咱们须要在一个循环内频繁地调用一个特定的方法时,经过这种方式能够提升程序的性能。
NSObject类提供了methodForSelector:方法,让咱们能够获取到方法的指针,而后经过这个指针来调用实现代码。咱们须要将methodForSelector:返回的指针转换为合适的函数类型,函数参数和返回值都须要匹配上。
咱们经过如下代码来看看methodForSelector:的使用:
void (*setter)(id, SEL, BOOL); int i; setter = (void (*)(id, SEL, BOOL))[target methodForSelector:@selector(setFilled:)]; for (i = 0 ; i < 1000 ; i++) setter(targetList[i], @selector(setFilled:), YES);
这里须要注意的就是函数指针的前两个参数必须是id和SEL。
固然这种方式只适合于在相似于for循环这种状况下频繁调用同一方法,以提升性能的状况。另外,methodForSelector:是由Cocoa运行时提供的;它不是Objective-C语言的特性。
当一个对象能接收一个消息时,就会走正常的方法调用流程。但若是一个对象没法接收指定消息时,又会发生什么事呢?默认状况下,若是是以[object message]的方式调用方法,若是object没法响应message消息时,编译器会报错。但若是是以perform…的形式来调用,则须要等到运行时才能肯定object是否能接收message消息。若是不能,则程序崩溃。
一般,当咱们不能肯定一个对象是否能接收某个消息时,会先调用respondsToSelector:来判断一下。以下代码所示:
if ([self respondsToSelector:@selector(method)]) { [self performSelector:@selector(method)]; }
不过,咱们这边想讨论下不使用respondsToSelector:判断的状况。这才是咱们这一节的重点。
当一个对象没法接收某一消息时,就会启动所谓”消息转发(message forwarding)“机制,经过这一机制,咱们能够告诉对象如何处理未知的消息。默认状况下,对象接收到未知的消息,会致使程序崩溃,经过控制台,咱们能够看到如下异常信息:
-[SUTRuntimeMethod method]: unrecognized selector sent to instance 0x100111940 *** Terminating app due to uncaught exception 'NSInvalidArgumentException', reason: '-[SUTRuntimeMethod method]: unrecognized selector sent to instance 0x100111940'
这段异常信息其实是由NSObject的”doesNotRecognizeSelector”方法抛出的。不过,咱们能够采起一些措施,让咱们的程序执行特定的逻辑,而避免程序的崩溃。
消息转发机制基本上分为三个步骤:
下面咱们详细讨论一下这三个步骤。
对象在接收到未知的消息时,首先会调用所属类的类方法+resolveInstanceMethod:(实例方法)或者+resolveClassMethod:(类方法)。在这个方法中,咱们有机会为该未知消息新增一个”处理方法”“。不过使用该方法的前提是咱们已经实现了该”处理方法”,只须要在运行时经过class_addMethod函数动态添加到类里面就能够了。以下代码所示:
void functionForMethod1(id self, SEL _cmd) { NSLog(@"%@, %p", self, _cmd); } + (BOOL)resolveInstanceMethod:(SEL)sel { NSString *selectorString = NSStringFromSelector(sel); if ([selectorString isEqualToString:@"method1"]) { class_addMethod(self.class, @selector(method1), (IMP)functionForMethod1, "@:"); } return [super resolveInstanceMethod:sel]; }
不过这种方案更多的是为了实现@dynamic属性。
若是在上一步没法处理消息,则Runtime会继续调如下方法:
- (id)forwardingTargetForSelector:(SEL)aSelector
若是一个对象实现了这个方法,并返回一个非nil的结果,则这个对象会做为消息的新接收者,且消息会被分发到这个对象。固然这个对象不能是self自身,不然就是出现无限循环。固然,若是咱们没有指定相应的对象来处理aSelector,则应该调用父类的实现来返回结果。
使用这个方法一般是在对象内部,可能还有一系列其它对象能处理该消息,咱们即可借这些对象来处理消息并返回,这样在对象外部看来,仍是由该对象亲自处理了这一消息。以下代码所示:
@interface SUTRuntimeMethodHelper : NSObject - (void)method2; @end @implementation SUTRuntimeMethodHelper - (void)method2 { NSLog(@"%@, %p", self, _cmd); } @end #pragma mark - @interface SUTRuntimeMethod () { SUTRuntimeMethodHelper *_helper; } @end @implementation SUTRuntimeMethod + (instancetype)object { return [[self alloc] init]; } - (instancetype)init { self = [super init]; if (self != nil) { _helper = [[SUTRuntimeMethodHelper alloc] init]; } return self; } - (void)test { [self performSelector:@selector(method2)]; } - (id)forwardingTargetForSelector:(SEL)aSelector { NSLog(@"forwardingTargetForSelector"); NSString *selectorString = NSStringFromSelector(aSelector); // 将消息转发给_helper来处理 if ([selectorString isEqualToString:@"method2"]) { return _helper; } return [super forwardingTargetForSelector:aSelector]; } @end
这一步合适于咱们只想将消息转发到另外一个能处理该消息的对象上。但这一步没法对消息进行处理,如操做消息的参数和返回值。
若是在上一步还不能处理未知消息,则惟一能作的就是启用完整的消息转发机制了。此时会调用如下方法:
- (void)forwardInvocation:(NSInvocation *)anInvocation
运行时系统会在这一步给消息接收者最后一次机会将消息转发给其它对象。对象会建立一个表示消息的NSInvocation对象,把与还没有处理的消息有关的所有细节都封装在anInvocation中,包括selector,目标(target)和参数。咱们能够在forwardInvocation方法中选择将消息转发给其它对象。
forwardInvocation:方法的实现有两个任务:
不过,在这个方法中咱们能够实现一些更复杂的功能,咱们能够对消息的内容进行修改,好比追回一个参数等,而后再去触发消息。另外,若发现某个消息不该由本类处理,则应调用父类的同名方法,以便继承体系中的每一个类都有机会处理此调用请求。
还有一个很重要的问题,咱们必须重写如下方法:
- (NSMethodSignature *)methodSignatureForSelector:(SEL)aSelector
消息转发机制使用从这个方法中获取的信息来建立NSInvocation对象。所以咱们必须重写这个方法,为给定的selector提供一个合适的方法签名。
完整的示例以下所示:
- (NSMethodSignature *)methodSignatureForSelector:(SEL)aSelector { NSMethodSignature *signature = [super methodSignatureForSelector:aSelector]; if (!signature) { if ([SUTRuntimeMethodHelper instancesRespondToSelector:aSelector]) { signature = [SUTRuntimeMethodHelper instanceMethodSignatureForSelector:aSelector]; } } return signature; } - (void)forwardInvocation:(NSInvocation *)anInvocation { if ([SUTRuntimeMethodHelper instancesRespondToSelector:anInvocation.selector]) { [anInvocation invokeWithTarget:_helper]; } }
NSObject的forwardInvocation:方法实现只是简单调用了doesNotRecognizeSelector:方法,它不会转发任何消息。这样,若是不在以上所述的三个步骤中处理未知消息,则会引起一个异常。
从某种意义上来说,forwardInvocation:就像一个未知消息的分发中心,将这些未知的消息转发给其它对象。或者也能够像一个运输站同样将全部未知消息都发送给同一个接收对象。这取决于具体的实现。
回过头来看第二和第三步,经过这两个方法咱们能够容许一个对象与其它对象创建关系,以处理某些未知消息,而表面上看仍然是该对象在处理消息。经过这种关系,咱们能够模拟“多重继承”的某些特性,让对象能够“继承”其它对象的特性来处理一些事情。不过,这二者间有一个重要的区别:多重继承将不一样的功能集成到一个对象中,它会让对象变得过大,涉及的东西过多;而消息转发将功能分解到独立的小的对象中,并经过某种方式将这些对象链接起来,并作相应的消息转发。
不过消息转发虽然相似于继承,但NSObject的一些方法仍是能区分二者。如respondsToSelector:和isKindOfClass:只能用于继承体系,而不能用于转发链。便若是咱们想让这种消息转发看起来像是继承,则能够重写这些方法,如如下代码所示:
- (BOOL)respondsToSelector:(SEL)aSelector { if ( [super respondsToSelector:aSelector]) return YES; else { /* Here, test whether the aSelector message can * * be forwarded to another object and whether that * * object can respond to it. Return YES if it can. */ } return NO; }
在此,咱们已经了解了Runtime中消息发送和转发的基本机制。这也是Runtime的强大之处,经过它,咱们能够为程序增长不少动态的行为,虽然咱们在实际开发中不多直接使用这些机制(如直接调用objc_msgSend),但了解它们有助于咱们更多地去了解底层的实现。其实在实际的编码过程当中,咱们也能够灵活地使用这些机制,去实现一些特殊的功能,如hook操做等。
注:若有不对之处,还请指正,欢迎加QQ好友:1318202110(南峰子)
http://southpeak.github.io/blog/2014/11/03/objective-c-runtime-yun-xing-shi-zhi-san-:fang-fa-yu-xiao-xi-zhuan-fa/