您的位置:首页 > 移动开发 > Swift

RxSwift Runtime分析(利用OC消息转发实现IOS消息拦截)<原理同ReactiveCocoa>

2016-07-18 09:37 573 查看
简要介绍:这是一篇介绍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格式的文件,地址
https://github.com/ShakeShakeMe/TempStaff/blob/master/RxSwift/RX_Runtime.png
b) 针对宏,有必要给出两个展开的过程例子,那就选“理论部分中提到的两个关键宏”,其他的宏都是类似展开(展开过程就不详细写了,因为写起来,排版很难看,展开过程也很繁琐,有兴趣的可以私聊),下面只给出几个宏展开之后的结果:

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



SWIZZLE_OBSERVE_METHOD(void,id)宏(两次截屏):





备注:这里说的RXSwift其实严格来说是RXSwift中的RxCocoa子框架
内容来自用户分享和网络整理,不保证内容的准确性,如有侵权内容,可联系管理员处理 点击这里给我发消息
标签: