runtime源码解析(前传2)--Mach-O格式和runtime

在前传1中，我们分析了解了XNU内核所支持的二进制文件格式Mach-O。同时还留了一个小尾巴，就是Mach-O文件中和Objective-C以及runtime相关的Segment section。今天，就来了解一下它们。

OC之源起

我们知道，程序的入口点在iOS中被称之为main函数：

#import 
#import "AppDelegate.h"

int main(int argc, char * argv[]) {
    @autoreleasepool {
        return UIApplicationMain(argc, argv, nil, NSStringFromClass([AppDelegate class]));
    }
}

我们所写的所有代码，它的执行的第一步，均是由main函数开始的。

但其实，在程序进入main函数之前，内核已经为我们的程序加载和运行做了许多的事情。

当我们设置符号断点_objc_init，可以看到如下调用堆栈信息，这些函数都是在main函数调用前，被系统调用的：

_objc_init 是Object-C runtime的入口函数，在这里面主要功能是读取Mach-O文件OC对应的Segment seciton，并根据其中的数据代码信息，完成为OC的内存布局，以及初始化runtime相关的数据结构。
我们可以看到， __objc_init_ 是被 __dyld_start_ 所调用起来的， __dyld_start_ 是dyld的bootstrap方法，最终调用到了 __objc_init_。
dyld是苹果的动态加载器，用来加载image（注意这里image不是指图片，而是Mach -O格式的二进制文件）。
当程序启动时，系统内核首先会加载dyld， 而dyld会将我们APP所依赖的各种库加载到内存空间中，其中就包括libobjc库（OC和runtime）, 这些工作，是在APP的main函数执行前完成的。

在_objc_init 方法中，会注册监听来自dlyd的以下事件：

  // Register for unmap first, in case some +load unmaps something
    _dyld_register_func_for_remove_image(&unmap_image);
    dyld_register_image_state_change_handler(dyld_image_state_bound,
                                             1/*batch*/, &map_2_images);
    dyld_register_image_state_change_handler(dyld_image_state_dependents_initialized, 0/*not batch*/, &load_images);

对应的事件说明：

• _dyld_register_func_for_remove_image ： dyld将image移除内存
• dyld_image_state_bound ：dyld绑定了新的image
• dyld_image_state_dependents_initialized：image所依赖的各种库都被初始化好了

由上面代码可以看到，当dyld绑定了新的image之后，runtime会执行map_2_images方法，在这个方法中，libobjc会读取当前所加载的image的Mach-O文件信息，并利用和OC相关的Segment section中的信息，对OC内存空间的各种底层数据结构进行初始化，包括class struct的填充，category绑定到对应class，填充class的method list，protocol list以及property list等。当这一切都做好后，我们就可以在程序中尽情的调用runtime的各种黑魔法啦~ 说到底，所谓的runtime黑魔法，只是基于OC各种底层数据结构上的应用。

所以，要想深入的了解runtime，需要了解OC底层的各种C语言实现，这在后续的章节中会逐步介绍。而OC底层结构的初始化，则是借助于Mach-O文件格式以及dyld。

对于dyld是如何加载Mach-O文件的，我们这里不做深入介绍，有兴趣可以参见：iOS 程序 main 函数之前发生了什么。
这里，我们重点关注一下Mach-O文件和OC相关的Segment section。

PS：不要将OC和runtime分开理解，其实在苹果开源代码中，OC和runtime是在一个工程中objc4的。我们平常所用到的OC语言，底层90%都是由C语言加一些汇编代码实现的。比如OC中的NSObject它唯一的实例变量类型Class，对应C语言结构体objc_class。
而所谓的runtime，则是在OC这些C语言底层实现的数据结构基础上，进行的一些操作，比如交换Selector的实现，只需要交换method
list的IMP。获取一个对象的说有属性名称，只需要输出对应C语言结构property list即可。

Mach-O中OC相关的Segment Section

在上一篇文章中，我们可以看到，在__TEXT段和__DATA段中，都有如下以objc**形式命名的section，这些section，是和OC的内存布局相关的。

__TEXT & OC

__TEXT段是程序的不可变常量部分，包括了字符串常量，被const修饰的常量，同时也包括OC相关的一些seciton。

__objc_classname

这里面以字符串常量的形式，记录了我们自定义以及所引用的系统class的名称，同时也包括Category, protocol 的名称：

__objc_methname

这个seciton中记录了当前APP所调用的方法的名称：

__objc_methtype

这个seciton与__objc_methname节对应，记录了method的描述字符串：

__DATA & OC

以下内容的结论，大部分来自于五子棋大神的深入理解Macho文件（二）- 消失的__OBJC段与新生的__DATA段，里面涉及到许多的汇编分析，本人对汇编功力欠佳，所以仅能总结下大神的结论。

__objc_imageinfo

__objc_imageinfo section 主要用来区分OC的版本1.0 或 2.0，在OC源码中是这样定义的：

typedef struct {
    uint32_t version; // currently 0
    uint32_t flags;
} objc_image_info;

version 字段总是为0，而flags字段通过异或的方式，表面需要支持的特性。如是否需要/支持垃圾回收：

SupportsGC          = 1<<1,  // image supports GC
  RequiresGC          = 1<<2,  // image requires GC

if (ii.flags & (1<<1)) {
    // App wants GC. 
    // Don't return yet because we need to 
    // check the AppleScriptObjC exception.
    wantsGC = YES;
}

__objc_classlist

这个section列出了所有的class，包括meta class。
用MachOView查看该节，是这样的:

该节中存储的是一个个的指针，指针指向的地址是class结构体所在的地址。class结构体在OC中用结构体 objc_class表示。

struct objc_class : objc_object {
    // Class ISA;
    Class superclass;
    cache_t cache;             // formerly cache pointer and vtable
    class_data_bits_t bits;    // class_rw_t * plus custom rr/alloc flags
}

__objc_catlist

该节中存储了OC中定义的Catgory, 存储了一个个指向__objc_category类型的指针。

struct category_t {
    const char *name;
    classref_t cls;
    struct method_list_t *instanceMethods;
    struct method_list_t *classMethods;
    struct protocol_list_t *protocols;
    struct property_list_t *instanceProperties;
}

__objc_protolist

该节中记录了所有的协议。 像上面一样，也是存储了指向protocol_t的指针。

struct protocol_t : objc_object {
    const char *mangledName;
    struct protocol_list_t *protocols;
    method_list_t *instanceMethods;
    method_list_t *classMethods;
    method_list_t *optionalInstanceMethods;
    method_list_t *optionalClassMethods;
    property_list_t *instanceProperties;
    uint32_t size;   // sizeof(protocol_t)
    uint32_t flags;
    // Fields below this point are not always present on disk.
    const char **extendedMethodTypes;
    const char *_demangledName;
  }

__objc_classrefs

该节记录了那些class被引用了。因为有些类虽然被打包入APP中，但是在程序中并没有被引用。所以，这里记录了那些类真正的被我们实例化了。（注意，这里的AppDelegate 虽然在程序中没有显示的实例化，但系统似乎将其也标识为被引用的）

__objc_selrefs

这节告诉那些SEL对应的字符串被引用了，有系统方法，也有自定义方法：

__objc_superrefs

这一个节记录了调用super message的类。比如，在son方法中，我们调用了father的方法，就会将son class记录在这里。同理，在viewDidLoad中调用了super viewDidLoad, 因此view controller class也被记录在这里。

至于为什么要单独弄出一个section来记录所有调用了super message的类，这应该和[super message]的底层实现相关，说实话，五子棋大神的解释，我没有看懂……

__objc_const

这一节用来记录在OC内存初始化过程中的不可变内容。这里所谓的不可变内容并不是我们在程序中所写的const int k = 5这种常量数据（它存在__TEXT的const section中），而是在OC内存布局中不可变得部分，包括但不限于：

struct class_ro_t {
    uint32_t flags;
    uint32_t instanceStart;
    uint32_t instanceSize;
#ifdef __LP64__
    uint32_t reserved;
#endif

    const uint8_t * ivarLayout;

    const char * name;
    method_list_t * baseMethodList;
    protocol_list_t * baseProtocols;
    const ivar_list_t * ivars;

    const uint8_t * weakIvarLayout;
    property_list_t *baseProperties;

    method_list_t *baseMethods() const {
        return baseMethodList;
    }
};

// 方法列表
// Two bits of entsize are used for fixup markers.
struct method_list_t : entsize_list_tt {
    bool isFixedUp() const;
    void setFixedUp();

    uint32_t indexOfMethod(const method_t *meth) const {
        uint32_t i = 
            (uint32_t)(((uintptr_t)meth - (uintptr_t)this) / entsize());
        assert(i < count);
        return i;
    }
};
// 方法实体
struct method_t {
    SEL name;
    const char *types;
    IMP imp;

    struct SortBySELAddress :
        public std::binary_function
    {
        bool operator() (const method_t& lhs,
                         const method_t& rhs)
        { return lhs.name < rhs.name; }
    };
};

总结

今天我们了解了Mach-O格式和OC的关系，并大致了解了各个section中的内容。

当dyld加载我们的APP的时候，会通知OC读取对应seciton的内容，进而完成OC内存数据结构的初始化工作，为之后的程序运行及runtime黑魔法做好了准备。

注意，上面所说的工作，是在APP的main函数之前就已经结束了的。

到此为止，关于Mach-O格式，我们已经有了基本的了解了。接下来将会进入我们的正题：理解OC内部的各种数据结构，以及它们是如何被runtime所应用的。