OC是个动态运行语言，何为动态语言，个人理解为在运行时才会去检查类的类型，当然，xcode其实会帮你避免不正确的类去调用方法，但是当类型是id的时候，你会发现他可以随便调用方法。。。额，说过头了!
说个大家常常遇到的错误吧，就是 嗯：无效的方法发送到了实例，额，你说你没见过，好吧，这是中文版的，英文的是unrecognized selector sent to instance！
这个就是最直接的反应了一个问题，在编译的时候他就根本不会去检查你的对象是否是这个类，但是到运行的时候会做，于是，你给一把刀配了把剑鞘，结果你懂得！
来个简单的代码，[me eat],在运行时中应该会被翻译成这样吧objc_msgSend(me, eat)
引用一段话：
消息只有到运行时才会和函数实现绑定起来，而不是按照编译好的逻辑一成不变的执行。按照我的理解，编译阶段只是确定了要去向receiver对象发送message消息，但是却没有发送，真正发送是等到运行的时候进行。因此，编译阶段完全不知道message方法的具体实现，甚至，该方法到底有没有被实现也不知道。这就有可能导致运行时崩溃问题。
关于runtime:
完全基于c，Objective-C运行时系统有两个已知版本:早期版本（Legacy）和现行版本（Modern），
在现行版本中,最显著的新特性就是实例变量是"健壮“(non-fragile)的:
在早期版本中,如果您改变类中实例变量的布局,您必须重新编译该类的所有子类。
在现行版本中,如果您改变类中实例变量的布局,您无需重新编译该类的任何子类。
此外,现行版本支持声明property的synthesis属性器。
目前iPhone 程序和 Mac OS X v10.5 及以后的系统中的 64 位程序使用的都是 Objective-C 运行时系统的现行版 本。其它情况(Mac OS X 系统中的 32 位程序)使用的是早期版本。
---------------------------------------
和runtime system交互的三种方式
1、通过Objective-C源代码
2、通过类NSObject的方法
3、通过运行时系统的函数
运行时系统是一个有公开接口的动态库,由一些数据结构和函数的集合组成,这些数据结构和函数的声明 头文件在/usr/include/objc中。这些函数支持用纯C的函数来实现和Objective-C同样的功能。还有一些函数构成了 NSObject 类方法的基础。
---------------------------------------
说到这里就要说明一下几个问题：
1、什么是消息
①message（消息）
message的具体定义很难说，因为并没有真正的代码描述，简单的讲message 是一种抽象，包括了函数名+参数列表，他并没有实际的实体存在。
②method（方法）
method是真正的存在的代码。如：- (int)eat { return 1; }
③selector（方法选择器）
selector 通过SEL类型存在，描述一个特定的method 或者说 message。在实际编程中，可以通过selector进行检索方法等操作。
2、两个跟消息相关的概念
①SEL
SEL又叫方法选择器，这到底是个什么玩意呢？在objc.h中是这样定义的：
typedef struct objc_selector *SEL;
这个SEL表示什么？首先，说白了，方法选择器仅仅是一个char *指针，仅仅表示它所代表的方法名字罢了，有如下证据：
- SEL selector = @selector(message); //@selector不是函数调用，只是给这个坑爹的编译器的一个提示
- NSLog (@"%s", (char *)selector); //print message
Objective-C在编译的时候，会根据方法的名字，生成一个用 来区分这个方法的唯一的一个ID，这个ID就是SEL类型的。我们需要注意的是，只要方法的名字相同，那么它们的ID都是相同的。就是说，不管是超类还是子类，不管是有没有超类和子类的关系，只要名字相同那么ID就是一样的。
而这也就导致了Objective-C在处理有相同函数名和参数个数但参数类型不同的函数的能力非常的弱，比如当你想在程序中实现下面两个方法：
- -(void)setWidth:(int)width；
- -(void)setWidth:(double)width；
这样的函数则被认为是一种编译错误，而这最终导致了一个非常非常奇怪的Objective-C特色的函数命名：
- -(void)setWidthIntValue:(int)width；
- -(void)setWidthDoubleValue:(double)width；
刚才我们说道，编译器会根据每个方法的方法名为那个方法生成唯一的SEL，这些SEL组成了一个Set集合，这个Set简单的说就是一个经过了优化过的hash表。而Set的特点就是唯一，也就是SEL是唯一的，因此，如果我们想到这个方法集合中查找某个方法时，只需要去找到这个方法对应的SEL就行了，SEL实际上就是根据方法名hash化了的一个字符串，而对于字符串的比较仅仅需要比较他们的地址就可以了，犀利，速度上无语伦比！！但是，有一个问题，就是数量增多会增大hash冲突而导致的性能下降（或是没有冲突，因为也可能用的是perfect hash）。但是不管使用什么样的方法加速，如果能够将总量减少（多个方法可能对应同一个SEL），那将是最犀利的方法。那么，我们就不难理解，为什么SEL仅仅是函数名了。
到这里，我们明白了，本质上，SEL只是一个指向方法的指针（准确的说，只是一个根据方法名hash化了的KEY值，能唯一代表一个方法），它的存在只是为了加快方法的查询速度！！！！
说道这里大概你也能明白SEL是个什么东东了，那好，继续下一个
②IMP
IMP在objc.h中是如此定义的：
typedef id (*IMP)(id, SEL, ...);
这个比SEL要好理解多了，熟悉C语言的同学都知道，这其实是一个函数指针。
前面介绍过的SEL，就是为IMP服务的。由于每个方法都对应唯一的SEL，（如objc_msgSend(me, eat)）因此我们可以通过SEL方便、快速、准确的获得它所对应的IMP（也就是函数指针），而在取得了函数指针之后，也就意味着我们取得了执行的时候的这段方法的代码的入口，这样我们就可以像普通的C语言函数调用一样使用这个函数指针。当然我们可以把函数指针作为参数传递到其他的方法，或者实例变量里面，从而获得极大的动态性。
下面的例子，介绍了取得函数指针，即函数指针的用法：
- void (* performMessage)(id,SEL);//定义一个IMP（函数指针）
- performMessage = (void (*)(id,SEL))[self performSelector:@selector(message)];//通过performSelector方法根据SEL获取对应的函数指针
- performMessage(self,@selector(message));//通过取到的IMP（函数指针）跳过runtime消息传递机制，直接执行message方法
用IMP 的方式，省去了runtime消息传递过程中所做的一系列动作，比直接向对象发送消息高效一些。
3、传递消息所用的几个runtime方法
- objc_msgSend_stret（返回值是结构体）
- objc_msgSend_fpret（返回值是浮点型）
- objc_msgSendSuper（调用父类方法）
- objc_msgSendSuper_stret（调用父类方法，返回值是结构体）
它们的作用都是类似的，为了简单起见，后续介绍消息和消息传递机制都以objc_msgSend方法为例。
-------------------------
二、消息调用流程
一切还是从消息表达式[receiver message]开始，
在被转换成objc_msgSend(receiver, SEL)后，在运行时，runtime system会做以下事情：
1、检查忽略的Selector，比如当我们运行在有垃圾回收机制的环境中，将会忽略retain和release消息。
2、检查receiver是否为nil。不像其他语言，nil在objective-C中是完全合法的，并且这里有很多原因你也愿意这样，比如，至少我们省去了给一个对象发送消息前检查对象是否为空的操作。如果receiver为空，则会将 selector也设置为空，并且直接返回到消息调用的地方。如果对象非空，就继续下一步。（这里为空确实比较方便）
3、接下来会根据SEL到当前类中查找对应的IMP，首先会在cache中检索它，如果找到了就根据函数指针跳转到这个函数执行，否则进行下一步。（引入了一个cache，提升速度，牺牲空间）
4、检索当前类对象中的方法表（method list），如果找到了，加入cache中，并且就跳转到这个函数之行，否则进行下一步。（这个概念以前木有接触过，一直以为就放在一个hash表里面。。。。）
5、从父类中寻找,直到根类：NSObject类。找到了就将方法加入对应类的cache表中，如果仍为找到，则要进入后文介绍的内容：动态方法决议。（觉得，这个才是个比较关键的东西）
6、如果动态方法决议仍不能解决问题，只能进行最后一次尝试，进入消息转发流程。（后续的操作）
7、如果还不行，去死吧。（系统无奈了，我找了半天都木有找到，那你就不存在，嗯，不存在的玩意我咋执行，我干不了你非让干，好吧，我自杀了，结果就是崩溃）
写到这大家肯定会发出这样的疑问：我仅仅想调用一个方法而已，却不得不经历那么多步骤（确实，我只是想执行一个方法啊，要不要那么麻烦，跑过来跑过去的，累不累啊），效率上怎么保证？？苹果也做了一些优化上的工作。
三、函数检索优化措施
主要从下面两个方面着手：
1、通过SEL进行IMP匹配
先来看看类对象中保存的方法列表和方法的数据结构：
typedef struct method_list_t { uint32_t entsize_NEVER_USE; uint32_t count; struct method_t first; } method_list_t; typedef struct method_t { SEL name; const char *types;//参数类型和返回值类型 IMP imp; } method_t;
2、cache缓存
cache的原则就是缓存那些可能要执行的函数地址，那么下次调用的时候，速度就可以快速很多。这个和CPU的各种缓存原理相通。好吧，说了这么多了，再来认识几个名词：
struct objc_cache { uintptr_t mask; uintptr_t occupied; cache_entry *buckets[1]; }; typedef struct { SEL name; void *unused; IMP imp; } cache_entry;
看这个结构，有没有搞错又是hash table。
objc_msgSend 首先在cache list 中找SEL，没有找到就在class method中找，super class method中找（当然super class 也有cache list）。而cache的机制则非常复杂了，由于Objective-C是动态语言。所以，这里面还有很多的多线程同步问题，而这些锁又是效率的大敌，相关的内容已经远远超过本文讨论的范围。（苹果里面的实现机制，你只能去猜，当然就像女人的心思一样，你猜啊猜啊猜不透，但也有可能不小心明白了）
如果在缓存中已经有了需要的方法选标,则消息仅仅比函数调用慢一点点。如果程序运行了足够长的时间,几乎每个消息都能在缓存中找到方法实现。程序运行时,缓存也将随着新的消息的增加而增加。据牛人说（没有亲测过），苹果通过这些优化，使消息传递和直接的函数调用效率上的差距已经相当的小。（这种无语的干法，不过牺牲空间来换效率觉得还是可行，毕竟现在的硬件配置还是比较强大的）
四、方法调用中的隐藏参数
亲爱的Objective-C程序员们，你们在进行面向对象编程的时候，在实例方法中都是用过self关键字吧，可是你有没有想过，为什么在一个实例方法中，通过self关键字就能取到调用当前方法的对象呢？这就要归功与runtime system消息的隐藏参数了。
（注：在此修正，类方法和实例方法中，都可以访问self和_cmd这两个属性，因为它们都不属于类的实例变量，而是形参！！！！误导大家了，深表歉意！！！！）
当objc_msgSend找到方法对应的实现时,它将直接调用该方法实现,并将消息中所有的参数都传递给方法实现,同时,它还将传递两个隐藏的参数:
1.接收消息的对象（也就是self指向的内容）
2.方法选标（_cmd指向的内容）
这些参数帮助方法实现获得了消息表达式的信息。它们被认为是”隐藏“的是因为它们并没有在定义方法的源代码中声明,而是在代码编译时是插入方法的实现中的。尽管这些参数没有被显示声明,但在源代码中仍然可以引用它们(就象可以引用消息接收者对象的实例变 量一样)。在方法中可以通过 self 来引用消息接收者对象,通过选标_cmd 来引用方法本身。下面的例子很好的说明了这个问题：(有点绕，不过看看代码就能明白)
- (void)message { self.name = @"James";//通过self关键字给当前对象的属性赋值 SEL currentSel = _cmd;//通过_cmd关键字取到当前函数对应的SEL （在这里可以获得当前的message这个方法名） NSLog(@"currentSel is :%s",(char *)currentSel); }
打印结果：
ObjcRunTime[693:403] currentSel is :message
当然，在这两个参数中,self 更有用，更常用一些。实际上,它是在方法实现中访问消息接收者对象的实例变量的途径。
四、动态方法解析
1、+(BOOL) resolveInstanceMethod:(SEL) sel
这是NSObject根类提供的类方法，调用时机为当被调用的方法实现部分没有找到，而消息转发机制启动之前的这个中间时刻。
2、@dynamic关键字
Objective-C2.0 提供了@dynamic关键字。这个关键字有两个作用：
①告诉编译器不要创建实现属性所用的实例变量；
②告诉编译器不要创建该属性的get和setter方法。
@property(nonatomic,retain) NSString *name; @dynamic name; 如果使用了name属性的setter方法，又不想在运行时崩溃，就可以在运行时做点动作： void dynamicMethodIMP(id self, SEL _cmd) { // implementation .... } + (BOOL)resolveInstanceMethod:(SEL)sel { NSLog(@"sel is %@", NSStringFromSelector(sel)); if(sel == @selector(setName:)){ class_addMethod([self class],sel,(IMP)dynamicMethodIMP,"v@:"); return YES; } return [super resolveInstanceMethod:sel]; }
在resolveInstanceMethod的实现中，我们通过class_addMethod方法动态的向当前对象增加了dynamicMethodIMP函数，来代替-(void)setName:(NSString *)name的实现部分，从而达到了动态生成name属性方法的目的。
值得说明的是：
①在上个例子中，我们自己实现了-(void)setName:(NSString *)name方法，则在运行的时候，调用完我们实现的-(void)setName:(NSString *)name方法后，运行时系统仍然会调+(BOOL) resolveInstanceMethod:(SEL) sel方法，只不过这里的sel会变成_doZombieMe，从而我们实现重定向的if分支就进不去了，即我们实现的方法不会被覆盖。
②"v@:"属于Objective-C类型编码的内容，感兴趣的同学可以自己google一下。
五、runtime system消息转发机制
对象是谦恭的，它会接收所有发送过来的消息，哪怕这些消息自己无法响应。问题来了：当对象无法响应这些消息时怎么办？runtime提供了消息转发机制来处理该问题。（消息转发的核心问题吧）
当外部调用的某个方法对象没有实现，而且resolveInstanceMethod方法中也没有做重定向处理时，就会触发- (void)forwardInvocation:(NSInvocation *)anInvocation方法。在该方法中，可以实现对不能处理的消息做的一些默认处理,也可以以其它的某种方式来避免错误被抛出。像forwardInvocation:的名字一样,这个方法通常用来将不能处理的消息转发给其它的对象。通常我们重写该方法的方式如下所示：
-(void)forwardInvocation:(NSInvocation *)invocation { SEL invSEL = invocation.selector; if ([someOtherObject respondsToSelector:invSEL]) [anInvocation invokeWithTarget:someOtherObject]; } else { [self doesNotRecognizeSelector:invSEL]; } }
（这个
NSInvocation在ASI中曾经见过，当时没理解，这里看来明白一些了
）
怎么看着有点像多继承呀？？？你说对了，消息转发提供了多重继承的很多特性。然而,两者有很大的不同:多重继承是将不同的行为封装到单个的对象中,有可能导致庞大的,复杂的对象。而消息转发是将问题分解到更小的对象中,但是又以一种对消息发送对象来说完全透明的方式将这些对象联系起来。总之，Objective-C通过这种方式，一定程度上减小了自己不支持多继承的劣势。
好了，这是参考某人的博客一遍看一边转载的，
原地址：http://blog.csdn.net/wzzvictory/article/details/8629036