Objective-c Run Time

（一）消息机制

最近在找工作，Objective-C中的Runtime是经常被问到的一个问题，几乎是面试大公司必问的一个问题。当然还有一些其他问题也几乎必问，例 如：RunLoop，Block，内存管理等。其他的问题如果有机会我会在其他文章中介绍。本篇文章主要介绍RunTime。

RunTime简称运行时。就是系统在运行的时候的一些机制，其中最主要的是消息机制。对于C语言，函数的调用在编译的时候会决定调用哪个函数（ C语言的函数调用请看这里 ）。编译完成之后直接顺序执行，无任何二义性。OC的函数调用成为消息发送。属于动态调用过程。在编译的时候并不能决定真正调用哪个函数（事实证明，在编 译阶段，OC可以调用任何函数，即使这个函数并未实现，只要申明过就不会报错。而C语言在编译阶段就会报错）。只有在真正运行的时候才会根据函数的名称找 到对应的函数来调用。

那OC是怎么实现动态调用的呢？下面我们来看看OC通过发送消息来达到动态调用的秘密。假如在OC中写了这样的一个代码：

1	[obj makeText];

其中obj是一个对象，makeText是一个函数名称。对于这样一个简单的调用。在编译时RunTime会将上述代码转化成

1	objc_msgSend(obj,@selector(makeText));

首先我们来看看obj这个对象，iOS中的obj都继承于NSObject。

1 2 3

@interface NSObject <NSObject> { Class isaOBJC_ISA_AVAILABILITY; }

在NSObjcet中存在一个Class的isa指针。然后我们看看Class：

1 2 3 4 5 6 7 8 9 10 11 12 13 14

typedef struct objc_class *Class; struct objc_class { Class isa; // 指向metaclass Class super_class ; // 指向其父类 const char *name ; // 类名 long version ; // 类的版本信息，初始化默认为0，可以通过runtime函数class_setVersion和class_getVersion进行修改、读取 long info; // 一些标识信息,如CLS_CLASS (0x1L) 表示该类为普通 class ，其中包含对象方法和成员变量;CLS_META (0x2L) 表示该类为 metaclass，其中包含类方法; long instance_size ; // 该类的实例变量大小(包括从父类继承下来的实例变量); struct objc_ivar_list *ivars; // 用于存储每个成员变量的地址 struct objc_method_list **methodLists ; // 与 info 的一些标志位有关,如CLS_CLASS (0x1L),则存储对象方法，如CLS_META (0x2L)，则存储类方法; struct objc_cache *cache; // 指向最近使用的方法的指针，用于提升效率； struct objc_protocol_list *protocols; // 存储该类遵守的协议 }

我们可以看到，对于一个Class类中，存在很多东西，下面我来一一解释一下：

Class isa：指向metaclass，也就是静态的Class。一般一个Obj对象中的isa会指向普通的Class，这个Class中存储普通成员变量和对 象方法（“-”开头的方法），普通Class中的isa指针指向静态Class，静态Class中存储static类型成员变量和类方法（“+”开头的方 法）。

Class super_class:指向父类，如果这个类是根类，则为NULL。

下面一张图片很好的描述了类和对象的继承关系：



注意：所有metaclass中isa指针都指向跟metaclass。而跟metaclass则指向自身。Root metaclass是通过继承Root class产生的。与root class结构体成员一致，也就是前面提到的结构。不同的是Root metaclass的isa指针指向自身。

Class类中其他的成员这里就先不做过多解释了，下面我们来看看：

@selector (makeText)：这是一个SEL方法选择器。SEL其主要作用是快速的通过方法名字（makeText）查找到对应方法的函数指针，然后调用其函 数。SEL其本身是一个Int类型的一个地址，地址中存放着方法的名字。对于一个类中。每一个方法对应着一个SEL。所以iOS类中不能存在2个名称相同 的方法，即使参数类型不同，因为SEL是根据方法名字生成的，相同的方法名称只能对应一个SEL。

下面我们就来看看具体消息发送之后是怎么来动态查找对应的方法的。

首先，编译器将代码[obj makeText];转化为objc_msgSend(obj, @selector (makeText));，在objc_msgSend函数中。首先通过obj的isa指针找到obj对应的class。在Class中先去cache中 通过SEL查找对应函数method（猜测cache中method列表是以SEL为key通过hash表来存储的，这样能提高函数查找速度），若 cache中未找到。再去methodList中查找，若methodlist中未找到，则取superClass中查找。若能找到，则将method加
入到cache中，以方便下次查找，并通过method中的函数指针跳转到对应的函数中去执行。
（二）成员变量与属性

本章的主要内容将聚集在Runtime对成员变量与属性的处理。在讨论之前，我们先介绍一个重要的概念：类型编码。

类型编码(Type Encoding)

作为对Runtime的补充，编译器将每个方法的返回值和参数类型编码为一个字符串，并将其与方法的selector关联在一起。这种编码方案在其它情况下也是非常有用的，因此我们可以使用@encode编译器指令来获取它。当给定一个类型时，@encode返回这个类型的字符串编码。这些类型可以是诸如int、指针这样的基本类型，也可以是结构体、类等类型。事实上，任何可以作为sizeof()操作参数的类型都可以用于@encode()。

在Objective-C Runtime Programming Guide中的Type
Encoding一节中，列出了Objective-C中所有的类型编码。需要注意的是这些类型很多是与我们用于存档和分发的编码类型是相同的。但有一些不能在存档时使用。

注：Objective-C不支持long double类型。@encode(long double)返回d，与double是一样的。

一个数组的类型编码位于方括号中；其中包含数组元素的个数及元素类型。如以下示例：

float a[] = {1.0, 2.0, 3.0};

NSLog(@"array encoding type: %s", @encode(typeof(a)));

输出是：

2014-10-28 11:44:54.731 RuntimeTest[942:50791] array encoding type: [3f]

其它类型可参考Type Encoding，在此不细说。

另外，还有些编码类型，@encode虽然不会直接返回它们，但它们可以作为协议中声明的方法的类型限定符。可以参考Type Encoding。

对于属性而言，还会有一些特殊的类型编码，以表明属性是只读、拷贝、retain等等，详情可以参考Property Type String。

成员变量、属性

Runtime中关于成员变量和属性的相关数据结构并不多，只有三个，并且都很简单。不过还有个非常实用但可能经常被忽视的特性，即关联对象，我们将在这小节中详细讨论。

基础数据类型

Ivar

Ivar是表示实例变量的类型，其实际是一个指向objc_ivar结构体的指针，其定义如下：

typedef struct objc_ivar *Ivar;

struct objc_ivar {

char *ivar_name OBJC2_UNAVAILABLE;// 变量名

char *ivar_type OBJC2_UNAVAILABLE;// 变量类型

int ivar_offset OBJC2_UNAVAILABLE;// 基地址偏移字节

#ifdef __LP64__

int space OBJC2_UNAVAILABLE;

#endif

}

objc_property_t

objc_property_t是表示Objective-C声明的属性的类型，其实际是指向objc_property结构体的指针，其定义如下：

typedef struct objc_property *objc_property_t;

objc_property_attribute_t

objc_property_attribute_t定义了属性的特性(attribute)，它是一个结构体，定义如下：

typedef struct {

const char *name; // 特性名

const char *value;// 特性值

} objc_property_attribute_t;

关联对象(Associated Object)

关联对象是Runtime中一个非常实用的特性，不过可能很容易被忽视。

关联对象类似于成员变量，不过是在运行时添加的。我们通常会把成员变量(Ivar)放在类声明的头文件中，或者放在类实现的@implementation后面。但这有一个缺点，我们不能在分类中添加成员变量。如果我们尝试在分类中添加新的成员变量，编译器会报错。

我们可能希望通过使用(甚至是滥用)全局变量来解决这个问题。但这些都不是Ivar，因为他们不会连接到一个单独的实例。因此，这种方法很少使用。

Objective-C针对这一问题，提供了一个解决方案：即关联对象(Associated Object)。

我们可以把关联对象想象成一个Objective-C对象(如字典)，这个对象通过给定的key连接到类的一个实例上。不过由于使用的是C接口，所以key是一个void指针(const void *)。我们还需要指定一个内存管理策略，以告诉Runtime如何管理这个对象的内存。这个内存管理的策略可以由以下值指定：

OBJC_ASSOCIATION_ASSIGN

OBJC_ASSOCIATION_RETAIN_NONATOMIC

OBJC_ASSOCIATION_COPY_NONATOMIC

OBJC_ASSOCIATION_RETAIN

OBJC_ASSOCIATION_COPY

当宿主对象被释放时，会根据指定的内存管理策略来处理关联对象。如果指定的策略是assign，则宿主释放时，关联对象不会被释放；而如果指定的是retain或者是copy，则宿主释放时，关联对象会被释放。我们甚至可以选择是否是自动retain/copy。当我们需要在多个线程中处理访问关联对象的多线程代码时，这就非常有用了。

我们将一个对象连接到其它对象所需要做的就是下面两行代码：

static char myKey;

objc_setAssociatedObject(self, &myKey, anObject, OBJC_ASSOCIATION_RETAIN);

在这种情况下，self对象将获取一个新的关联的对象anObject，且内存管理策略是自动retain关联对象，当self对象释放时，会自动release关联对象。另外，如果我们使用同一个key来关联另外一个对象时，也会自动释放之前关联的对象，这种情况下，先前的关联对象会被妥善地处理掉，并且新的对象会使用它的内存。

id anObject = objc_getAssociatedObject(self, &myKey);

我们可以使用objc_removeAssociatedObjects函数来移除一个关联对象，或者使用objc_setAssociatedObject函数将key指定的关联对象设置为nil。

我们下面来用实例演示一下关联对象的使用方法。

假定我们想要动态地将一个Tap手势操作连接到任何UIView中，并且根据需要指定点击后的实际操作。这时候我们就可以将一个手势对象及操作的block对象关联到我们的UIView对象中。这项任务分两部分。首先，如果需要，我们要创建一个手势识别对象并将它及block做为关联对象。如下代码所示：

- (void)setTapActionWithBlock:(void (^)(void))block

{

UITapGestureRecognizer *gesture = objc_getAssociatedObject(self, &kDTActionHandlerTapGestureKey);

if (!gesture)

{

gesture = [[UITapGestureRecognizer alloc] initWithTarget:self action:@selector(__handleActionForTapGesture:)];

[self addGestureRecognizer:gesture];

objc_setAssociatedObject(self, &kDTActionHandlerTapGestureKey, gesture, OBJC_ASSOCIATION_RETAIN);

}

objc_setAssociatedObject(self, &kDTActionHandlerTapBlockKey, block, OBJC_ASSOCIATION_COPY);

}

这段代码检测了手势识别的关联对象。如果没有，则创建并建立关联关系。同时，将传入的块对象连接到指定的key上。注意block对象的关联内存管理策略。

手势识别对象需要一个target和action，所以接下来我们定义处理方法：

- (void)__handleActionForTapGesture:(UITapGestureRecognizer *)gesture

{

if (gesture.state == UIGestureRecognizerStateRecognized)

{

void(^action)(void) = objc_getAssociatedObject(self, &kDTActionHandlerTapBlockKey);

if (action)

{

action();

}

}

}

我们需要检测手势识别对象的状态，因为我们只需要在点击手势被识别出来时才执行操作。

从上面的例子我们可以看到，关联对象使用起来并不复杂。它让我们可以动态地增强类现有的功能。我们可以在实际编码中灵活地运用这一特性。

成员变量、属性的操作方法

成员变量

成员变量操作包含以下函数：

// 获取成员变量名

const char * ivar_getName ( Ivar v );

// 获取成员变量类型编码

const char * ivar_getTypeEncoding ( Ivar v );

// 获取成员变量的偏移量

ptrdiff_t ivar_getOffset ( Ivar v );

● ivar_getOffset函数，对于类型id或其它对象类型的实例变量，可以调用object_getIvar和object_setIvar来直接访问成员变量，而不使用偏移量。

关联对象

关联对象操作函数包括以下：

// 设置关联对象

void objc_setAssociatedObject ( id object, const void *key, id value, objc_AssociationPolicy policy );

// 获取关联对象

id objc_getAssociatedObject ( id object, const void *key );

// 移除关联对象

void objc_removeAssociatedObjects ( id object );

关联对象及相关实例已经在前面讨论过了，在此不再重复。

属性

属性操作相关函数包括以下：

// 获取属性名

const char * property_getName ( objc_property_t property );

// 获取属性特性描述字符串

const char * property_getAttributes ( objc_property_t property );

// 获取属性中指定的特性

char * property_copyAttributeValue ( objc_property_t property, const char *attributeName );

// 获取属性的特性列表

objc_property_attribute_t * property_copyAttributeList ( objc_property_t property, unsigned int *outCount );

● property_copyAttributeValue函数，返回的char *在使用完后需要调用free()释放。

● property_copyAttributeList函数，返回值在使用完后需要调用free()释放。

实例

假定这样一个场景，我们从服务端两个不同的接口获取相同的字典数据，但这两个接口是由两个人写的，相同的信息使用了不同的字段表示。我们在接收到数据时，可将这些数据保存在相同的对象中。对象类如下定义：

@interface MyObject: NSObject

@property (nonatomic, copy) NSString * name;

@property (nonatomic, copy) NSString * status;

@end

接口A、B返回的字典数据如下所示：

@{@"name1": "张三", @"status1": @"start"}

@{@"name2": "张三", @"status2": @"end"}

通常的方法是写两个方法分别做转换，不过如果能灵活地运用Runtime的话，可以只实现一个转换方法，为此，我们需要先定义一个映射字典(全局变量)

static NSMutableDictionary *map = nil;

@implementation MyObject

+ (void)load

{

map = [NSMutableDictionary dictionary];

map[@"name1"]= @"name";

map[@"status1"]= @"status";

map[@"name2"]= @"name";

map[@"status2"]= @"status";

}

@end

上面的代码将两个字典中不同的字段映射到MyObject中相同的属性上，这样，转换方法可如下处理：

- (void)setDataWithDic:(NSDictionary *)dic

{

[dic enumerateKeysAndObjectsUsingBlock:^(NSString *key, id obj, BOOL *stop) {

NSString *propertyKey = [self propertyForKey:key];

if (propertyKey)

{

objc_property_t property = class_getProperty([self class], [propertyKey UTF8String]);

// TODO: 针对特殊数据类型做处理

NSString *attributeString = [NSString stringWithCString:property_getAttributes(property) encoding:NSUTF8StringEncoding];

...

[self setValue:obj forKey:propertyKey];

}

}];

}

当然，一个属性能否通过上面这种方式来处理的前提是其支持KVC。

小结

本章中我们讨论了Runtime中与成员变量和属性相关的内容。成员变量与属性是类的数据基础，合理地使用Runtime中的相关操作能让我们更加灵活地来处理与类数据相关的工作。

三：方法与消息

前面我们讨论了Runtime中对类和对象的处理，及对成员变量与属性的处理。这一章，我们就要开始讨论Runtime中最有意思的一部分：消息处理机制。我们将详细讨论消息的发送及消息的转发。不过在讨论消息之前，我们先来了解一下与方法相关的一些内容。
基础数据类型
SEL
SEL又叫选择器，是表示一个方法的selector的指针，其定义如下：

1	typedef struct objc_selector *SEL;

objc_selector结构体的详细定义没有在<objc/runtime.h>头文件中找到。方法的selector用于表示运行时方 法的名字。Objective-C在编译时，会依据每一个方法的名字、参数序列，生成一个唯一的整型标识(Int类型的地址)，这个标识就是SEL。如下 代码所示：

1 2	SEL sel1 = @selector(method1); NSLog(@ "sel : %p" , sel1);

上面的输出为：

1	2014-10-30 18:40:07.518 RuntimeTest[52734:466626] sel : 0x100002d72

两个类之间，不管它们是父类与子类的关系，还是之间没有这种关系，只要方法名相同，那么方法的SEL就是一样的。每一个方法都对应着一个SEL。所以在 Objective-C同一个类(及类的继承体系)中，不能存在2个同名的方法，即使参数类型不同也不行。相同的方法只能对应一个SEL。这也就导致 Objective-C在处理相同方法名且参数个数相同但类型不同的方法方面的能力很差。如在某个类中定义以下两个方法：

1 2	- (void)setWidth:(int)width; - (void)setWidth:(double)width;

当然，不同的类可以拥有相同的selector，这个没有问题。不同类的实例对象执行相同的selector时，会在各自的方法列表中去根据selector去寻找自己对应的IMP。
工程中的所有的SEL组成一个Set集合，Set的特点就是唯一，因此SEL是唯一的。因此，如果我们想到这个方法集合中查找某个方法时，只需要去 找到这个方法对应的SEL就行了，SEL实际上就是根据方法名hash化了的一个字符串，而对于字符串的比较仅仅需要比较他们的地址就可以了，可以说速度 上无语伦比！！但是，有一个问题，就是数量增多会增大hash冲突而导致的性能下降（或是没有冲突，因为也可能用的是perfect hash）。但是不管使用什么样的方法加速，如果能够将总量减少（多个方法可能对应同一个SEL），那将是最犀利的方法。那么，我们就不难理解，为什么
SEL仅仅是函数名了。
本质上，SEL只是一个指向方法的指针（准确的说，只是一个根据方法名hash化了的KEY值，能唯一代表一个方法），它的存在只是为了加快方法的查询速度。这个查找过程我们将在下面讨论。
我们可以在运行时添加新的selector，也可以在运行时获取已存在的selector，我们可以通过下面三种方法来获取SEL:
1. sel_registerName函数
2. Objective-C编译器提供的@selector()
3. NSSelectorFromString()方法
IMP
IMP实际上是一个函数指针，指向方法实现的首地址。其定义如下：

1	id (*IMP)(id, SEL, ...)

这个函数使用当前CPU架构实现的标准的C调用约定。第一个参数是指向self的指针(如果是实例方法，则是类实例的内存地址；如果是类方法，则是指向元类的指针)，第二个参数是方法选择器(selector)，接下来是方法的实际参数列表。
前面介绍过的SEL就是为了查找方法的最终实现IMP的。由于每个方法对应唯一的SEL，因此我们可以通过SEL方便快速准确地获得它所对应的 IMP，查找过程将在下面讨论。取得IMP后，我们就获得了执行这个方法代码的入口点，此时，我们就可以像调用普通的C语言函数一样来使用这个函数指针 了。
通过取得IMP，我们可以跳过Runtime的消息传递机制，直接执行IMP指向的函数实现，这样省去了Runtime消息传递过程中所做的一系列查找操作，会比直接向对象发送消息高效一些。
Method
介绍完SEL和IMP，我们就可以来讲讲Method了。Method用于表示类定义中的方法，则定义如下：

1 2 3 4 5 6 7

typedef struct objc_method *Method; struct objc_method { SEL method_name OBJC2_UNAVAILABLE; // 方法名 char *method_typesOBJC2_UNAVAILABLE; IMP method_impOBJC2_UNAVAILABLE; // 方法实现 }

我们可以看到该结构体中包含一个SEL和IMP，实际上相当于在SEL和IMP之间作了一个映射。有了SEL，我们便可以找到对应的IMP，从而调用方法的实现代码。具体操作流程我们将在下面讨论。
objc_method_description
objc_method_description定义了一个Objective-C方法，其定义如下：

1	struct objc_method_description { SEL name; char *types; };

方法相关操作函数
Runtime提供了一系列的方法来处理与方法相关的操作。包括方法本身及SEL。本节我们介绍一下这些函数。
方法
方法操作相关函数包括下以：

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38

// 调用指定方法的实现 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函数，注意该函数返回值是方法之前的实现。
方法选择器
选择器相关的操作函数包括：

1 2 3 4 5 6 7 8 9 10 11

// 返回给定选择器指定的方法的名称 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。这个函数将消息接收者和方法名作为其基础参数，如以下所示：

1	objc_msgSend(receiver, selector)

如果消息中还有其它参数，则该方法的形式如下所示：

1	objc_msgSend(receiver, selector, arg1, arg2, ...)

这个函数完成了动态绑定的所有事情：
1. 首先它找到selector对应的方法实现。因为同一个方法可能在不同的类中有不同的实现，所以我们需要依赖于接收者的类来找到的确切的实现。
2. 它调用方法实现，并将接收者对象及方法的所有参数传给它。
3. 最后，它将实现返回的值作为它自己的返回值。
消息的关键在于我们前面章节讨论过的结构体objc_class，这个结构体有两个字段是我们在分发消息的关注的：
1. 指向父类的指针
2. 一个类的方法分发表，即methodLists。
当我们创建一个新对象时，先为其分配内存，并初始化其成员变量。其中isa指针也会被初始化，让对象可以访问类及类的继承体系。
下图演示了这样一个消息的基本框架：



当消息发送给一个对象时，objc_msgSend通过对象的isa指针获取到类的结构体，然后在方法分发表里面查找方法的selector。如果 没有找到selector，则通过objc_msgSend结构体中的指向父类的指针找到其父类，并在父类的分发表里面查找方法的selector。依 此，会一直沿着类的继承体系到达NSObject类。一旦定位到selector，函数会就获取到了实现的入口点，并传入相应的参数来执行方法的具体实
现。如果最后没有定位到selector，则会走消息转发流程，这个我们在后面讨论。
为了加速消息的处理，运行时系统缓存使用过的selector及对应的方法的地址。这点我们在前面讨论过，不再重复。
隐藏参数
objc_msgSend有两个隐藏参数：
1. 消息接收对象
2. 方法的selector
这两个参数为方法的实现提供了调用者的信息。之所以说是隐藏的，是因为它们在定义方法的源代码中没有声明。它们是在编译期被插入实现代码的。
虽然这些参数没有显示声明，但在代码中仍然可以引用它们。我们可以使用self来引用接收者对象，使用_cmd来引用选择器。如下代码所示：

1 2 3 4 5 6 7 8 9

- strange { idtarget = getTheReceiver(); SEL method = getTheMethod(); if ( target == self || method == _cmd ) return nil; return [target performSelector:method]; }

当然，这两个参数我们用得比较多的是self，_cmd在实际中用得比较少。
获取方法地址
Runtime中方法的动态绑定让我们写代码时更具灵活性，如我们可以把消息转发给我们想要的对象，或者随意交换一个方法的实现等。不过灵活性的提 升也带来了性能上的一些损耗。毕竟我们需要去查找方法的实现，而不像函数调用来得那么直接。当然，方法的缓存一定程度上解决了这一问题。
我们上面提到过，如果想要避开这种动态绑定方式，我们可以获取方法实现的地址，然后像调用函数一样来直接调用它。特别是当我们需要在一个循环内频繁地调用一个特定的方法时，通过这种方式可以提高程序的性能。
NSObject类提供了methodForSelector:方法，让我们可以获取到方法的指针，然后通过这个指针来调用实现代码。我们需要将methodForSelector:返回的指针转换为合适的函数类型，函数参数和返回值都需要匹配上。
我们通过以下代码来看看methodForSelector:的使用：

1 2 3 4 5 6 7

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:来判断一下。如下代码所示：

1 2 3

if ([self respondsToSelector:@selector(method)]) { [self performSelector:@selector(method)]; }

不过，我们这边想讨论下不使用respondsToSelector:判断的情况。这才是我们这一节的重点。
当一个对象无法接收某一消息时，就会启动所谓”消息转发(message forwarding)“机制，通过这一机制，我们可以告诉对象如何处理未知的消息。默认情况下，对象接收到未知的消息，会导致程序崩溃，通过控制台，我们可以看到以下异常信息：

1 2	-[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”方法抛出的。不过，我们可以采取一些措施，让我们的程序执行特定的逻辑，而避免程序的崩溃。
消息转发机制基本上分为三个步骤：
1. 动态方法解析
2. 备用接收者
3. 完整转发
下面我们详细讨论一下这三个步骤。
动态方法解析
对象在接收到未知的消息时，首先会调用所属类的类方法+resolveInstanceMethod:(实例方法)或 者+resolveClassMethod:(类方法)。在这个方法中，我们有机会为该未知消息新增一个”处理方法”“。不过使用该方法的前提是我们已经 实现了该”处理方法”，只需要在运行时通过class_addMethod函数动态添加到类里面就可以了。如下代码所示：

1 2 3 4 5 6 7 8 9 10 11 12 13 14

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会继续调以下方法：

1	- (id)forwardingTargetForSelector:(SEL)aSelector

如果一个对象实现了这个方法，并返回一个非nil的结果，则这个对象会作为消息的新接收者，且消息会被分发到这个对象。当然这个对象不能是self自身，否则就是出现无限循环。当然，如果我们没有指定相应的对象来处理aSelector，则应该调用父类的实现来返回结果。
使用这个方法通常是在对象内部，可能还有一系列其它对象能处理该消息，我们便可借这些对象来处理消息并返回，这样在对象外部看来，还是由该对象亲自处理了这一消息。如下代码所示：

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56

@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

这一步合适于我们只想将消息转发到另一个能处理该消息的对象上。但这一步无法对消息进行处理，如操作消息的参数和返回值。
完整消息转发
如果在上一步还不能处理未知消息，则唯一能做的就是启用完整的消息转发机制了。此时会调用以下方法：

1	- (void)forwardInvocation:(NSInvocation *)anInvocation

运行时系统会在这一步给消息接收者最后一次机会将消息转发给其它对象。对象会创建一个表示消息的NSInvocation对象，把与尚未处理的消息 有关的全部细节都封装在anInvocation中，包括selector，目标(target)和参数。我们可以在forwardInvocation 方法中选择将消息转发给其它对象。
forwardInvocation:方法的实现有两个任务：
1. 定位可以响应封装在anInvocation中的消息的对象。这个对象不需要能处理所有未知消息。
2. 使用anInvocation作为参数，将消息发送到选中的对象。anInvocation将会保留调用结果，运行时系统会提取这一结果并将其发送到消息的原始发送者。
不过，在这个方法中我们可以实现一些更复杂的功能，我们可以对消息的内容进行修改，比如追回一个参数等，然后再去触发消息。另外，若发现某个消息不应由本类处理，则应调用父类的同名方法，以便继承体系中的每个类都有机会处理此调用请求。
还有一个很重要的问题，我们必须重写以下方法：

1	- (NSMethodSignature *)methodSignatureForSelector:(SEL)aSelector

消息转发机制使用从这个方法中获取的信息来创建NSInvocation对象。因此我们必须重写这个方法，为给定的selector提供一个合适的方法签名。
完整的示例如下所示：

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17

- (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:只能用于继承体系，而不能用于转发链。便如果我们想让这种消息转发看起来像是继承，则可以重写这些方法，如以下代码所示：

1 2 3 4 5 6 7 8 9 10 11 12 13

- (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操作等。

四：Method Swizzling

在上周associated objects一文中，我们开始探索Objective-C运行时的一些黑魔法。本周我们继续前行，来讨论可能是最受争议的运行时技术：method swizzling。

Method swizzling指的是改变一个已存在的选择器对应的实现的过程，它依赖于Objectvie-C中方法的调用能够在运行时进改变——通过改变类的调度表（dispatch table）中选择器到最终函数间的映射关系。

举个例子，假设我们想跟踪在一个iOS应用中每个视图控制器展现给用户的次数：

我们可以给每个视图控制器对应的viewWillAppear:实现方法中增加相应的跟踪代码，但是这样做会产生大量重复的代码。子类化可能是另一个选择，但要求你将UIViewController、 UITableViewController、 UINavigationController 以及所有其他视图控制器类都子类化，这也会导致代码重复。

幸好，还有另一个方法，在分类中进行method swizzling，下面来看怎么做：

#import <objc/runtime.h>

@implementation UIViewController (Tracking)

+ (void)load {

static dispatch_once_t onceToken;

dispatch_once(&onceToken, ^{

Class class = [self class];

// When swizzling a class method, use the following:

// Class class = object_getClass((id)self);

SEL originalSelector = @selector(viewWillAppear:);

SEL swizzledSelector = @selector(xxx_viewWillAppear:);

Method originalMethod = class_getInstanceMethod(class, originalSelector);

Method swizzledMethod = class_getInstanceMethod(class, swizzledSelector);

BOOL didAddMethod =

class_addMethod(class,

originalSelector,

method_getImplementation(swizzledMethod),

method_getTypeEncoding(swizzledMethod));

if (didAddMethod) {

class_replaceMethod(class,

swizzledSelector,

method_getImplementation(originalMethod),

method_getTypeEncoding(originalMethod));

} else {

method_exchangeImplementations(originalMethod, swizzledMethod);

}

});

}

#pragma mark - Method Swizzling

- (void)xxx_viewWillAppear:(BOOL)animated {

[self xxx_viewWillAppear:animated];

NSLog(@"viewWillAppear: %@", self);

}

@end

在计算机学科中，指针变换（pointer swizzling）是指将基于名字或位置的引用转变为直接的指针引用。 然而在Objective-C中，这个词的起源并不完全知道，但关于这一借鉴其实也很好理解，method swizzling可以通过选择器来改变它引用的函数指针。

现在，当UIViewController或它子类的任何实例触发viewWillAppear:方法都会打印一条log日志。

向视图控制器的生命周期中注入操作、事件的响应、视图的绘制，或Foundation中的网络堆栈都是能够利用method swizzling产生明显效果的场景。还有一些其他的场景使用swizzling会是一个合适的选择，这随着Objective-C开发者经验不断丰富会变得越来越明显。

先不说为什么和在哪些地方使用swizzling，来看一下应该怎样实现：

+load vs. +initialize

Swizzling应该在+load方法中实现。

每个类的这两个方法会被Objective-C运行时系统自动调用，+load是在一个类最开始加载时调用，+initialize是在应用中第一次调用该类或它的实例的方式之前调用。这两个方法都是可选的，只有实现了才会被执行。

因为method swizzling会影响全局，所以减少冒险情况就很重要。+load能够保证在类初始化的时候就会被加载，这为改变系统行为提供了一些统一性。但+initialize并不能保证在什么时候被调用——事实上也有可能永远也不会被调用，例如应用程序从未直接的给该类发送消息。

dispatch_once

Swizzling应该在dispatch_once中实现。

还是因为swizzling会改变全局，我们需要在运行时采取所有可用的防范措施。保障原子性就是一个措施，它确保代码即使在多线程环境下也只会被执行一次。GCD中的diapatch_once就提供这些保障，它应该被当做swizzling的标准实践。

选择器、方法及实现

在Objective-C中，尽管这些词经常被放在一起来描述消息传递的过程，但选择器、方法及实现分别代表运行时的不同方面。

下面是苹果Objective-C Runtime Reference文档中对它们的描述：

1.选择器（typedef struct objc_selector *SEL）：选择器用于表示一个方法在运行时的名字，一个方法的选择器是一个注册到（或映射到）Objective-C运行时中的C字符串，它是由编译器生成并在类加载的时候被运行时系统自动映射。

2.方法（typedef struct objc_method *Method）：一个代表类定义中一个方法的不明类型。

3.实现（typedef id (*IMP)(id, SEL, ...)）：这种数据类型是实现某个方法的函数开始位置的指针，函数使用的是基于当前CPU架构的标准C调用规约。第一个参数是指向self的指针（也就是该类的某个实例的内存空间，或者对于类方法来说，是指向元类（metaclass）的指针）。第二个参数是方法的选择器，后面跟的都是参数。

理解这些概念之间关系最好的方式是：一个类（Class）维护一张调度表（dispatch table）用于解析运行时发送的消息；调度表中的每个实体（entry）都是一个方法（Method），其中key值是一个唯一的名字——选择器（SEL），它对应到一个实现（IMP）——实际上就是指向标准C函数的指针。

Method Swizzling就是改变类的调度表让消息解析时从一个选择器对应到另外一个的实现，同时将原始的方法实现混淆到一个新的选择器。

调用_cmd

下面这段代码看起来像是会导致一个死循环：

- (void)xxx_viewWillAppear:(BOOL)animated {

[self xxx_viewWillAppear:animated];

NSLog(@"viewWillAppear: %@", NSStringFromClass([self class]));

}

但其实并没有，在Swizzling的过程中，xxx_viewWillAppear:会被重新分配给UIViewController的-viewWillAppear:的原始实现。一个优秀程序员应有的直觉会告诉你在一个方法的实现中通过self调用当前方法自身会产生错误，但是在当前这种情况下，如果我们记住到底是怎么回事更有意义。反而，如果我们在这个方法中调用viewWillAppear:才会真的导致死循环，因为这个方法的实现会在运行时被swizzle到viewWillAppear:的选择器。

记住给swizzled方法加上前缀，这和你需要给可能产生冲突的分类方法加前缀是一个道理。

注意事项

Swizzling被普遍认为是一种巫术，容易导致不可预料的行为和结果。尽管不是最安全的，但是如果你采取下面这些措施，method swizzling还是很安全的。

1.始终调用方法的原始实现（除非你有足够的理由不这么做）： API为输入和输出提供规约，但它里面具体的实现其实是个黑匣子，在Method Swizzling过程中不调用它原始的实现可能会破坏一些私有状态，甚至是程序的其他部分。

2.避免冲突：给分类方法加前缀，一定要确保不要让你代码库中其他代码（或是依赖库）在做与你相同的事。

3.理解：只是简单的复制粘贴swizzling代码而不去理解它是怎么运行的，这不仅非常危险，而且还浪费了学习Objective-C运行时的机会。阅读 Objective-C
Runtime Reference 和 <objc/rumtime.h> 去理解代码是怎样和为什么这样执行的，努力的用你的理解来消灭你的疑惑。

谨慎行事：不管你多么自信你能够swizzling Foundation、UIKit 或者其他内置框架，请记住所有这些都可能在下一个版本中就不好使。提前做好准备，防范于未然才不至于到时候焦头烂额。

不敢放心大胆的直接使用Objective-C运行时？Jonathan ‘Wolf’ Rentzsch提供了经过实战检验的、支持CocoaPads的库JRSwizzle，它会为你考虑好了一切。

与associated objects一样，method swizzling是一个强大的技术，但是你也应该谨慎使用。

五：协议与分类

Objective-C中的分类允许我们通过给一个类添加方法来扩充它（但是通过category不能添加新的实例变量），并且我们不需要访问类中的代码就可以做到。

Objective-C中的协议是普遍存在的接口定义方式，即在一个类中通过@protocol定义接口，在另外类中实现接口，这种接口定义方式也成为“delegation”模式，@protocol声明了可以呗其他任何方法类实现的方法，协议仅仅是定义一个接口，而由其他的类去负责实现。

在本章中，我们来看看runtime对分类与协议的支持。

基础数据类型

Category

Category是表示一个指向分类的结构体的指针，其定义如下：

1 2 3 4 5 6 7 8 9

typedef struct objc_category *Category; struct objc_category { char *category_nameOBJC2_UNAVAILABLE; // 分类名 char *class_name OBJC2_UNAVAILABLE; // 分类所属的类名 struct objc_method_list *instance_methodsOBJC2_UNAVAILABLE; // 实例方法列表 struct objc_method_list *class_methods OBJC2_UNAVAILABLE; // 类方法列表 struct objc_protocol_list *protocols OBJC2_UNAVAILABLE; // 分类所实现的协议列表 }

这个结构体主要包含了分类定义的实例方法与类方法，其中instance_methods列表是objc_class中方法列表的一个子集，而class_methods列表是元类方法列表的一个子集。

Protocol

Protocol的定义如下：

1	typedef struct objc_object Protocol;

我们可以看到，Protocol其中实就是一个对象结构体。

操作函数

Runtime并没有在<objc/runtime.h>头文件中提供针对分类的操作函数。因为这些分类中的信息都包含在objc_class中，我们可以通过针对objc_class的操作函数来获取分类的信息。如下例所示：

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41

@interface RuntimeCategoryClass : NSObject - (void)method1; @end @interface RuntimeCategoryClass (Category) - (void)method2; @end @implementation RuntimeCategoryClass - (void)method1 { } @end @implementation RuntimeCategoryClass (Category) - (void)method2 { } @end #pragma mark - NSLog(@ "测试objc_class中的方法列表是否包含分类中的方法" ); unsigned int outCount = 0; Method *methodList = class_copyMethodList(RuntimeCategoryClass.class, &outCount); for (int i = 0; i < outCount; i++) { Method method = methodList[i]; const char *name = sel_getName(method_getName(method)); NSLog(@ "RuntimeCategoryClass's method: %s" , name); if (strcmp(name, sel_getName(@selector(method2)))) { NSLog(@ "分类方法method2在objc_class的方法列表中" ); } }

其输出是：

1 2 3 4

2014-11-08 10:36:39.213 [561:151847] 测试objc_class中的方法列表是否包含分类中的方法 2014-11-08 10:36:39.215 [561:151847] RuntimeCategoryClass's method: method2 2014-11-08 10:36:39.215 [561:151847] RuntimeCategoryClass's method: method1 2014-11-08 10:36:39.215 [561:151847] 分类方法method2在objc_class的方法列表中

而对于Protocol，runtime提供了一系列函数来对其进行操作，这些函数包括：

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44

// 返回指定的协议 Protocol * objc_getProtocol ( const char *name ); // 获取运行时所知道的所有协议的数组 Protocol ** objc_copyProtocolList ( unsigned int *outCount ); // 创建新的协议实例 Protocol * objc_allocateProtocol ( const char *name ); // 在运行时中注册新创建的协议 void objc_registerProtocol ( Protocol *proto ); // 为协议添加方法 void protocol_addMethodDescription ( Protocol *proto, SEL name, const char *types, BOOL isRequiredMethod, BOOL isInstanceMethod ); // 添加一个已注册的协议到协议中 void protocol_addProtocol ( Protocol *proto, Protocol *addition ); // 为协议添加属性 void protocol_addProperty ( Protocol *proto, const char *name, const objc_property_attribute_t *attributes, unsigned int attributeCount, BOOL isRequiredProperty, BOOL isInstanceProperty ); // 返回协议名 const char * protocol_getName ( Protocol *p ); // 测试两个协议是否相等 BOOL protocol_isEqual ( Protocol *proto, Protocol *other ); // 获取协议中指定条件的方法的方法描述数组 struct objc_method_description * protocol_copyMethodDescriptionList ( Protocol *p, BOOL isRequiredMethod, BOOL isInstanceMethod, unsigned int *outCount ); // 获取协议中指定方法的方法描述 struct objc_method_description protocol_getMethodDescription ( Protocol *p, SEL aSel, BOOL isRequiredMethod, BOOL isInstanceMethod ); // 获取协议中的属性列表 objc_property_t * protocol_copyPropertyList ( Protocol *proto, unsigned int *outCount ); // 获取协议的指定属性 objc_property_t protocol_getProperty ( Protocol *proto, const char *name, BOOL isRequiredProperty, BOOL isInstanceProperty ); // 获取协议采用的协议 Protocol ** protocol_copyProtocolList ( Protocol *proto, unsigned int *outCount ); // 查看协议是否采用了另一个协议 BOOL protocol_conformsToProtocol ( Protocol *proto, Protocol *other );

objc_getProtocol函数，需要注意的是如果仅仅是声明了一个协议，而未在任何类中实现这个协议，则该函数返回的是nil。

● objc_copyProtocolList函数，获取到的数组需要使用free来释放

● objc_allocateProtocol函数，如果同名的协议已经存在，则返回nil

● objc_registerProtocol函数，创建一个新的协议后，必须调用该函数以在运行时中注册新的协议。协议注册后便可以使用，但不能再做修改，即注册完后不能再向协议添加方法或协议

需要强调的是，协议一旦注册后就不可再修改，即无法再通过调用protocol_addMethodDescription、protocol_addProtocol和protocol_addProperty往协议中添加方法等。

小结

Runtime并没有提供过多的函数来处理分类。对于协议，我们可以动态地创建协议，并向其添加方法、属性及继承的协议，并在运行时动态地获取这些信息。