在前传1中，我们分析了解了XNU内核所支持的二进制文件格式Mach-O。同时还留了一个小尾巴，就是Mach-O文件中和Objective-C以及runtime相关的Segment section。今天，就来了解一下它们。
OC之源起
我们知道，程序的入口点在iOS中被称之为main函数：
#import <UIKit/UIKit.h>
#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<method_t, method_list_t, 0x3> {
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<const method_t&,
const method_t&, bool>
{
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所应用的。
网友评论