他的最新文章
他的热门文章
您举报文章：
举报原因：
原文地址：
原因补充：
(最多只允许输入30个字)iOS开发（110）
SEL : 类成员方法的指针，但不同于C语言中的函数指针，函数指针直接保存了方法的地址，但SEL只是方法编号。
IMP:一个函数指针,保存了方法的地址IMP和SEL关系每一个继承于NSObject的类都能自动获得runtime的支持。在这样的一个类中，有一个isa指针，指向该类定义的数据结构体,这个结构体是由编译器编译时为类（需继承于NSObject）创建的.在这个结构体中有包括了指向其父类类定义的指针以及 Dispatch table. Dispatch table是一张SEL和IMP的对应表。也就是说方法编号SEL最后还是要通过Dispatch table表寻找到对应的IMP，IMP就是一个函数指针，然后执行这个方法Q1:有什么办法可以知道方法编号呢@selector()就是取类方法的编号。SEL methodId=@selector(func1);Q2:编号获取后怎么执行对应方法呢[self performSelector:methodIdwithObject:nil];Q3:有没有办法通过编号获取方法NSString*methodName = NSStringFromSelector(methodId);Q4:IMP怎么获得和使用
IMP methodPoint = [self methodForSelector:methodId];
methodPoint();
Q5:为什么不直接获得函数指针，而要从SEL这个编号走一圈再回到函数指针呢？有了SEL这个中间过程，我们可以对一个编号和什么方法映射做些操作，也就是说我们可以一个SEL指向不同的函数指针，这样就可以完成一个方法名在不同时候执行不同的函数体。另外可以将SEL作为参数传递给不同的类执行。也就是说我们某些业务我们只知道方法名但需要根据不同的情况让不同类执行的时候，SEL可以帮助我们。其他SEL的好处可以在评论中帮忙补充...
作者：壮了个壮
链接：https://www.jianshu.com/p/4a09d5ebdc2c
來源：简书
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。
* 以上用户言论只代表其个人观点，不代表CSDN网站的观点或立场
访问：291247次
积分：6427
积分：6427
排名：第4359名
原创：310篇
转载：24篇
评论：466条
(3)(4)(1)(8)(10)(3)(2)(3)(2)(2)(1)(4)(4)(38)(30)(26)(10)(96)(48)(1)(39)
(window.slotbydup = window.slotbydup || []).push({
id: '4740890',
container: s,
size: '250,250',
display: 'inlay-fix'Objective-C runtime源码学习之IMP寻址（不包括消息转发部分）
这是在看《招聘一个靠谱的iOS》时回答第22题时总结的一篇博客，不过这篇博客中并没有牵涉到底层的代码，而且也留下了几个没有解决的问题，这篇博客将深入runtime继续探索这个问题，并尝试解决上篇博客中未解决的问题，本人第一次源码，如果有分析错误的地方，欢迎大家纠正。
首先大家都知道，在oc中调用方法（或者说发送一个消息是）runtime底层都会翻译成objc_msgSend(id self, SEL op, ...)，苹果为了优化性能，这个方法是用汇编写成的
/********************************************************************
* id objc_msgSend(id self, SEL _cmd,...);
********************************************************************/
ENTRY objc_msgSend
# check whether receiver is nil
LMsgSendNilReceiver
# save registers and load receiver's class for CacheLookup
sp!, {a4,v1}
v1, [a1, #ISA]
# receiver is non-nil: search the cache
CacheLookup a2, v1, LMsgSendCacheMiss
# cache hit (imp in ip) and CacheLookup returns with nonstret (eq) set, restore registers and call
sp!, {a4,v1}
# cache miss: go search the method lists
LMsgSendCacheMiss:
ldmfd sp!, {a4,v1}
b _objc_msgSend_uncached
LMsgSendNilReceiver:
LMsgSendExit:
END_ENTRY objc_msgSend
实话说我没有学过汇编，所以看到这段代码我的内心是崩溃的，更可怕的是针对不同的平台，还有不同汇编代码的实现
虽然不懂汇编，但是苹果的注释很详细，看注释也可以大致明白在干什么，首先检查传入的self是否为空，然后根据selector寻找方法实现IMP，找到则调用并返回，否则抛出异常。由此可以有以下伪代码
id objc_msgSend(id self, SEL _cmd, ...) {
Class class = object_getClass(self);
IMP imp = class_getMethodImplementation(class, _cmd);
return imp ? imp(self, _cmd, ...) : 0;
伪代码中我们看到class_getMethodImplementation(Class cls, SEL sel) 方法用来寻找IMP地址，有趣的是苹果真的提供了这个方法，可以让我们调用，通过selector去寻找方法实现IMP，而这个函数的实现，以及其延伸就是这篇博客所要探讨的重点。
在我前面的文章中也说到IMP寻址总共有两种方法：
IMP class_getMethodImplementation(Class cls, SEL name);
IMP method_getImplementation(Method m);
而在NSObject中提供了几个对class_getMethodImplementation封装的方法
+ (IMP)instanceMethodForSelector:(SEL)sel {
if (!sel) [self doesNotRecognizeSelector:sel];
return class_getMethodImplementation(self, sel);
+ (IMP)methodForSelector:(SEL)sel {
if (!sel) [self doesNotRecognizeSelector:sel];
return object_getMethodImplementation((id)self, sel);
- (IMP)methodForSelector:(SEL)sel {
if (!sel) [self doesNotRecognizeSelector:sel];
return object_getMethodImplementation(self, sel);
但这些方法却并没有在头文件中暴露，所以我并不明白苹果这样做的用意，如果有人知道，希望能够告知，感激不尽！
这里出现的object_getMethodImplementation其实就是对class_getMethodImplementation的封装，苹果的解释是：
Equivalent to: class_getMethodImplementation(object_getClass(obj), name);
下面我们就暂时把目光转向class_getMethodImplementation这个函数，看看它底层到底是如何实现的
IMP class_getMethodImplementation(Class cls, SEL sel)
imp = lookUpImpOrNil(cls, sel, nil,
YES/*initialize*/, YES/*cache*/, YES/*resolver*/);
// Translate forwarding function to C-callable external version
if (!imp) {
return _objc_msgF
首先判断传入的参数是否为空，然后进入lookUpImpOrNil这个方法，实际上这个这个方法是对lookUpImpOrForward的简单封装：
/***********************************************************************
* lookUpImpOrNil.
* Like lookUpImpOrForward, but returns nil instead of _objc_msgForward_impcache
**********************************************************************/
IMP lookUpImpOrNil(Class cls, SEL sel, id inst,
bool initialize, bool cache, bool resolver)
IMP imp = lookUpImpOrForward(cls, sel, inst, initialize, cache, resolver);
if (imp == _objc_msgForward_impcache)
注释写的也很清楚，这个方法不会进行消息的转发，而直接返回nil，这个倒是比较有趣，明明调用lookUpImpOrForward可以直接进行消息转发，可是这里偏不这样做，调用消息转发返回nil的函数，然后判断imp为nil时，自己手动返回_objc_msgForward，进行消息转发，还真是有意思，不过苹果在这里做了注释：Translate forwarding function to C-callable external version，将这个转发函数转换为C语言能够调用的版本。
接下来我们继续深入，看一下lookUpImpOrForward是如何实现的：
IMP lookUpImpOrForward(Class cls, SEL sel, id inst,
bool initialize, bool cache, bool resolver)
Class curC
IMP methodPC =
bool triedResolver = NO;
methodListLock.assertUnlocked();
if (cache) {
methodPC = _cache_getImp(cls, sel);
if (methodPC) return methodPC;
if (cls == _class_getFreedObjectClass())
return (IMP) _freedH
methodListLock.lock();
// Ignore GC selectors
if (ignoreSelector(sel)) {
methodPC = _cache_addIgnoredEntry(cls, sel);
// Try this class's cache.
methodPC = _cache_getImp(cls, sel);
if (methodPC)
// Try this class's method lists.
meth = _class_getMethodNoSuper_nolock(cls, sel);
if (meth) {
log_and_fill_cache(cls, cls, meth, sel);
methodPC = method_getImplementation(meth);
// Try superclass caches and method lists.
curClass =
while ((curClass = curClass-&superclass)) {
// Superclass cache.
meth = _cache_getMethod(curClass, sel, _objc_msgForward_impcache);
if (meth) {
if (meth != (Method)1) {
// Found the method in a superclass. Cache it in this class.
log_and_fill_cache(cls, curClass, meth, sel);
methodPC = method_getImplementation(meth);
// Found a forward:: entry in a superclass.
// Stop searching, but don' call method
// resolver for this class first.
// Superclass method list.
meth = _class_getMethodNoSuper_nolock(curClass, sel);
if (meth) {
log_and_fill_cache(cls, curClass, meth, sel);
methodPC = method_getImplementation(meth);
// No implementation found. Try method resolver once.
if (resolver
!triedResolver) {
methodListLock.unlock();
_class_resolveMethod(cls, sel, inst);
triedResolver = YES;
// No implementation found, and method resolver didn't help.
// Use forwarding.
_cache_addForwardEntry(cls, sel);
methodPC = _objc_msgForward_
methodListLock.unlock();
// paranoia: look for ignored selectors with non-ignored implementations
assert(!(ignoreSelector(sel)
methodPC != (IMP)&_objc_ignored_method));
return methodPC;
我天，好长的一段代码，我删了好多注释，还是很多
首先这里有一个我并不懂的东西methodListLock.assertUnlocked(); 我看到 中对此的解释是
对 debug 模式下的 assert 进行 unlock，runtimeLock 本质上是对 Darwin 提供的线程读写锁 pthread_rwlock_t 的一层封装，提供了一些便捷的方法。
需要注意的是在objc-runtime-new.mm中有一段几乎相同的lookUpImpOrForward的实现，在该实现中，加锁操作是runtimeLock.read(); 所以这篇上述博客使用的代码应该是objc-runtime-new.mm的代码，而我的源码是来自于objc-class-old.mm 虽然名称不同，但我想底层应该是一样的。
很佩服这位博主对底层认识的如此深刻，我们暂时就按照这里写的理解，继续往下看
无锁的缓存查找（Optimistic cache lookup）
在没有锁的状态下进行缓存搜索，性能会比较好
if (cache) {
methodPC = _cache_getImp(cls, sel);
if (methodPC) return methodPC;
首先如果cache传入的是YES，则调用cache_getImp在缓存中搜索，当然这里传入的是YES（而在objc_msgSend方法里在这里进行了优化，objc_msgSend最开始就在缓存中进行了搜索，所以有了一个很有趣的方法_class_lookupMethodAndLoadCache3，这个方法在调用lookUpImpOrForward时传入cache是NO，避免两次搜索缓存），而cache_getImp 是用汇编写的（又是汇编。。。(T＿T)）
STATIC_ENTRY cache_getImp
mov r9, r0
CacheLookup GETIMP
// returns IMP on success
LCacheMiss:
// return nil if cache miss
LGetImpExit:
END_ENTRY cache_getImp
具体的缓存搜索是在宏CacheLookup 中实现的，具体这里就不展开了（也展开不了，我还没看懂(^-^) ）。
if (cls == _class_getFreedObjectClass())
return (IMP) _freedH
检测发送消息的对象是否已经被释放，如果已经释放，则返回_freedHandler 的IMP
static void _freedHandler(id obj, SEL sel)
__objc_error (obj, &message %s sent to freed object=%p&,
sel_getName(sel), (void*)obj);
在该方法中抛出message sent to freed object的错误信息（不过我还从来没有遇到过这样的错误信息）
初始化检查
if (initialize
!cls-&isInitialized()) {
_class_initialize (_class_getNonMetaClass(cls, inst));
这里我不是很理解+initialize方法是做什么的
// +initialize bits are stored on the metaclass only
bool isInitialized() {
return getMeta()-&info & CLS_INITIALIZED;
但是从isInitialized() 的实现来看初始化的信息保存在元类中，由此推测是元类或者是类对象的初始化工作，而我在上文中提到的博客中是这样写的：
如果是第一次用到这个类且 initialize 参数为 YES（initialize && !cls-&isInitialized()），需要进行初始化工作，也就是开辟一个用于读写数据的空间。先对 runtimeLock 写操作加锁，然后调用 cls 的 initialize 方法。如果 sel == initialize 也没关系，虽然 initialize 还会被调用一次，但不会起作用啦，因为 cls-&isInitialized() 已经是 YES 啦。
这里的表述也大致印证了我的猜测，是对类对象或者是元类对象进行初始化的工作，不过我还是有一点不明白：类对象都还没有初始化，那是如何产生这个类的实例对象呢？然而在别人博客中看到：＋load是在runtime之前就被调用的，＋initialize是在runtime才调用
retry语句标号（在该类的父类中查找）
这里对方法列表进行了加锁的操作methodListLock.lock();
The lock is held to make method-lookup + cache-fill atomic with respect to method addition. Otherwise, a category could be added but ignored indefinitely because the cache was re-filled with the old value after the cache flush on behalf of the category.
考虑运行时方法的动态添加，加锁是为了使方法搜索和缓存填充成为原子操作。否则category添加时刷新的缓存可能会因为旧数据的重新填充而被完全忽略掉。
typedef struct {
// same layout as struct old_method
// same layout as struct old_method
//objective-c 2.0以前
struct old_method {
SEL method_
char *method_
IMP method_
typedef struct old_method *M
//objective-c 2.0
struct method_t {
const char *
struct SortBySELAddress :
public std::binary_function
bool operator() (const method_t& lhs,
const method_t& rhs)
{ return lhs.name & rhs. }
typedef struct method_t *M
检查selector是否是垃圾回收方法，如果是则填充缓存_cache_fill(cls, (Method)entryp, sel);（这里entryp的类型是结构体cache_entry，将其强转为Method，我们可以看到上面的代码，OC2.0前，这个cache_entry和method的定义几乎是相同的，2.0后加入了一个我完全看不懂的东西(T_T)）并让methodPC指向该方法的实现即entryp-&imp（实际上这是一个汇序的入口_objc_ignored_method），然后跳转到done语句标号。否则进行下一步 在本类的缓存中查找，也是使用汇编程序入口_cache_getImp，如果找到，跳转到done语句标号，否则进行下一步。 在上一步缓存中没有发现，然后进入本类的方法列表中查找，如果找到了则进行缓存填充，并让methodPC指向该方法的实现，跳转到done语句标号，否则进行下一步。 在父类的方法列表和缓存中递归查找，首先是查找缓存，又是调用一个汇编的程序入口_cache_getMethod 比较奇怪的是我只在objc-msg-i386.s中发现了这个程序入口，与前面不同的是，这里传入了一个_objc_msgForward_impcache 的汇编程序入口作为缓存中消息转发的标记，如果发现缓存的方法，则使method_PC指向其实现，跳转到done语句标号，如果找到了Method，但发现其IMP是一个转发的汇编程序入口即_objc_msgForward_impcache ，立即跳出循环，但是不立刻缓存，而是call method resolver，即进行第5步。如果缓存中没发现Method，就在列表中寻找，同样是找到即跳转到done，否则进行下一步。 当传入的resolver为YES且triedResolver为NO时（即此步骤只会进入一次，进入后triedResolver会设为YES），进入method resolver（动态方法解析），首先对methodListLock解锁，然后调用_class_resolveMethod 发送_class_resolveInstanceMethod 或_class_resolveClassMethod 消息，程序员此时可以动态的给selector添加一个对应的IMP。完成后再回到第1步重新来一遍。这一步消息转发前最后一次机会。 没有找到方法的实现，method resolver（动态方法解析）也没有作用，此时进行消息的转发，使methodPC指向_objc_msgForward_impcache 汇编程序入口，并进入done。
done语句标号
首先将methodListLock解锁，然后断言不会存在一个被忽略的selector其implementation是没有被忽略的（官方的意思是非要找到这样一个selector，真是有趣）
paranoia: look for ignored selectors with non-ignored implementations
最后返回这个methodPC。
然后就是消息转发部分了，其objc_setForwardHandler实现机制不在Objective-C Runtime （libobjc.dylib）中，而是在CoreFoundation（CoreFoundation.framework）中，所以这里就先不讨论了，等我以后研究了那部分以后，再专门写一篇关于消息转发的博客。
关于正文开始处所说的第二种方法method_getImplementation()，首先需要调用class_getInstanceMethod() 而在这个方法里加了一个warning
#warning fixme build and search caches
// Search method lists, try method resolver, etc.
lookUpImpOrNil(cls, sel, nil,
NO/*initialize*/, NO/*cache*/, YES/*resolver*/);
#warning fixme build and search caches
我这里调用了lookUpImpOrNil方法，却没有使用其返回值，而且标注需要fix and search caches，我猜测可能因为某种原因，在这里无法进行缓存查找，而后面return _class_getMethod(cls, sel);本质上就是在方法列表中进行查找，而且也没有进行消息转发。
这里也印证了苹果对于这个方法的注释：class_getMethodImplementation may be faster than method_getImplementation(class_getInstanceMethod(cls, name))，因为第一个方法进行了缓存的查找，如果缓存中能找到，效率会提高很多。
以前的问题
在我上一篇博客里我有一个没有解决的问题：为什么对于无法找到的IMP，class_getMethodImplementation()，method_getImplementation()返回值会不一样？
IMP method_getImplementation(Method m)
return m ? m-&imp :
看完源码，就很清楚了，如果这个method不存在，直接返回nil，而
class_getMethodImplementation()会经历消息转发机制，最后返回的是forwardInvocation的结果，而这部分是不开源的，也不知道具体是怎么返回的，但每次运行确实是会返回的一个固定的地址，我猜测最后这个地址可能和NSInvocation这个对象的内存地址有关，具体那是什么地址，以后有机会在去寻找答案。JSPatch实现原理详解：让JS调用/替换任意OC方法
招聘信息：
以小巧的体积做到了让JS调用/替换任意OC方法，让iOS APP具备的能力，在实现 JSPatch 过程中遇到过很多困难也踩过很多坑，有些还是挺值得分享的。本篇文章从基础原理、方法调用和方法替换三块内容介绍整个 JSPatch 的实现原理，并把实现过程中的想法和碰到的坑也尽可能记录下来。基础原理能做到通过JS调用和改写OC方法最根本的原因是 Objective-C 是动态语言，OC上所有方法的调用/类的生成都通过 Objective-C Runtime 在运行时进行，我们可以通过类名/方法名反射得到相应的类和方法：Class&class&=&NSClassFromString("UIViewController");
id&viewController&=&[[class&alloc]&init];
SEL&selector&=&NSSelectorFromString("viewDidLoad");
[viewController&performSelector:selector];也可以替换某个类的方法为新的实现：static&void&newViewDidLoad(id&slf,&SEL&sel)&{}
class_replaceMethod(class,&selector,&newViewDidLoad,&@"");还可以新注册一个类，为类添加方法：Class&cls&=&objc_allocateClassPair(superCls,&"JPObject",&0);
objc_registerClassPair(cls);
class_addMethod(cls,&selector,&implement,&typedesc);对于 Objective-C 对象模型和动态消息发送的原理已有很多文章阐述得很详细，例如，这里就不详细阐述了。理论上你可以在运行时通过类名/方法名调用到任何OC方法，替换任何类的实现以及新增任意类。所以 JSPatch 的原理就是：JS传递字符串给OC，OC通过 Runtime 接口调用和替换OC方法。这是最基础的原理，实际实现过程还有很多怪要打，接下来看看具体是怎样实现的。方法调用require('UIView')
var&view&=&UIView.alloc().init()
view.setBackgroundColor(require('UIColor').grayColor())
view.setAlpha(0.5)引入JSPatch后，可以通过以上JS代码创建了一个 UIView 实例，并设置背景颜色和透明度，涵盖了require引入类，JS调用接口，消息传递，对象持有和转换，参数转换这五个方面，接下来逐一看看具体实现。1.require调用 require(‘UIView’) 后，就可以直接使用 UIView 这个变量去调用相应的类方法了，require 做的事很简单，就是在JS全局作用域上创建一个同名变量，变量指向一个对象，对象属性__isCls表明这是一个 Class，__clsName保存类名，在调用方法时会用到这两个属性。var&_require&=&function(clsName)&{
&&if&(!global[clsName])&{
&&&&global[clsName]&=&{
&&&&&&__isCls:&1,
&&&&&&__clsName:&clsName
&&return&global[clsName]
}所以调用require(‘UIView’)后，就在全局作用域生成了 UIView 这个变量，指向一个这样一个对象：{
&&__isCls:&1,
&&__clsName:&"UIView"
}2.JS接口接下来看看 UIView.alloc() 是怎样调用的。旧实现对于这个调用的实现，一开始我的想法是，根据JS特性，若要让 UIView.alloc() 这句调用不出错，唯一的方法就是给 UIView 这个对象添加 alloc 方法，不然是不可能调用成功的，JS对于调用没定义的属性/变量，只会马上抛出异常，而不像OC/Lua/ruby那样会有转发机制。所以做了一个复杂的事，就是在require生成类对象时，把类名传入OC，OC通过 Runtime 方法找出这个类所有的方法返回给JS，JS类对象为每个方法名都生成一个函数，函数内容就是拿着方法名去OC调用相应方法。生成的 UIView 对象大致是这样的：{&
&&&&__isCls:&1,
&&&&__clsName:&"UIView",
&&&&alloc:&function()&{…},
&&&&beginAnimations_context:&function()&{…},
&&&&setAnimationsEnabled:&function(){…},
}实际上不仅要遍历当前类的所有方法，还要循环找父类的方法直到顶层，整个继承链上的所有方法都要加到JS对象上，一个类就有几百个方法，这样把方法全部加到JS对象上，碰到了挺严重的问题，引入几个类就内存暴涨，无法使用。后来为了优化内存问题还在JS搞了继承关系，不把继承链上所有方法都添加到一个JS对象，避免像基类 NSObject 的几百个方法反复添加在每个JS对象上，每个方法只存在一份，JS对象复制了OC对象的继承关系，找方法时沿着继承链往上找，结果内存消耗是小了一些，但还是大到难以接受。新实现当时继续苦苦寻找解决方案，若按JS语法，这是唯一的方法，但若不按JS语法呢？突然脑洞开了下，CoffieScript/JSX都可以用JS实现一个解释器实现自己的语法，我也可以通过类似的方式做到，再进一步想到其实我想要的效果很简单，就是调用一个不存在方法时，能转发到一个指定函数去执行，就能解决一切问题了，这其实可以用简单的字符串替换，把JS脚本里的方法调用都替换掉。最后的解决方案是，在OC执行JS脚本前，通过正则把所有方法调用都改成调用 __c() 函数，再执行这个JS脚本，做到了类似OC/Lua/Ruby等的消息转发机制：UIView.alloc().init()
UIView.__c('alloc')().__c('init')()给JS对象基类 Object 的 prototype 加上 __c 成员，这样所有对象都可以调用到 __c，根据当前对象类型判断进行不同操作：Object.prototype.__c&=&function(methodName)&{
&&if&(!this.__obj&&&&!this.__clsName)&return&this[methodName].bind(this);
&&var&self&=&this
&&return&function(){
&&&&var&args&=&Array.prototype.slice.call(arguments)
&&&&return&_methodFunc(self.__obj,&self.__clsName,&methodName,&args,&self.__isSuper)
}_methodFunc() 就是把相关信息传给OC，OC用 Runtime 接口调用相应方法，返回结果值，这个调用就结束了。这样做不用去OC遍历对象方法，不用在JS对象保存这些方法，内存消耗直降99%，这一步是做这个项目最爽的时候，用一个非常简单的方法解决了严重的问题，替换之前又复杂效果又差的实现。3.消息传递解决了JS接口问题，接下来看看JS和OC是怎样互传消息的。这里用到了 JavaScriptCore 的接口，OC端在启动JSPatch引擎时会创建一个 JSContext 实例，JSContext 是JS代码的执行环境，可以给 JSContext 添加方法，JS就可以直接调用这个方法：JSContext&*context&=&[[JSContext&alloc]&init];
context[@"hello"]&=&^(NSString&*msg)&{
&&&&NSLog(@"hello&%@",&msg);
[_context&evaluateScript:@"hello('word')"];&&&&&//output&hello&wordJS通过调用 JSContext 定义的方法把数据传给OC，OC通过返回值传会给JS。调用这种方法，它的参数/返回值 JavaScriptCore 都会自动转换，OC里的 NSArray, NSDictionary, NSString, NSNumber, NSBlock 会分别转为JS端的数组/对象/字符串/数字/函数类型。上述 _methodFunc() 方法就是这样把要调用的类名和方法名传递给OC的。4.对象持有/转换UIView.alloc() 通过上述消息传递后会到OC执行 [UIView alloc]，并返回一个UIView实例对象给JS，这个OC实例对象在JS是怎样表示的呢？怎样可以在JS拿到这个实例对象后可以直接调用它的实例方法 (UIView.alloc().init())？对于一个自定义id对象，JavaScriptCore 会把这个自定义对象的指针传给JS，这个对象在JS无法使用，但在回传给OC时OC可以找到这个对象。对于这个对象生命周期的管理，按我的理解如果JS有变量引用时，这个OC对象引用计数就加1 ，JS变量的引用释放了就减1，如果OC上没别的持有者，这个OC对象的生命周期就跟着JS走了，会在JS进行垃圾回收时释放。传回给JS的变量是这个OC对象的指针，如果不经过任何处理，是无法通过这个变量去调用实例方法的。所以在返回对象时，JSPatch 会对这个对象进行封装。首先，告诉JS这是一个OC对象：static&NSDictionary&*toJSObj(id&obj)
&&&&if&(!obj)&return&
&&&&return&@{@"__isObj":&@(YES),&@"cls":&NSStringFromClass([obj&class]),&@"obj":&obj};
}用__isObj表示这是一个OC对象，对象指针也一起返回。接着在JS端会把这个对象转为一个 JSClass 实例：var&JSClass
var&_getJSClass&=&function(className)&{
&&if&(!JSClass)&{
&&&&JSClass&=&function(obj,&className,&isSuper)&{
&&&&&&&&this.__obj&=&obj
&&&&&&&&this.__isSuper&=&isSuper
&&&&&&&&this.__clsName&=&className
&&return&JSClass
var&_toJSObj&=&function(meta)&{
&&var&JSClass&=&_getJSClass()
&&return&new&JSClass(meta["obj"],&meta["cls"])
}JS端如果发现返回是一个OC对象，会传入 _toJSObj()，生成一个 JSClass 实例，这个实例保存着OC对象指针，类名等。这个实例就是OC对象在 JSPatch 对应的JS对象，生命周期是一样的。回到我们第二点说的 JS接口， 这个 JSClass 实例对象同样有 __c 函数，调用这个对象的方法时，同样走到 __c 函数， __c 函数会把JSClass实例对象里的OC对象指针以及要调用的方法名和参数回传给OC，这样OC就可以调用这个对象的实例方法了。接着看看对象是怎样回传给OC的。上述例子中，view.setBackgroundColor(require(‘UIColor’).grayColor())，这里生成了一个 UIColor 实例对象，并作为参数回传给OC。根据上面说的，这个 UIColor 实例在JS中的表示是一个 JSClass 实例，所以不能直接回传给OC，这里的参数实际上会在 __c 函数进行处理，会把对象的 .__obj 原指针回传给OC。最后一点，OC对象可能会存在于 NSDictionary / NSArray 等容器里，所以需要遍历容器挑出OC对象进行格式化，OC需要把对象都替换成JS认得的格式，JS要把对象转成 JSClass 实例，JS实例回传给OC时需要把实例转为OC对象指针。所以OC流出数据时都会经过 formatOCObj() 方法处理，JS从OC得到数据时都会经过 _formatOCToJS() 处理，JS传参数给OC时会经过 _formatJSToOC() 处理，图示：5.类型转换JS把要调用的类名/方法名/对象传给OC后，OC调用类/对象相应的方法是通过 NSInvocation 实现，要能顺利调用到方法并取得返回值，要做两件事：1.取得要调用的OC方法各参数类型，把JS传来的对象转为要求的类型进行调用。2.根据返回值类型取出返回值，包装为对象传回给JS。例如开头例子的 view.setAlpha(0.5)， JS传递给OC的是一个 NSNumber，OC需要通过要调用OC方法的 NSMethodSignature 得知这里参数要的是一个 float 类型值，于是把NSNumber转为float值再作为参数进行OC方法调用。这里主要处理了 int/float/bool 等数值类型，并对 CGRect/CGRange 等类型进行了特殊转换处理，剩下的就是实现细节了。方法替换JSPatch 可以用 defineClass 接口任意替换一个类的方法，方法替换的实现过程也是颇为曲折，一开始是用 va_list 的方式获取参数，结果发现 arm64 下不可用，只能转而用另一种hack方式绕道实现。另外在给类新增方法、实现property、支持self/super关键字上也费了些功夫，下面逐个说明。基础原理OC上，每个类都是这样一个结构体：struct&objc_class&{
&&struct&objc_class&*&
&&const&char&*&
&&struct&objc_method_list&**methodL&/*方法链表*/
};其中 methodList 方法链表里存储的是Method类型：typedef&struct&objc_method&*M
typedef&struct&objc_&method&{
&&SEL&method_
&&char&*method_
&&IMP&method_
};Method 保存了一个方法的全部信息，包括SEL方法名，type各参数和返回值类型，IMP该方法具体实现的函数指针。通过 Selector 调用方法时，会从 methodList 链表里找到对应Method进行调用，这个 methodList 上的的元素是可以动态替换的，可以把某个 Selector 对应的函数指针IMP替换成新的，也可以拿到已有的某个 Selector 对应的函数指针IMP，让另一个 Selector 跟它对应，Runtime 提供了一些接口做这些事，以替换 UIViewController 的 -viewDidLoad: 方法为例：static&void&viewDidLoadIMP&(id&slf,&SEL&sel)&{
&&&JSValue&*jsFunction&=&…;
&&&[jsFunction&callWithArguments:nil];
Class&cls&=&NSClassFromString(@"UIViewController");
SEL&selector&=&@selector(viewDidLoad);
Method&method&=&class_getInstanceMethod(cls,&selector);
//获得viewDidLoad方法的函数指针
IMP&imp&=&method_getImplementation(method)
//获得viewDidLoad方法的参数类型
char&*typeDescription&=&(char&*)method_getTypeEncoding(method);
//新增一个ORIGViewDidLoad方法，指向原来的viewDidLoad实现
class_addMethod(cls,&@selector(ORIGViewDidLoad),&imp,&typeDescription);
//把viewDidLoad&IMP指向自定义新的实现
class_replaceMethod(cls,&selector,&viewDidLoadIMP,&typeDescription);这样就把 UIViewController 的 -viewDidLoad 方法给替换成我们自定义的方法，APP里调用 UIViewController 的 viewDidLoad 方法都会去到上述 viewDidLoadIMP 函数里，在这个新的IMP函数里调用JS传进来的方法，就实现了替换 -viewDidLoad 方法为JS代码里的实现，同时为 UIViewController 新增了个方法 -ORIGViewDidLoad 指向原来 viewDidLoad 的IMP，JS可以通过这个方法调用到原来的实现。方法替换就这样很简单的实现了，但这么简单的前提是，这个方法没有参数。如果这个方法有参数，怎样把参数值传给我们新的IMP函数呢？例如 UIViewController 的 -viewDidAppear: 方法，调用者会传一个Bool值，我们需要在自己实现的IMP（上述的viewDidLoadIMP）上拿到这个值，怎样能拿到？如果只是针对一个方法写IMP，是可以直接拿到这个参数值的：static&void&viewDidAppear&(id&slf,&SEL&sel,&BOOL&animated)&{
&&&[function&callWithArguments:@(animated)];
}但我们要的是实现一个通用的IMP，任意方法任意参数都可以通过这个IMP中转，拿到方法的所有参数回调JS的实现。va_list实现(32位)最初我是用可变参数va_list实现：static&void&commonIMP(id&slf,&...)
&&va_list&
&&va_start(args,&slf);
&&NSMutableArray&*list&=&[[NSMutableArray&alloc]&init];
&&NSMethodSignature&*methodSignature&=&[cls&instanceMethodSignatureForSelector:selector];
&&NSUInteger&numberOfArguments&=&methodSignature.numberOfA
&&for&(NSUInteger&i&=&2;&i&<&numberOfA&i++)&{
&&&&&&const&char&*argumentType&=&[methodSignature&getArgumentTypeAtIndex:i];
&&&&&&switch(argumentType[0])&{
&&&&&&&&&&case&&#39;i&#39;:
&&&&&&&&&&&&&&obj&=&@(va_arg(args,&int));
&&&&&&&&&&&&&&
&&&&&&&&&&case&&#39;B&#39;:
&&&&&&&&&&&&&&obj&=&@(va_arg(args,&BOOL));
&&&&&&&&&&&&&&
&&&&&&&&&&case&&#39;f&#39;:
&&&&&&&&&&case&&#39;d&#39;:
&&&&&&&&&&&&&&obj&=&@(va_arg(args,&double));
&&&&&&&&&&&&&&
&&&&&&&&&&……&//其他数值类型
&&&&&&&&&&default:&{
&&&&&&&&&&&&&&obj&=&va_arg(args,&id);
&&&&&&&&&&&&&&
&&&&&&&&&&}
&&&&&&[list&addObject:obj];
&&va_end(args);
&&[function&callWithArguments:list];
}这样无论方法参数是什么，有多少个，都可以通过 va_list 的一组方法一个个取出来，组成NSArray在调用JS方法时传回。很完美地解决了参数的问题，一直运行正常，直到我跑在arm64的机子上测试，一调用就crash。查了资料，才发现arm64下 va_list 的结构改变了，导致无法上述这样取参数。详见。ForwardInvocation实现(64位)后来找到另一种非常hack的方法解决参数获取的问题，利用了OC消息转发机制。当调用一个 NSObject 对象不存在的方法时，并不会马上抛出异常，而是会经过多层转发，层层调用对象的 -resolveInstanceMethod:, -forwardingTargetForSelector:, -methodSignatureForSelector:, -forwardInvocation: 等方法，说得比较清楚，其中最后 -forwardInvocation: 是会有一个 NSInvocation 对象，这个 NSInvocation 对象保存了这个方法调用的所有信息，包括 Selector 名，参数和返回值类型，最重要的是有所有参数值，可以从这个 NSInvocation 对象里拿到调用的所有参数值。我们可以想办法让每个需要被JS替换的方法调用最后都调到 -forwardInvocation:，就可以解决无法拿到参数值的问题了。具体实现，以替换 UIViewController 的 -viewWillAppear: 方法为例：把UIViewController的 -viewWillAppear: 方法通过 class_replaceMethod() 接口指向一个不存在的IMP: class_getMethodImplementation(cls, @selector(__JPNONImplementSelector))，这样调用这个方法时就会走到 -forwardInvocation:。为 UIViewController 添加 -ORIGviewWillAppear: 和 -_JPviewWillAppear: 两个方法，前者指向原来的IMP实现，后者是新的实现，稍后会在这个实现里回调JS函数。改写 UIViewController 的 -forwardInvocation: 方法为自定义实现。一旦OC里调用 UIViewController 的 -viewWillAppear: 方法，经过上面的处理会把这个调用转发到 -forwardInvocation: ，这时已经组装好了一个 NSInvocation，包含了这个调用的参数。在这里把参数从 NSInvocation 反解出来，带着参数调用上述新增加的方法 -JPviewWillAppear: ，在这个新方法里取到参数传给JS，调用JS的实现函数。整个调用过程就结束了，整个过程图示如下：最后一个问题，我们把 UIViewController 的 -forwardInvocation: 方法的实现给替换掉了，如果程序里真有用到这个方法对消息进行转发，原来的逻辑怎么办？首先我们在替换 -forwardInvocation: 方法前会新建一个方法 -ORIGforwardInvocation:，保存原来的实现IMP，在新的 -forwardInvocation: 实现里做了个判断，如果转发的方法是我们想改写的，就走我们的逻辑，若不是，就调 -ORIGforwardInvocation: 走原来的流程。实现过程中还碰到一个坑，就是从 -forwardInvocation: 里的 NSInvocation 对象取参数值时，若参数值是id类型，我们会这样取:id&
[invocation&getArgument:&arg&atIndex:i];但这样取某些时候会导致莫名其妙的crash，而且不是crash在这个地方，似乎这里的指针取错导致后续的内存错乱，crash在各种地方，这个bug查了我半天才定位到这里，至今不知为什么。后来以这样的方式解决了：void&*
[invocation&getArgument:&arg&atIndex:i];
id&a&=&(__bridge&id)其他就是实现上的细节了，例如需要根据不同的返回值类型生成不同的IMP，要在各处处理参数转换等。新增方法在 JSPatch 刚开源时，是不支持为一个类新增方法的，因为觉得能替换原生方法就够了，新的方法纯粹添加在JS对象上，只在JS端跑就行了。另外OC为类新增方法需要知道各个参数和返回值的类型，需要在JS定一种方式把这些类型传给OC才能完成新增方法，比较麻烦。后来挺多人比较关注这个问题，不能新增方法导致 action-target 模式无法用，我也开始想有没有更好的方法实现添加方法。一开始想到，反正新增的方法都是JS在用，不如新增的方法返回值和参数全统一成id类型，这样就不用传类型了，但还是需要知道参数个数，后来跟Lancy聊天时找到了解决方案，JS可以获得函数参数个数，直接封装一下把参数个数一并传给OC就行了。现在 defineClass 定义的方法会经过JS包装，变成一个包含参数个数和方法实体的数组传给OC，OC会判断如果方法已存在，就执行替换的操作，若不存在，就调用 class_addMethod() 新增一个方法，通过传过来的参数个数和方法实体生成新的 Method，把 Method 的参数和返回值类型都设为id。这里有个问题，若某个类实现了某protocol，protocol方法里有可选的方法，它的参数不全是id类型，例如 UITableViewDataSource 的一个方法：-&(NSInteger)tableView:(UITableView&*)tableView&sectionForSectionIndexTitle:(NSString&*)title&atIndex:(NSInteger)若原类没有实现这个方法，在JS里实现了，会走到新增方法的逻辑，每个参数类型都变成id，与这个 protocol 方法不匹配，产生错误。后续会处理 protocol 的问题，若新增的方法是 protocol 实现的方法，会取这个方法的 NSMethodSignature 获得正确的参数类型进行添加。Property实现defineClass(&#39;JPTableViewController&:&UITableViewController&#39;,&{
&&dataSource:&function()&{
&&&&var&data&=&self.getProp(&#39;data&#39;)
&&&&if&(data)&return&
&&&&data&=&[1,2,3]
&&&&self.setProp_forKey(data,&&#39;data&#39;)
&&&&return&
}JSPatch 可以通过 -getProp:， -setProp:forKey: 这两个方法给对象添加成员变量。实现上用了运行时关联接口 objc_getAssociatedObject() 和 objc_setAssociatedObject() 模拟，相当于把一个对象跟当前对象 self 关联起来，以后可以通过当前对象 self 找到这个对象，跟成员的效果一样，只是一定得是id对象类型。本来OC有 class_addIvar() 可以为类添加成员，但必须在类注册之前添加完，注册完成后无法添加，这意味着可以为在JS新增的类添加成员，但不能为OC上已存在的类添加，所以只能用上述方法模拟。self关键字defineClass("JPViewController:&UIViewController",&{
&&viewDidLoad:&function()&{
&&&&var&view&=&self.view()
}JSPatch支持直接在 defineClass 里的实例方法里直接使用 self 关键字，跟OC一样 self 是指当前对象，这个 self 关键字是怎样实现的呢？实际上这个self是个全局变量，在 defineClass 里对实例方法 方法进行了包装，在调用实例方法之前，会把全局变量 self 设为当前对象，调用完后设回空，就可以在执行实例方法的过程中使用 self 变量了。这是一个小小的trick。super关键字defineClass("JPViewController:&UIViewController",&{
&&viewDidLoad:&function()&{
&&&&self.super.viewDidLoad()
}OC里 super 是一个关键字，无法通过动态方法拿到 super，那么 JSPatch 的super是怎么实现的？实际上调用 super 的方法，OC做的事是调用父类的某个方法，并把当前对象当成 self 传入父类方法，我们只要模拟它这个过程就行了。首先JS端需要告诉OC想调用的是当前对象的 super 方法，做法是调用 self.super时，会返回一个新的 JSClass 实例，这个实例同样保存了OC对象的引用，同时标识 __isSuper=1。JSClass&=&function(obj,&className,&isSuper)&{
&&&&this.__obj&=&obj
&&&&this.__isSuper&=&isSuper
&&&&this.__clsName&=&className
JSClass.prototype.__defineGetter__(&#39;super&#39;,&function(){
&&if&(!this.__super)&{
&&&&this.__super&=&new&JSClass(this.__obj,&this.__clsName,&1)
&&return&this.__super
})调用方法时，__isSuper 会传给OC，告诉OC要调 super 的方法。OC做的事情是，如果是调用 super 方法，找到 superClass 这个方法的IMP实现，为当前类新增一个方法指向 super 的IMP实现，那么调用这个类的新方法就相当于调用 super 方法。把要调用的方法替换成这个新方法，就完成 super 方法的调用了。static&id&callSelector(NSString&*className,&NSString&*selectorName,&NSArray&*arguments,&id&instance,&BOOL&isSuper)&{
&&&&if&(isSuper)&{
&&&&&&&&NSString&*superSelectorName&=&[NSString&stringWithFormat:@"SUPER_%@",&selectorName];
&&&&&&&&SEL&superSelector&=&NSSelectorFromString(superSelectorName);
&&&&&&&&Class&superCls&=&[cls&superclass];
&&&&&&&&Method&superMethod&=&class_getInstanceMethod(superCls,&selector);
&&&&&&&&IMP&superIMP&=&method_getImplementation(superMethod);
&&&&&&&&class_addMethod(cls,&superSelector,&superIMP,&method_getTypeEncoding(superMethod));
&&&&&&&&selector&=&superS
}总结整个 JSPatch 实现原理就大致描述完了，剩下的一些小点，例如GCD接口，block实现，方法名下划线处理等就不细说了，可以直接看代码。JSPatch 还在持续改进中，希望能成为iOS平台动态更新的最佳解决方案，欢迎大家一起建设这个项目，github地址： 版权声明：本文章在微信公众平台的发表权，已「独家代理」给指定公众帐号：iOS开发(iOSDevTips)。
微信扫一扫
订阅每日移动开发及APP推广热点资讯公众号：CocoaChina
您还没有登录！请或
点击量4849点击量4404点击量3835点击量3456点击量3217点击量3180点击量3133点击量2980点击量2812
&2016 Chukong Technologies,Inc.
京公网安备89}