RxSwift Runtime分析(利用OC消息转发实现IOS消

简要介绍：这是一篇介绍IOS消息拦截的文章，来源于对RxSwift源码的分析，其原理是利用Object-c的消息转发(forwardInvocation:)来实现(ReactiveCocoa中也是这个原理，而且是RXSwift借鉴的RAC和MAZeroingWeakRef)，阅读本文章需要对OC的runtime有一定的了解，并且对函数式响应编程(FRP)框架RAC或者RxSwift有一定的了解，不然会很迷惑的。

特别说明：如果想深入到代码层次来理解这个机制，可以参照着RxSwift框架中RxCocoa模块代码的_RXObjCRuntime.h和_RXObjCRuntime.m文件来理解，使用端的代码可以参考RxCocoa中的NSObject+Rx.swift文件的publicfuncrx_sentMessage(selector:Selector) ->Observable<[AnyObject]>方法（以及publicvarrx_deallocating:Observable<()>），并配合着文中提供的那张大图来仔细研读。

本文结构：文章总共包括两个部分：1）理论部分；2）源码剖析部分。这两个部分都会配置上一些图，帮助大家理解，最后会把用OmniGraffle绘制的图上传上来。

1. 理论部分：

至于什么是函数式相应编程(FRP)以及有什么好处此处不做介绍，ReactiveCocoa和RxSwift(结合MVVM)的基本用法也不做介绍，下面只结合RXSwift源码对这俩框架中的其中一个技术做剖析，也就是本文的主题，如何利用Object-c的消息转发(forwardInvocation:)机制来实现IOS的消息拦截机制！

a) 首先介绍下最终实现的效果，就是可以为任何OC类(排除CF类和已经实现类似KVO机制的类)的方法添加一个切面(AOP)，这个切面可以获取到原方法的参数列表，加上自己的逻辑，这时就可以做到OC在执行某一个方法的时候，加上自己的逻辑，这一点很想Java中spring的AOP，不过没那么强大，在RXSwift中主要利用这个工作来给使用者提供一个钩子(hook)，并结合RXSwift中信号流的概念，在方法被调用时，以数据流的方式发送出来。

b) 在继续下面之前，有必要先简要说说apple实现KVO的原理(先推荐大家看一下Mike Ash的一篇KVO的文章，还有Mike Ash的一篇NSNotificationCenter的文章，也可以看看NSNotificationCenter 与 KVO 的实现比较的一篇文章)，我简要描述下，KVO的实现，是借助了OC的动态性语言的特点，利用runtime在程序运行时动态的为ClassA添加一个子类，暂且叫_KVO_ClassA,把ClassA设置为其父类，重写要监听的属性pro的setPro方法，在重写的这个方法中，赋值前后发出相应的通知，并且把用户当前要监听的对象的isa指针设置为_KVO_ClassA，这样，当使用者调用a.pro=xxx的时候，就会顺着isa指针找到_KVO_ClassA类的被重写的setPro方法，这样就做到了KVO的特性(KVO中还重写了class函数，使得当使用者调用[a class]时返回的还是ClassA，而不是a的isa指针指向的_KVO_ClassA，这里有点欺骗了使用者)。

c）这里的原理跟这个有一点相似的地方，就是也是通过给当前类ClassB(假设有有一个方法叫selector)添加一个子类_RX_namespace_ClassB（_RX_namespace_是命名前缀）,这个类继承ClassB，并且添加一个_RX_namespace_selector方法，并且把_RX_namespace_selector的实现设置为原selector的实现，然后再把原selector的实现设置为_objc_msgForward,_objc_msgForward是runtime的消息转发环节的入口，这样当使用者调用[a selector]是，就进入了OC runtime的消息转发环节；

d) 这里还有一个地方就是，会为每一个rx临时类(暂且把_RX_namespace_ClassB这一群类叫做rx临时类，把_RX_namespace_selector一类的方法叫做rx临时方法)新增或者替换forwardInvocation:的实现（其实还有另外三个，不过这个最重要，其他三个是respondsToSelector:, class, methodSignatureForSelector: ;其中class就是类似KVO的那种欺骗使用者的效果），在forwardInvocation:的新实现中，调用static BOOL RX_forward_invocation(id self, NSInvocation *invocation)方法；

e) 在进入整个环节之前（也就是开启监听方法的入口），还有一个步骤，就是给原类实例对象添加一个关联属性，这个关联属性的key就是_RX_namespace_selector，属性值value是名为MessageSentObservable实例对象的钩子，这样在d步骤中RX_forward_invocation的实现中以key为_RX_namespace_selector获取这个钩子，获取到钩子之后，调用钩子的-(void)messageSentWithParameters:(NSArray*)parameters方法，把原方法的参数以数组的方式传递出去，最后在把invocation的方法SEL设置为_RX_namespace_selector，调用[invocation invokeWithTarget:self]，还记得d中的方法实现替换的步骤吗？那一步，把_RX_namespace_selector的实现设置为原方法的实现，这样，就实现了不破坏现场的特性了；至此通用情形下得原理就结束了。

f) 因为OC的消息转发环节，不是直接调用方法的实现，而是绕了一个圈子，所以效率上肯定是有折扣的，所以RXSwift中间又加了一层优化机制，下面简述下优化机制过程原理：

g) 再讲述优化机制前，有必要简要说下RXSwift中强大的宏的运用（这里宏的运用是为了生成函数或者category，从而减少代码的量），这里到处使用到了宏，大部分都是利用宏来动态生成代码，比如说生成函数，生成category等等；比如说d中提到的“新增或者替换forwardInvocation:”的方法-(BOOL)swizzleForwardInvocation:(Class __nonnull)class error:(NSError **__nonnull)error就是下面这个宏生成的：

（这个宏生成的category会生成一个方法-(BOOL)swizzle_void_id:(Class __nonnull)class selector:(SEL)selector error:(NSError ** __nonnull)error）

下面优化环节要用到的category也都是宏生成的，文章后面的图中，会给出例子；在每一个category中，都有load方法，load方法又都是在类被加载时就执行，举例子来说吧，宏SWIZZLE_OBSERVE_METHOD(void, id)针对的是为返回值为void，有一个参数为id类型的方法签名的一类生成个RXInterceptWithOptimizedObserver，在load方法中，将这个observer根据方法的签名为key添加到optimizedObserversByMethodEncoding中（这俩东西h点会讲解到）；

h) RxSwift中存在一个全局静态变量optimizedObserversByMethodEncoding，这个变量就是存储RXInterceptWithOptimizedObserver列表，而RXInterceptWithOptimizedObserver的定义是typedef BOOL (^RXInterceptWithOptimizedObserver)(RXObjCRuntime * __nonnull self, Class __nonnull class, SEL __nonnull selector, NSError ** __nonnull error);，当需要监听某一个方法的执行时，首先会根据这个方法的方法签名，到optimizedObserversByMethodEncoding中查找，找不到就进入c,d,e三个对应的通用消息转发环节中，找到了，就执行g中宏生成的swizzle_void_id方法，这个方法中是将原方法新增或者替换一个block生成的方法实现，这个block中，首先根据_RX_namespace_selector来找RXMessageSentObserver钩子对象，获取到钩子之后，调用钩子的-(void)messageSentWithParameters:(NSArray*)parameters方法，再调用msgSend(&superInfo, selector, id_0)或者originalImplementationTyped(self, selector, id_0)来保持现场完整性，这样就把selector给拦截了，别切不破坏现场，而且也没有用到OC的消息转发，只有第一次使用时需要方法实现的替换，后续的效率肯定高。

i) 当需要监听一个对象的dealloc方法的调用时，RXSwift中还针对dealloc方法做了特殊化处理，这个过程跟“优化环节”很像，在此不再表述，文章后面的图中有说明。

2. 源码剖析部分：

a) 上面一大堆的原理过程，看着难免有些枯燥，下面给出一张大图（小弟文档工地太差，画图很不规范，大家就凑合着看吧，意思应该还是表达清楚了），这个图中有对源码中关键部分，比如说宏，关键方法等做解读(这个图片太大，下载下来时出现模糊的情况，我另外在github上存了一份，可以去那儿下载高清版，以及OMniGraffe格式的文件，地址，另外，手机简书APP打开的图片是高清的，保存下来放在电脑上，效果不错)

b) 针对宏，有必要给出两个展开的过程例子，那就选“理论部分中提到的两个关键宏”，其他的宏都是类似展开(展开过程就不详细写了，因为写起来，排版很难看，展开过程也很繁琐，有兴趣的可以私聊)，下面只给出几个宏展开之后的结果：

替换转发方法forwardInvocation:的实现的宏：

SWIZZLE_OBSERVE_METHOD(void,id)宏（两次截屏）：

备注：这里说的RXSwift其实严格来说是RXSwift中的RxCocoa子框架；

关于RxSwift中把Delegate代理、KVO，Notification转化为流的原理后续文章会给出，这些相对于本文章中原理稍简单些。