前言
在前一篇文章中我们分析了dyld的加载流程，那么它是如何与objc关联起来的呢？
objc4-781官方源码_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();
tls_init();
static_init();
runtime_init();
exception_init();
cache_init();
_imp_implementationWithBlock_init();
// 什么时候调用? images 镜像文件
// map_images()
// load_images()
_dyld_objc_notify_register(&map_images, load_images, unmap_image);
#if __OBJC2__
didCallDyldNotifyRegister = true;
#endif
}
参数说明
- environ_init() : 读取影响运⾏时的环境变量。如果需要，还可以打印环境变量帮助。
我们可以点击进入环境变量初始化 environ_init 方法，将控制环境变量打印信息的条件都屏蔽掉，代码如下所示：
for (size_t i = 0; i < sizeof(Settings)/sizeof(Settings[0]); i++) {
const option_t *opt = &Settings[I];
_objc_inform("%s: %s", opt->env, opt->help);
_objc_inform("%s is set", opt->env);
}
控制台打印日志如下：
···
objc[38640]: OBJC_DISABLE_TAG_OBFUSCATION is set
objc[38640]: OBJC_DISABLE_NONPOINTER_ISA: disable non-pointer isa fields
objc[38640]: OBJC_DISABLE_NONPOINTER_ISA is set
objc[38640]: OBJC_DISABLE_INITIALIZE_FORK_SAFETY: disable safety checks for +initialize after fork
objc[38640]: OBJC_DISABLE_INITIALIZE_FORK_SAFETY is set
我们设置打印所有加载的文件的相关的load方法，设置环境 OBJC_PRINT_LOAD_METHODS = YES然后再次打印，控制台日志如下:
图1
···
objc[7093]: LOAD: class 'OS_xpc_connection' scheduled for +load
objc[7093]: LOAD: class 'OS_xpc_service' scheduled for +load
objc[7093]: LOAD: class 'OS_xpc_null' scheduled for +load
objc[7093]: LOAD: class 'OS_xpc_bool' scheduled for +load
objc[7093]: LOAD: class 'OS_xpc_double' scheduled for +load
objc[7093]: LOAD: class 'OS_xpc_pointer' scheduled for +load
objc[7093]: LOAD: class 'OS_xpc_date' scheduled for +load
objc[7093]: LOAD: class 'OS_xpc_data' scheduled for +load
objc[7093]: LOAD: class 'OS_xpc_string' scheduled for +load
objc[7093]: LOAD: class 'OS_xpc_uuid' scheduled for +load
objc[7093]: LOAD: class 'OS_xpc_fd' scheduled for +load
objc[7093]: LOAD: class 'OS_xpc_shmem' scheduled for +load
objc[7093]: LOAD: class 'OS_xpc_mach_send' scheduled for +load
objc[7093]: LOAD: class 'OS_xpc_array' scheduled for +load
objc[7093]: LOAD: class 'OS_xpc_dictionary' scheduled for +load
···
- tls_init() 关于线程key的绑定 - ⽐如每线程数据的析构函数
void tls_init(void)
{
#if SUPPORT_DIRECT_THREAD_KEYS
pthread_key_init_np(TLS_DIRECT_KEY, &_objc_pthread_destroyspecific);
#else
_objc_pthread_key = tls_create(&_objc_pthread_destroyspecific);
#endif
}
- static_init() 运⾏C ++静态构造函数。在dyld调⽤我们的静态构造函数之前，
libc会调⽤ _objc_init（），
因此我们必须⾃⼰做 - lock_init(): 没有重写,采⽤C++ 的特性
- exception_init () 初始化libobjc的异常处理系统
- cache_init() 缓存条件初始化
- runtime_init() : runtime运⾏时环境初始化,⾥⾯主要
是:unattachedCategories,allocatedClasses 后⾯会分析 - _imp_implementationWithBlock_init :启动回调机制。通常这不会做什么，因为所有的初始化都是惰性的，但是对于某些进程，我们会迫不及待地加载trampolines dylib。
_dyld_objc_notify_register 这个方法是跨库执行的，在苹果开源的 dyld 源码里面可以找到，然后看到调用了 dyld::registerObjCNotifiers 这个方法：
void registerObjCNotifiers(_dyld_objc_notify_mapped mapped, _dyld_objc_notify_init init, _dyld_objc_notify_unmapped unmapped)
{
// record functions to call
sNotifyObjCMapped = mapped;
sNotifyObjCInit = init;
sNotifyObjCUnmapped = unmapped;
// call 'mapped' function with all images mapped so far
try {
notifyBatchPartial(dyld_image_state_bound, true, NULL, false, true);
}
catch (const char* msg) {
// ignore request to abort during registration
}
// <rdar://problem/32209809> call 'init' function on all images already init'ed (below libSystem)
for (std::vector<ImageLoader*>::iterator it=sAllImages.begin(); it != sAllImages.end(); it++) {
ImageLoader* image = *it;
if ( (image->getState() == dyld_image_state_initialized) && image->notifyObjC() ) {
dyld3::ScopedTimer timer(DBG_DYLD_TIMING_OBJC_INIT, (uint64_t)image->machHeader(), 0, 0);
(*sNotifyObjCInit)(image->getRealPath(), image->machHeader());
}
}
}
load_images
接下来我们分析一下 registerObjCNotifiers 方法的第二个参数 init，（也就是_dyld_objc_notify_register 方法中的 load_images 参数）方法里面有sNotifyObjCInit = init; 这个赋值语句，接下来我们在 dyld 源码中全局搜索一下 sNotifyObjCInit ，会发现在 notifySingle 方法中有 sNotifyObjCInit 的调用：
(*sNotifyObjCInit)(image->getRealPath(), image->machHeader());
所以在 ObjC 中 _objc_init 方法里调用的 _dyld_objc_notify_register 方法终于在 dyld 源码中找到其真正调用的地方，终于找到了它们真正的关联关系了。
map_images
那么 _dyld_objc_notify_register 方法中的 map_images 参数呢？接下来我们继续找 registerObjCNotifiers 方法中的 sNotifyObjCMapped = mapped; 这一赋值语句，在 dyld 源码中全局搜索一下 sNotifyObjCMapped ，同样会发现在 notifyBatchPartial 方法中有 sNotifyObjCMapped 的调用：
(*sNotifyObjCMapped)(objcImageCount, paths, mhs);
所以说 ObjC 中 _objc_init 方法的调用时离不开 dyld 的，它们之间有着紧密的联系。
我们还可以继续探索一下 map_images， 进入到 objc_781 源码，全局搜索相关的函数调用 map_images ，我们能进入相关的函数调用过程：
void
map_images(unsigned count, const char * const paths[],
const struct mach_header * const mhdrs[])
{
mutex_locker_t lock(runtimeLock);
return map_images_nolock(count, paths, mhdrs);
}
再进入到 map_images_nolock 方法中，我们能发现其中有很多加载相关类的信息 _read_images：
if (hCount > 0) {
_read_images(hList, hCount, totalClasses, unoptimizedTotalClasses);
}
我们知道，map_images 这个函数的主要功能就是为了映射相关的类信息，所以此处才是我们研究的重点，接着进入到相关的类方法的定义 _read_images 方法，顺着源码分析我们能得到很多关于类的信息：
1.条件控制进⾏⼀次的加载
2.修复预编译阶段的 @selector 的混乱问题
3.错误混乱的类处理
4.修复重映射⼀些没有被镜像⽂件加载进来的 类
5.修复⼀些消息!
6.当我们类⾥⾯有协议的时候 : readProtocol
7.修复没有被加载的协议
8.分类处理
9.类的加载处理
10.没有被处理的类 优化那些被侵犯的类
网友评论