在日常开发中我经常会调用responseToSelector这个方法，尤其是是在我们写的协议的类中我们经常会有这样的判断。最近重新看《编写高质量iOS于OS X代码的52个有效方法》这本书的时候作者提供了不一样的思路，作者认为可以在对象初始化的时候去判断，然后用枚举的方式进行判断，来防止每次查找的过程，提高开发效率，我当时思考的问题是，应该是第一次调用方法之后就存储在了类的方法缓存列表中，之后每次调用responseToSelector()方法都会优先在缓存列表中查找么。当时认为每次查找的算法复杂度O(1)的，对于程序的优化没有必要，而且如果代理方法很多的情况下，对象初始化也会增加程序的负荷，因为这个时候会把所有的方法加入到缓存列表，这样的方案本身意义不大。然后我就去看runtime的源码验证我的想法，现在我们一起来看一下我们是不是有必要做这一块的优化。
1.responseToSelector（） vs 作者的方案
日常使用方案
日常protocol的使用方式
作者的方案用OC的方案写出来是下边的样子
对比两种方法我们很容易明白作者的意图是在程序每次创建的时候就先去我们的代理类中去读取当前代理类有没有实现当前的代理方法，然后创建一个状态枚举动态的存储类的返回结果，每次判断方法可否执行前只要进行一次简单的位运算即可。这时我发现即使responseToObject（）方法即便是O（1）操作，在时间级的优化上作者的方案显然也是更好的。但是作者的方案同样有一些需要注意的问题。
1）假如说你的程序在收到一些服务器的返回结果之后用runtime添加代理方法，而这个时候我们已经创建了代理，那么这个时候是无法执行代理方法的。所以这时还要再有动态的改变枚举状态的新的接口，此时程序的复杂性就会上升。这个时候我觉得还是使用responseToSelect（）方法更好一些。而且很少有程序会遇到这样的情况，所以这一点只有遇到这种情况的时候注意即可。
2）在我们的程序中，可能会有多个对象成为一个协议的代理，我们不可能每次在协议创建的时候，再去专门的写一个类来记录状态那样程序的耦合性无疑有上升了，而且也没有意义，所以这个时候，我们每一个协议都要跟随一个类来做绑定，用于记录代理对象是不是可以执行某个协议方法，即便是协议的继承，一样要创建多个相应的绑定类。这样虽然稍有麻烦，但是我觉得这一部分还是合理的。
3）如果代理方法很多的情况下，在初始化阶段无疑就增加了对应的绑定的类的负荷，因为需要在初始化的时候去方法列表中读取所有的方法，在存储到方法缓存列表中去还是需要一些耗时的，所以这时其实需要做时间上的衡量之后进行选择的。如果协议多次调用，方法少，那么作者的方案更好。如果协议的每个方法调用次数不多，且协议的方法还很多的情况下，我认为responseToSelect（）方法应该更好一些。
4）想到上边的3个问题之后，我就思考是不是有更好的处理方案呢，将绑定的类的负荷拆分到每一次方法的调用阶段，即便出现方法一的情况，也不需要在协议的绑定类中添加状态改变的操作。也不用再去考虑调用次数和方法数量之间的抉择。我认为我们可以将绑定关系的类进行一下修改即可。绑定类中的代码修改如下。
优化后的方案
经过上边的优化后我们在第一次调用的时候会相应responseToSelector()方法之后，如果响应到了之后都是根据枚举状态去相应。也没有了绑定类一开始加载很多方法时会产生的高负荷，这样的代码看起来很好，但是对于那些占内存很大的程序，我觉得为了保护宝贵的内存，不去一次次创建这个虽然很小的绑定类。还是使用的系统的方案。因为我认为系统的方案本身也是很好的（下文会有介绍），当然这样的方法对于程序的性能还是有优化的。与本文相关的demo下载地址。
当然看了我的思路之后，有更好的解决方案，烦请您给我留言，我会在本文中进行补充，大家一起成长~
说完了上边的优化，我们回头再来看一下responseToSelector（）到底在底层做了什么，它的运行效率到底是怎么样的呢？
2）responseToSelector（）的执行效率怎么样？
这个时候我做的第一件事情就是去查看相关的源码，起初先到objc-class.mm文件中去调用下边的两个方法。 如果sel传入空的或者类被释放的话，其实直接就返回了NO.
通过一系列的查询之后，会发现程序被定位到了下边的代码处，这个方法在objc-runtime-new.mm文件中可以找到
查看了上边的代码的源代码，我知道程序之后的调用方式其实就是先从缓存池中进行查找，没有的情况下会从方法列表中取等一系列的操作。这篇文章可以看到lookupImporForward的实现的一些大体上的代码，有比较详细的注释。这时我发现其实从缓存中读取主要就是调用了 _cache_getImp(cls, sel) 这个方法，但是我从源码中没有找到这个方法，后来在网上查到了美团技术团队对于这一块的解释，才知道这一部分的实现使用汇编语言。但是读取美团的原文加上我从国外网站上看到的文章，我才知道原来在方法列表的缓存列表中读取到已执行过的方法在算法的复杂度上并不是O（1）的。但是那一块的执行都是汇编实现，所以执行效率还是比较快的，所以系统对于这一块的执行速度还是很有保证的，但是速度上肯定比不上一次位运算。
所以在具体的场景下，我们追求极致的用户体验的时候，这样的方式真的值得我们思考和引用。
如果文章中有任何问题，希望您不吝指出，我一定会及时进行修复。
网友评论