代码改变世界

Objective-C Message

2011-10-06 13:22  curer  阅读(4939)  评论(7编辑  收藏  举报

object c 里面有一个非常有趣的设计,如果之前了解过c++的家伙们,对object c 中的把传统的调用函数变成了向这个类发送消息,这个过程总是令人琢磨不透,在实际过程中遇到的crash也很难调试清楚。这篇就要详细的解释消息这个家伙。当然,消息这个涉及的东西实在是太多了。这篇先简单介绍一下。

上一篇,我们了解了什么是类http://www.cnblogs.com/studentdeng/archive/2011/10/01/2197194.html。同理这一篇,我们首先需要了解什么是message。

message(消息):message的具体定义很难说,因为并没有真正的代码描述,简单的讲message 是一种抽象,包括了函数名+参数列表,他并没有实际的实体存在。

method(方法):method是真正的存在的代码。如:- (int)meaning { return 42; }

selector: selector 通过SEL类型存在,描述一个特定的method or message。在实际编程中,可以通过selector来检索函数等操作。

我不知道上面这种描述有多少人可以明白,因为我觉得这3个每个人都可以有自己的看法,在了解object c message 的整个过程之后。

让我们从一个简单的例子开始。当我们写好如下的代码时

 - (int)foo:(NSString *)str { ...}

  

编译器事实上转成了下面的样子
int XXXX_XXXX_foo_(SomeClass *self, SEL _cmd, NSString *str) { ...}

  

当我们写下发送消息的代码如
int result = [obj foo:@"hello"];

  

实际上变成了
int result = ((int (*)(id, SEL, NSString *))objc_msgSend)(obj, @selector(foo:), @"hello");

  

而 objc_msgSend 是一个我们非常熟悉的C函数定义 id objc_msgSend(id self, SEL    _cmd,...);
那么,object c 发送消息就变成了一个表面上看似容易理解的C函数调用了,这里有必要解释一下几个名词
 
id:很多地方说id是一个void *的指针。事实上,id 其实是这样子的
typedef struct objc_object {
    Class isa;
} *id;

  

也就是说。id其实是一个可以指向任何一个object指针(只要结构体中包含isa 指针) 。

SEL:SEL 如果很粗鲁(我不知道改用什么其他词汇更容易描述)的讲,就是一个char * 的指针。因为你可以这样简单粗暴的测试

SEL selector = @selector(message); //@selector不是函数调用,只是给这个坑爹的编译器的一个提示
NSLog (@"%s", (char *)selector);  //print message 

  

注:这里之所以说粗鲁,是因为,这个的定义和object runtime 的具体实现息息相关,未来很可能改变,而这些定义也是没有文档化的,后面还会详细介绍SEL的具体实现。因为这里有不少为了提高效率而做的优化。

不知道有没有人惊呼这个问题。特别是如果之前从事C++的家伙们。传统的C++ 编译器在处理函数上,为了支持函数重载。使用了一种函数别名的方式如

int foo(int a);

  

变成了 XXX_1_foo_int (具体的形式没有意义,核心在于,编译器生成的函数签名包括函数名,参数类型,参数个数)。

但我们的SEL 仅仅是函数名而已。

有了这些知识做铺垫,原谅我在把这个东东再搬出来

int result = ((int (*)(id, SEL, NSString *))objc_msgSend)(obj, @selector(foo:), @"hello");

  

那么,作为程序员,我们就为这个而疯狂了,因为编译器无法根据id 和SEL 获得完整的函数签名,编译器对参数个数和类型,完全不知道。那么他如何能过做到识别这些并找到正确的代码呢?

事实上这个头痛的问题,编译器做了一个非常坑爹的事情,就是“ it cheats” ,他假装能够通过函数名,就能确定正确的代码。通过扫描之前的函数声明来做,如果没有找到,编译器就认为这是一个运行时(runtime)的函数而直接略过。而这也就导致了object c 在处理有相同函数名和参数个数但类型不同的函数时,非常的弱。如

-(void)setWidth:(int)width;

-(void)setWidth:(double)width;

  

这样的函数则被认为是一种编译错误,而这最终导致了一个非常非常奇怪的object c 特色的函数命名

-(void)setWidthIntValue:(int)width;

-(void)setWidthDoubleValue:(double)width;

  

注:这样的函数命名的好坏,只能说是因人而异的,站在我的角度来讲。object c 的这种命名实在是太臃肿了,这种冗长的名字让人感到作呕而没有任何美感。当然,这样的命名的确可以避免很多的错误,比如因C++ 函数重载而引起的人为上的小失误,而且减少了理解函数的负担。总有利弊,需要平衡:P,不过,我还是不喜欢object c 编译器,因为他彻底阻挡了你的想法,至于为什么这样设计,我的理解是为了runtime,在这里为了性能而做了妥协,具体原因,后面再讲。

popup our brain stack

objc_msgSend 这里传入了 class 指针 self  函数名SEL 已经后面通过C的不定参数传入的参数。通过这些条件。就像之前的C++函数那样,需要查表,并找到相应函数的位置,然后call xxxxx。那么。object c 是如何找到这些函数的真实地址呢? 之前有篇简单描述C++类函数布局的,有兴趣的可以对比的看。

为了解释这些这个过程,我们有需要介入一些名词了。

object c 2 的

typedef struct method_list_t {
    uint32_t entsize_NEVER_USE;  // low 2 bits used for fixup markers
    uint32_t count;
    struct method_t first;
} method_list_t;

typedef struct method_t {
    SEL name;
    const char *types;
    IMP imp;
} method_t;

  

method就是这么简单, 一个函数名SEL 一个包括的参数类型和返回类型的type 最后加一个IMP 而IMP 就是一个函数指针,指向我们真正的代码位置

typedef id             (*IMP)(id, SEL, ...); 

  

那么objc_msgSend 做的事情,就是通过我们传入的self 指针,找到class 的method_list 然后根据SEL 做比较,没有的话,就在super class 找,如此往复。直到找到匹配的SEL,然后,call imp。

那么,我们就发现了。如果object c 这样设计,调用函数的成本实在是太高了,相对传统的C函数调用。那么编译器和runtime又做了那些优化呢?有意思的事情开始了。

1、字符串比较

我们发现了SEL 就是简单的一个char* 字符串。那么,光是比较这一串字符,就可以让object c 慢的让人作呕了。那么我们就需要再认识一下我们的SEL了。

runtime 在实现selector是,实现了一个很大的Set,简单的说就是一个经过了杠杠优化过的hash表。而Set的特点就是唯一,也就是SEL是唯一的。那么对于字符串的比较仅仅需要比较他们的地址就可以了。犀利,速度上无语伦比,但是,有一个问题,就是数量增多会增大hash冲突而导致的性能下降(或是没有冲突,因为也可能用的是perfect hash)。但是不管使用什么样的方法加速,如果能够将总量减少,那将是最犀利的方法。那么,我们就不难理解,为什么SEL仅仅是函数名了。这样如

class A 有一个这样的method  -(void)setWidth:(int)width;

而 classB 有一个这样的method -(void)setWidth:(double)width;

那么的selector 将指向同一个地方,使用同一个selector,如果真的需要在类中定义类似重载时,只能使用不同的函数名了。

但是,这样的优化,依然不能让人满意,因为,根据二八原则,我们真正执行的只是少数代码。那么。就有

2、cache

cache的原则就是缓存那些可能要执行的函数地址,那么下次调用的时候,速度就可以快速很多。这个和CPU的各种缓存原理相通。好吧,说了这么多了,再来认识几个名词

struct objc_cache {
    uintptr_t mask;            /* total = mask + 1 */
    uintptr_t occupied;        
    cache_entry *buckets[1];
};

typedef struct {
    SEL name;     // same layout as struct old_method
    void *unused;
    IMP imp;  // same layout as struct old_method
} cache_entry;

  

看这个结构,有没有搞错又是hash table。

objc_msgSend 首先在cache list 中找SEL 没有找到就在class 找,super class 找(当然super class 也有cache list)。

而cache的机制则非常复杂了,由于object c 是动态语言。所以,这里面还有很多的多线程同步问题,而这些锁又是效率的大敌,相关的内容已经远远超过本文讨论的范围。

popup our brain stack

有了上面的粗略的介绍,是时候让我们看看objc_msgSend 的真面目了,当然,对于这个家伙是和性能息息相关的东西,没有任何缘由的是用汇编来写的。这里面贴出x86的,原谅我已经把arm汇编忘记了(主要原因是arm汇编是老师教得,x86是自学的,没有听学校老师的 :P)。

/********************************************************************
 *
 * id objc_msgSend(id self, SEL    _cmd,...);
 *
 ********************************************************************/
 
    ENTRY    _objc_msgSend
    CALL_MCOUNTER    LP0
 
    movl    self(%esp), %eax
 
// check whether receiver is nil 
    testl    %eax, %eax
    je    LMsgSendNilSelf
 
// receiver is non-nil: search the cache
    CacheLookup WORD_RETURN, MSG_SEND, LMsgSendCacheMiss
    movl    $kFwdMsgSend, %edx    // flag word-return for _objc_msgForward
    jmp    *%eax            // goto *imp
 
// cache miss: go search the method lists
LMsgSendCacheMiss:
    MethodTableLookup WORD_RETURN, MSG_SEND
    movl    $kFwdMsgSend, %edx    // flag word-return for _objc_msgForward
    jmp    *%eax            // goto *imp
 
// message sent to nil object: call optional handler and return nil
LMsgSendNilSelf:
    EXTERN_TO_REG(__objc_msgNil,%eax)
    movl    0(%eax), %eax        // load nil message handler
    testl    %eax, %eax
    je    LMsgSendDone        // if NULL just return and don't do anything
    call    *%eax            // call __objc_msgNil
    xorl    %eax, %eax        // Rezero $eax just in case
LMsgSendDone:
    ret
 
LMsgSendExit:
    END_ENTRY    _objc_msgSend

  

注释非常的详细+代码本身自解释,不做赘述,汇编的可读性都比我写的强,牛到不需要解释的代码。

MethodTableLookup 跳到__class_lookupMethodAndLoadCache
 
/***********************************************************************
* lookUpMethod.
* The standard method 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.
* May return _objc_msgForward_internal. IMPs destined for external use 
*   must be converted to _objc_msgForward or _objc_msgForward_stret.
**********************************************************************/
__private_extern__ IMP lookUpMethod(Class cls, SEL sel, 
                                    BOOL initialize, BOOL cache)
{
    Class curClass;
    IMP methodPC = NULL;
    Method meth;
    BOOL triedResolver = NO;
 
    // Optimistic cache lookup
    if (cache) {
        methodPC = _cache_getImp(cls, sel);
        if (methodPC) return methodPC;    
    }
 
    // realize, +initialize, and any special early exit
    methodPC = prepareForMethodLookup(cls, sel, initialize);
    if (methodPC) return methodPC;
 
 
    // 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:
    lockForMethodLookup();
 
    // Try this class's cache.
 
    //// self note 这里再次查找cache 是因为有可能cache真的又有了,因为锁的原因
    methodPC = _cache_getImp(cls, sel);
    if (methodPC) goto done;
 
    // Try this class's method lists.
 
     //self note 这个就是简单的在method 一个线性查找,因为我们仅仅是一个地址比较
    meth = _class_getMethodNoSuper_nolock(cls, sel); 
    if (meth) {
        //我们找到了函数地址,那么添加到cachelist中
        log_and_fill_cache(cls, cls, meth, sel);
        methodPC = method_getImplementation(meth);
        goto done;
    }
 
    // Try superclass caches and method lists.
 
    curClass = cls;
    while ((curClass = _class_getSuperclass(curClass))) {
        // Superclass cache.
        meth = _cache_getMethod(curClass, sel, &_objc_msgForward_internal);
        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);
                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 = _class_getMethodNoSuper_nolock(curClass, sel);
        if (meth) {
            log_and_fill_cache(cls, curClass, meth, sel);
            methodPC = method_getImplementation(meth);
            goto done;
        }
    }
 
    // No implementation found. Try method resolver once.
 
    if (!triedResolver) {
        unlockForMethodLookup();
        _class_resolveMethod(cls, sel);
        // 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.
 
    _cache_addForwardEntry(cls, sel);
    methodPC = &_objc_msgForward_internal;
 
 done:
    unlockForMethodLookup();
 
    // paranoia: look for ignored selectors with non-ignored implementations
    assert(!(sel == (SEL)kIgnore  &&  methodPC != (IMP)&_objc_ignored_method));
 
    return methodPC;
}

  

牛到不需要解释的代码。而且这里面,我们发现了另一个被我拉下的东西,消息的转发。这个东西还是下一篇处理。不想再写长篇大论了。