介绍

runtime 运行时，这个几乎面试都会问而平时写代码用的不是很多的东西。同样可以看出，不仅仅runtime 其他的语言和技术也是，越是深度，用的越少。
runtime 都能干什么呢？这里我简单的终结了一下
1.发送消息 objc_msgSend
2.交互方法 method_exchangeImplementations
3.添加方法 resolveInstanceMethod
4.分类添加属性 objc_setAssociatedObject
5.字典边model class_copyIvarList ，这里加个setValue forKey
6.kvo 实现原理----这个面试问的多 willChangeValueForKey: 和 didChangeValueForKey:
.....
这也是我目前知道的，有补充的欢迎留言

目前国内背景

在前面说的例子，基本是目前runtime 我们能用的比较多的，baidu 一下能get 到现成代码，到项目中改一改就能用的。
所以现在runtime 在业内用的还是比较多的

开始

那这里我们反思一下，为什么有runtime ，或者没有他行不行
这里就要说起Object-C的消息机制了。消息机制是OC 比较独特的地方。
要实现的是对于class 或者 instance 发送一个SEL 在一个hash 表中或者代码块中寻找对应的imp 这个过程，可能使superClass 加入进来，也可能不是自己的class 里面的方法，可能是消息转发。等等一系列未知的情况。那么runtime 就这样诞生了。
这也是为什么说OC 是一门动态的语言。因为没有到最后谁也不知道sel 到底是和哪个imp 勾搭在一起了。

这里详细讨论一下最有名的objc_msgSend
我们每天都在用，可是没有了解它太多

内部结构

怎么能开始调用obj_msgSend
在NSObject.mm中可以看到

+ (id)performSelector:(SEL)sel {
    if (!sel) [self doesNotRecognizeSelector:sel];
    return ((id(*)(id, SEL))objc_msgSend)((id)self, sel);
}

+ (id)performSelector:(SEL)sel withObject:(id)obj {
    if (!sel) [self doesNotRecognizeSelector:sel];
    return ((id(*)(id, SEL, id))objc_msgSend)((id)self, sel, obj);
}

+ (id)performSelector:(SEL)sel withObject:(id)obj1 withObject:(id)obj2 {
    if (!sel) [self doesNotRecognizeSelector:sel];
    return ((id(*)(id, SEL, id, id))objc_msgSend)((id)self, sel, obj1, obj2);
}

- (id)performSelector:(SEL)sel {
    if (!sel) [self doesNotRecognizeSelector:sel];
    return ((id(*)(id, SEL))objc_msgSend)(self, sel);
}

- (id)performSelector:(SEL)sel withObject:(id)obj {
    if (!sel) [self doesNotRecognizeSelector:sel];
    return ((id(*)(id, SEL, id))objc_msgSend)(self, sel, obj);
}

- (id)performSelector:(SEL)sel withObject:(id)obj1 withObject:(id)obj2 {
    if (!sel) [self doesNotRecognizeSelector:sel];
    return ((id(*)(id, SEL, id, id))objc_msgSend)(self, sel, obj1, obj2);
}

这一大片，随便用一个就ok。

/* Basic Messaging Primitives
 *
 * On some architectures, use objc_msgSend_stret for some struct return types.
 * On some architectures, use objc_msgSend_fpret for some float return types.
 * On some architectures, use objc_msgSend_fp2ret for some float return types.
 *
 * These functions must be cast to an appropriate function pointer type 
 * before being called. 
 */
#if !OBJC_OLD_DISPATCH_PROTOTYPES
OBJC_EXPORT void objc_msgSend(void /* id self, SEL op, ... */ )
    OBJC_AVAILABLE(10.0, 2.0, 9.0, 1.0);

到这里，好像已经到了尽头，因为文档告诉你，这是个私有方法。
但是可以换个途径

调用 objc_msgSend 时，传入了 self 以及 SEL 参数。
既然要执行对应的方法，肯定要寻找选择子对应的实现。
在 objc-runtime-new.mm 文件中有一个函数 lookUpImpOrForward ，这个函数的作用就是查找方法的实现，于是运行程序，激活 lookUpImpOrForward 函数中的断点.
可以清楚看到调用的堆栈

[email protected]

为什么有uncached 这个我还是没有搞懂，因为我看调用的是objc_msgSend 可能是内部定义的吧

lookUpImpOrForward 返回的值是IMP
通过SEL 找到IMP 看来全靠他了


/***********************************************************************
* lookUpImpOrForward.
* The standard IMP lookup. 
* initialize==NO tries to avoid +initialize (but sometimes fails)
* cache==NO skips optimistic unlocked lookup (but uses cache elsewhere)
* Most callers should use initialize==YES and cache==YES.
* inst is an instance of cls or a subclass thereof, or nil if none is known. 
*   If cls is an un-initialized metaclass then a non-nil inst is faster.
* May return _objc_msgForward_impcache. IMPs destined for external use 
*   must be converted to _objc_msgForward or _objc_msgForward_stret.
*   If you don't want forwarding at all, use lookUpImpOrNil() instead.
**********************************************************************/
IMP lookUpImpOrForward(Class cls, SEL sel, id inst, 
                       bool initialize, bool cache, bool resolver)
{
    Class curClass;
    IMP imp = nil;
    Method meth;
    bool triedResolver = NO;

    runtimeLock.assertUnlocked();

    // Optimistic cache lookup
    if (cache) {
        imp = cache_getImp(cls, sel);
        if (imp) return imp;
    }

    if (!cls->isRealized()) {
        rwlock_writer_t lock(runtimeLock);
        realizeClass(cls);
    }

    if (initialize  &&  !cls->isInitialized()) {
        _class_initialize (_class_getNonMetaClass(cls, inst));
        // If sel == initialize, _class_initialize will send +initialize and 
        // then the messenger will send +initialize again after this 
        // procedure finishes. Of course, if this is not being called 
        // from the messenger then it won't happen. 2778172
    }

    // 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.
 retry:
    runtimeLock.read();

    // Try this class's cache.

    imp = cache_getImp(cls, sel);
    if (imp) goto done;

    // Try this class's method lists.

    meth = getMethodNoSuper_nolock(cls, sel);
    if (meth) {
        log_and_fill_cache(cls, meth->imp, sel, inst, cls);
        imp = meth->imp;
        goto done;
    }

    // Try superclass caches and method lists.

    curClass = cls;
    while ((curClass = curClass->superclass)) {
        // Superclass cache.
        imp = cache_getImp(curClass, sel);
        if (imp) {
            if (imp != (IMP)_objc_msgForward_impcache) {
                // Found the method in a superclass. Cache it in this class.
                log_and_fill_cache(cls, imp, sel, inst, curClass);
                goto done;
            }
            else {
                // Found a forward:: entry in a superclass.
                // Stop searching, but don't cache yet; call method 
                // resolver for this class first.
                break;
            }
        }

        // Superclass method list.
        meth = getMethodNoSuper_nolock(curClass, sel);
        if (meth) {
            log_and_fill_cache(cls, meth->imp, sel, inst, curClass);
            imp = meth->imp;
            goto done;
        }
    }

    // No implementation found. Try method resolver once.

    if (resolver  &&  !triedResolver) {
        runtimeLock.unlockRead();
        _class_resolveMethod(cls, sel, inst);
        // Don't cache the result; we don't hold the lock so it may have 
        // changed already. Re-do the search from scratch instead.
        triedResolver = YES;
        goto retry;
    }

    // No implementation found, and method resolver didn't help. 
    // Use forwarding.

    imp = (IMP)_objc_msgForward_impcache;
    cache_fill(cls, sel, imp, inst);

 done:
    runtimeLock.unlockRead();

    return imp;
}

这里面一共分为以下几步

Optimistic cache lookup
Try this class's cache.
Try this class's method lists
Superclass method list
No implementation found. Try method resolver once
No implementation found, and method resolver didn't help

这样可以看出，对于一个方法的处理逻辑
在类中寻找，父类中寻找，找到了元类。还没有找到那么给你一次机会 resolveMethod 是否有对这个sel 的实现
(BOOL)resolveInstanceMethod:(SEL)sel
如没有判断是否有转发
这个转发有很多种
-(id)forwardingTargetForSelector 这个返回的是转发的对象，显然这个更要灵活

关于源代码

obj_send_msg 这个方法虽然没有对方公开，objc_msgSend 在检查缓存。如果没有缓存会调用 lookupImpOrForward 进行方法查找。
网上大部分说是汇编写的，为了提高oc 的消息发送效率。这个因为没有看到代码。也不敢确定，不过通过各种实验可以确定。汇编可以搞定。具体的可以参考
https://www.mikeash.com/pyblog/friday-qa-2012-11-16-lets-build-objc_msgsend.html

这里有端代码

 id objc_msgSend(id self, SEL _cmd, ...)
    {
        Class c = object_getClass(self);
        IMP imp = cache_lookup(c, _cmd);
        if(!imp)
            imp = class_getMethodImplementation(c, _cmd);
        return imp(self, _cmd, ...);
    }

后期可以继续对内部进行分析，不过到这里已经是段落了。对于动态语言也会有个大概的了解，不仅仅是oc 。比如最近流行的Python，小程序的JS 。 js 是个万能的语言，更多的是我们需要一个万能的语言。
http://blog.csdn.net/liqingxu2005/article/details/41865821?locationNum=6

给我的技术启示

大概的runtime 框架以一个消息接受和发送的方法，简单叙述了一下，其他方法，各位可以多多探索，相互交流。
对于功能的实现是最基本的，公司不同，逻辑不用，业务不同。深度的东西不会改变这也是以后研究的方向。

关于面试

面试中，问的runtime感觉问与不问关系不大。因为现在网上的资料实在是太多了。这样是为什么你打开拉钩，基本找不到更高的待遇的原因。
技术不是赚钱的工具，是自我认知的工具。

结语

最后的最后，祝福大家2017 有好的技术启示，寻找到适合自己的技术方向。

iOS，关于runtime

介绍

目前国内背景

开始

内部结构

关于源代码

给我的技术启示

关于面试

结语

你可能感兴趣的:(iOS，关于runtime)