类的加载原理上

上篇文章我们已经了解到objc_init调用_dyld_objc_notify_register注册了load_image,load_image就是调用所有类里的load方法，今天我们来探讨一下map_images

objc_init

首先我们先来分析一下objc_init函数

void _objc_init(void)
{
    static bool initialized = false;
    if (initialized) return;
    initialized = true;
    
    // fixme defer initialization until an objc-using image is found?
    environ_init();  // 环境变量的初始化 export OBJC_HELP=1(终端也可以打印环境变量)
    tls_init();      // 线程池初始化
    static_init();  // 全局静态c++函数调用 libobjc 的全局构造函数自己调用，不用dyld调用
    runtime_init();  
    exception_init(); // 异常抛出点
#if __OBJC2__
    cache_t::init();
#endif
    _imp_implementationWithBlock_init();

    _dyld_objc_notify_register(&map_images, load_images, unmap_image);

#if __OBJC2__
    didCallDyldNotifyRegister = true;
#endif
}

• environ_init() : 读取影响运⾏时的环境变量。如果需要，还可以打印环境变量帮助。
• tls_init()关于线程key的绑定 - ⽐如每线程数据的析构函数
• static_init() 运⾏C ++静态构造函数。在dyld调⽤我们的静态构造函数之前，libc 会调⽤ _objc_init（），
  因此我们必须⾃⼰做
  *lock_init(): 没有重写,采⽤C++ 的特性
• cache_init() 缓存条件初始化
• runtime_init(): runtime运⾏时环境初始化,⾥⾯主要
  是:unattachedCategories,allocatedClasses 后⾯会分析
• _imp_implementationWithBlock_init:启动回调机制。通常这不会做什么，因为所有的初始化都是惰性的，但是对于某些进程，我们会迫不及待地加载trampolines dylib。
• exception_init 初始化libobjc的异常处理系统
  NSSetUncaughtExceptionHandler 注册异常回调函数

void HFExceptionHandlers(NSException *exception) {
    NSLog(@"%s",__func__);
    
    int32_t exceptionCount = atomic_fetch_add_explicit(&LGUncaughtExceptionCount,1,memory_order_relaxed);
    if (exceptionCount > LGUncaughtExceptionMaximum) {
        return;
    }
    // 获取堆栈信息 - model 编程思想
    NSArray *callStack = [LGUncaughtExceptionHandle lg_backtrace];
    NSMutableDictionary *userInfo = [NSMutableDictionary dictionaryWithDictionary:[exception userInfo]];
    [userInfo setObject:exception.name forKey:LGUncaughtExceptionHandlerSignalExceptionName];
    [userInfo setObject:exception.reason forKey:LGUncaughtExceptionHandlerSignalExceptionReason];
    [userInfo setObject:callStack forKey:LGUncaughtExceptionHandlerAddressesKey];
    [userInfo setObject:exception.callStackSymbols forKey:LGUncaughtExceptionHandlerCallStackSymbolsKey];
    [userInfo setObject:@"LGException" forKey:LGUncaughtExceptionHandlerFileKey];
    
    [[[LGUncaughtExceptionHandle alloc] init]
     performSelectorOnMainThread:@selector(lg_handleException:)
     withObject:
     [NSException
      exceptionWithName:[exception name]
      reason:[exception reason]
      userInfo:userInfo]
     waitUntilDone:YES]; // 发送到服务端，阻塞当前线程
    
}

+ (void)installUncaughtSignalExceptionHandler{
    // uncaught_handler() = fn = LGExceptionHandlers
//  objc_setUncaughtExceptionHandler()
    NSSetUncaughtExceptionHandler(&HFExceptionHandlers);
}

当发生异常，就会回调我们的HFExceptionHandlers函数，我们就可以在这个函数里面将异常信息发送到我们的服务器。

_dyld_objc_notify_register

image.png

_dyld_objc_notify_register(&map_images, load_images, unmap_image) 参数解释
这边map_images是取地址，而load_images不需要呢？
首先要先明白一点map_images参数是指针传递，传的是地址，可以进行修改返回相当于输入输出参数，而load_images值传递即输入参数。
我们要知道map_images函数是不断的循环和递归加载类的信息，所以中间会有所变化，因此用地址传递，而我们后续可能还有用到map_images

通过对代码分析，我们定位到一下函数走向流程
map_images ->map_images_nolock->_read_images...
map_images_nolock 该函数虽然代码挺多的，但是我们的主线是定位镜像的加载，里面很多函数都只是初始化和其他处理(根据注释猜测)，所以我们定位到read_image
目前我们先定位到read_image,主要是read_image函数代码里面有比较多函数名猜测是关于类的信息加载。

read_images

接下来我们重点分析read_images
通过read_image 里面的注释，我们可以将其流程归纳如下：

• 1: 条件控制进⾏⼀次的加载
• 2: 修复预编译阶段的 @selector 的混乱问题
• 3: 错误混乱的类处理
• 4:修复重映射⼀些没有被镜像⽂件加载进来的 类
• 5: 修复⼀些消息!
• 6: 当我们类⾥⾯有协议的时候 : readProtocol
• 7: 修复没有被加载的协议
• 8: 分类处理
• 9: 类的加载处理

• 10 : 没有被处理的类 优化那些被侵犯的类
  通过注释我们就能很快确定我们的研究目标9.类的加载处理。

  
  image.png

image.png

注意上面的注释：这边只有非懒加载类才能够进来，额什么是非懒加载类呢？也就是有load的方法的就是非懒加载类。

通过源码分析我们定位到上面两个地方，一个是readClass,另一个是realizeClassWithoutSwift
首先我们来分析一下readClass

image.png

readClass里面有对类的ro,rw,还有supperClass进行操作。所以我们猜测这边应该是类的加载。
如果这边是类的加载的话，那么我们定义的HFObject类应该会在这边加载，所以我们先断点到我们的类这边，通过一步步调试发现并没有走到断点三的位置也就是3360行，所以我们写的类并不是在这边加载的。
紧接着我们来看看realizeClassWithoutSwift
同样我们还是在realizeClassWithoutSwift添加一段判断是否是HFObject类的代码

image.png
从截图的代码中我们可以看到ro的获取以及rw的配置
而在代码下面还有对父类和元类的初始化

supercls = realizeClassWithoutSwift(remapClass(cls->getSuperclass()), nil); // 父类递归调用
metacls = realizeClassWithoutSwift(remapClass(cls->ISA()), nil); // 递归调用
...
 cls->setSuperclass(supercls);
 cls->initClassIsa(metacls);

我们还可以打印一下类的信息：

image.png
由此可以证明类的加载就在这个函数里头。但是这边只有对非懒加载类进来，如果懒加载的类呢？
我们可以通过断点来调试看看
image.png
image.png
通过bt打印函数调用堆栈如下
image.png
通过上面的断点调试我们可以得出结论：懒加载类在第一次调用的时候的时候，通过objc_msgSend发送消息，进行快速查找和慢速查找，在慢速查找的时候会初始化这个类。

补充：

1. 懒加载类与⾮懒加载类 — 当前类是否实现 load ⽅法

• 1: 懒加载类情况 数据加载推迟到第⼀次消息的时候
  lookUpImpOrForward
  realizeClassMaybeSwiftMaybeRelock
  realizeClassWithoutSwift
  methodizeClass
• 2: ⾮懒加载类情况 map_images的时候 加载所有类数据
  readClass
  _getObjc2NonlazyClassList
  realizeClassWithoutSwift
  methodizeClass

2. ro，rw，rwe 这三个的究竟是什么？
   app在使用类时，是需要在磁盘中app的二进制文件中读取类的信息，二进制文件中的类存储了类的元类、父类、flags和方法缓存，如下图

   
   image.png

类的额外信息(name、方法、协议和实例变量等)存储在class_ro_t中

class_ro_t简称ro：read only，将类从磁盘中读取到内存中就是对ro的赋值操作。由于ro是只读的，加载到内存后不会发生改变又称为clean memory（干净内存）。

image.png

class_rw_t简称rw：read write，用于读写编写程序也被称作drity memory， 在进程运行时发生更改的内存。类一经使用运行时就会分配一个额外的内存，那么这个内存变成了drity memory。但是在实际应用中，类的使用量只是10%，这样就在rw中造成了内存浪费，所以苹果就把rw中方法、协议和实例变量等放到了class_rw_ext_t中。

image.png
将需要动态更新的部分提取出来存入class_rw_ext_t
image.png

methodizeClass

methodizeClass是对方法的处理。那他都做了什么处理呢

static void methodizeClass(Class cls, Class previously)
{
    runtimeLock.assertLocked();

    bool isMeta = cls->isMetaClass();
    auto rw = cls->data();
    auto ro = rw->ro();
    auto rwe = rw->ext();

    // Methodizing for the first time
    if (PrintConnecting) {
        _objc_inform("CLASS: methodizing class '%s' %s", 
                     cls->nameForLogging(), isMeta ? "(meta)" : "");
    }

    // Install methods and properties that the class implements itself.
    method_list_t *list = ro->baseMethods();
    if (list) {
        prepareMethodLists(cls, &list, 1, YES, isBundleClass(cls), nullptr);
        if (rwe) rwe->methods.attachLists(&list, 1);
    }

    property_list_t *proplist = ro->baseProperties;
    if (rwe && proplist) {
        rwe->properties.attachLists(&proplist, 1);
    }

    protocol_list_t *protolist = ro->baseProtocols;
    if (rwe && protolist) {
        rwe->protocols.attachLists(&protolist, 1);
    }

    // Root classes get bonus method implementations if they don't have 
    // them already. These apply before category replacements.
    if (cls->isRootMetaclass()) {
        // root metaclass
        addMethod(cls, @selector(initialize), (IMP)&objc_noop_imp, "", NO);
    }

    // Attach categories.
    if (previously) {
        if (isMeta) {
            objc::unattachedCategories.attachToClass(cls, previously,
                                                     ATTACH_METACLASS);
        } else {
            // When a class relocates, categories with class methods
            // may be registered on the class itself rather than on
            // the metaclass. Tell attachToClass to look for those.
            objc::unattachedCategories.attachToClass(cls, previously,
                                                     ATTACH_CLASS_AND_METACLASS);
        }
    }
    objc::unattachedCategories.attachToClass(cls, cls,
                                             isMeta ? ATTACH_METACLASS : ATTACH_CLASS);

#if DEBUG
    // Debug: sanity-check all SELs; log method list contents
    for (const auto& meth : rw->methods()) {
        if (PrintConnecting) {
            _objc_inform("METHOD %c[%s %s]", isMeta ? '+' : '-', 
                         cls->nameForLogging(), sel_getName(meth.name()));
        }
        ASSERT(sel_registerName(sel_getName(meth.name())) == meth.name());
    }
#endif
}

首先通过prepareMethodLists(cls, &list, 1, YES, isBundleClass(cls), nullptr)对方法列表进行排序，这样方便后面慢速查找时用二分查找来找方法，紧接着是对属性和协议进行处理。
注意这边的rwe为NULL，因为rwe只有在动态更新的时候才会有值，啥时候动态更新，也就是分类加载，动态添加方法属性的时候。