上篇应用程序加载之dydl的流程探究了系统启动应用的以及使用
dyld
动态链接器的过程,也提高了libObjc
的初始化,以及在libObjc
注册的回调函数map_images
和load_images
。load_images
在已经讲了它的调用时机,所以本篇先看一下map_images
在dyld
的调用时机,再着重分析map_images
作了哪些事情
0x00 - _objc_init
源码解析
/***********************************************************************
* _objc_init
* Bootstrap initialization. Registers our image notifier with dyld.
* Called by libSystem BEFORE library initialization time
**********************************************************************/
void _objc_init(void)
{
static bool initialized = false;
if (initialized) return;
initialized = true;
// fixme defer initialization until an objc-using image is found?
//读取影响运行时的环境变量,如果需要,还可以打开环境变量帮助 export OBJC_HELP = 1
environ_init();
//关于线程key的绑定,例如线程数据的析构函数
tls_init();
//运行C++静态构造函数,在dyld调用我们的静态析构函数之前,libc会调用_objc_init(),因此我们必须自己做
static_init();
//runtime运行时环境初始化,里面主要是unattachedCategories、allocatedClasses -- 分类初始化
runtime_init();
//初始化libobjc的异常处理系统
exception_init();
//缓存条件初始化
cache_init();
//启动回调机制,通常这不会做什么,因为所有的初始化都是惰性的,但是对于某些进程,我们会迫不及待地加载trampolines dylib
_imp_implementationWithBlock_init();
/*
_dyld_objc_notify_register -- dyld 注册的地方
- 仅供objc运行时使用
- 注册处理程序,以便在映射、取消映射 和初始化objc镜像文件时使用,dyld将使用包含objc_image_info的镜像文件数组,回调 mapped 函数
map_images:dyld将image镜像文件加载进内存时,会触发该函数
load_images:dyld初始化image会触发该函数
unmap_image:dyld将image移除时会触发该函数
*/
_dyld_objc_notify_register(&map_images, load_images, unmap_image);
#if __OBJC2__
didCallDyldNotifyRegister = true;
#endif
}
下面简约的分析一下每一个函数:
environ_init();
初始化环境变量,系统也监听我们设置的环境变量
void environ_init(void)
{
//...省略部分逻辑
if (PrintHelp || PrintOptions) {
//...省略部分逻辑
for (size_t i = 0; i < sizeof(Settings)/sizeof(Settings[0]); i++) {
const option_t *opt = &Settings[i];
if (PrintHelp) _objc_inform("%s: %s", opt->env, opt->help);
if (PrintOptions && *opt->var) _objc_inform("%s is set", opt->env);
}
}
}
通过这个函数,可以打印系统环境变量,方法有二
- 把条件里的
for
循环放到外边打印
- 通过
终端
使用export OBJC_HELP=1
也可以打印出来所有的环境变量
这些环境变量可以通过Xcode
的Edit Scheme
里的Environment variables
配置,常用有以下几个:
DYLD_PRINT_STATISTICS
:设置DYLD_PRINT_STATISTICS
为YES
,会打印App
在main
函数前的加载时长,包括整体加载时长和动态库的时长,通过这个环境可以查看耗时,对其耗时分析进行优化。
OBJC_PRINT_LOAD_METHODS
:打印class
及Category
的load
方法
OBJC_DISABLE_NONPOINTER_ISA
:禁止对象生成nonpointer isa
,通过之前的文章可以了解isa
,isa
末尾为1
,生成普通对象(即isa
末尾是0)
通过设置OBJC_DISABLE_NONPOINTER_ISA
为YES
,看isa
末尾是0
正常未设置OBJC_DISABLE_NONPOINTER_ISA
环境, isa
末尾是1
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
/***********************************************************************
* static_init
* Run C++ static constructor functions.
* libc calls _objc_init() before dyld would call our static constructors,
* so we have to do it ourselves.
**********************************************************************/
static void static_init()
{
size_t count;
auto inits = getLibobjcInitializers(&_mh_dylib_header, &count);
for (size_t i = 0; i < count; i++) {
inits[i]();
}
}
这里会运行系统级别的
C++
的静态构造函数,在dyld
调用我们的静态构造函数之前,libObjc
会调用_objc_init
,所以这里我们必须自己来做,并且这里只会初始化系统内置的C++
静态构造函数,我们自己代码里面写的并不会在这里初始化。
runtime_init
void runtime_init(void)
{
objc::unattachedCategories.init(32); //分类处理初始化
objc::allocatedClasses.init(); // 类初始化表
}
runtime运行时环境初始化,里面主要是俩部分
unattachedCategories
分类初始化
allocatedClasses
类的存储表初始化
exception_init
/***********************************************************************
* exception_init
* Initialize libobjc's exception handling system.
* Called by map_images().
**********************************************************************/
void exception_init(void)
{
old_terminate = std::set_terminate(&_objc_terminate);//crash 违反系统规定,系统给app的一些信号 , 中断
}
主要
libOjbc
异常处理系统初始化,程序中触发的异常都会来到这里,执行异常回调
当程序有Crash
发生时, 程序中的Crash
是指违背了系统的一些指令,然后OS
执行中断,会来到_objc_terminate
, 抛出异常给到程序处理。
/***********************************************************************
* _objc_terminate
* Custom std::terminate handler.
*
* The uncaught exception callback is implemented as a std::terminate handler.
* 1. Check if there's an active exception
* 2. If so, check if it's an Objective-C exception
* 3. If so, call our registered callback with the object.
* 4. Finally, call the previous terminate handler.
**********************************************************************/
static void (*old_terminate)(void) = nil;
static void _objc_terminate(void)
{
if (PrintExceptions) {
_objc_inform("EXCEPTIONS: terminating");
}
if (! __cxa_current_exception_type()) {
// No current exception.
(*old_terminate)();
}
else {
// There is a current exception. Check if it's an objc exception.
@try {
__cxa_rethrow();
} @catch (id e) {
// It's an objc object. Call Foundation's handler, if any.
(*uncaught_handler)((id)e);
(*old_terminate)();
} @catch (...) {
// It's not an objc object. Continue to C++ terminate.
(*old_terminate)();
}
}
}
发生异常会走到uncaught_handler
,通过搜索看到这写内容
/***********************************************************************
* _objc_default_uncaught_exception_handler
* Default uncaught exception handler. Expected to be overridden by Foundation.
**********************************************************************/
static void _objc_default_uncaught_exception_handler(id exception)
{
}
static objc_uncaught_exception_handler uncaught_handler = _objc_default_uncaught_exception_handler;
/***********************************************************************
* objc_setUncaughtExceptionHandler
* Set a handler for uncaught Objective-C exceptions.
* Returns the previous handler.
**********************************************************************/
objc_uncaught_exception_handler
objc_setUncaughtExceptionHandler(objc_uncaught_exception_handler fn)
{
objc_uncaught_exception_handler result = uncaught_handler;
uncaught_handler = fn;//fn为设置的异常句柄 传入的函数,为外界给的
return result;
}
如果没有设置uncaught_handler
,默认就为_objc_default_uncaught_exception_handler
,什么也不做处理。
也可以通过objc_setUncaughtExceptionHandler
传一个自定义函数fn
设置给uncaught_handler
,发生异常就可以回调到我们自己的函数中作处理了。
针对日常App
开发中的Crash
,可以通过NSSetUncaughtExceptionHandler
机制来设置异常,实现线程保活, 手机上传崩溃日志。
应用程序Crash
捕获
- (void)_caughtException
{
// NSException
// objc_uncaught_exception_handler
// objc_setUncaughtExceptionHandler(objc_uncaught_exception_handler fn)
NSSetUncaughtExceptionHandler(HandleNSException);
}
void HandleNSException(NSException *exception)
{
__unused NSString *reason = exception.reason;
__unused NSString *name = exception.name;
//存储crash信息。
}
cache_init
void cache_init()
{
#if HAVE_TASK_RESTARTABLE_RANGES
mach_msg_type_number_t count = 0;
kern_return_t kr;
while (objc_restartableRanges[count].location) {
count++;
}
//为当前任务注册一组可重新启动的缓存
kr = task_restartable_ranges_register(mach_task_self(),
objc_restartableRanges, count);
if (kr == KERN_SUCCESS) return;
_objc_fatal("task_restartable_ranges_register failed (result 0x%x: %s)",
kr, mach_error_string(kr));
#endif // HAVE_TASK_RESTARTABLE_RANGES
}
主要是做一些缓存初始化
_imp_implementationWithBlock_init
启动回调机制
void
_imp_implementationWithBlock_init(void)
{
#if TARGET_OS_OSX
// Eagerly load libobjc-trampolines.dylib in certain processes. Some
// programs (most notably QtWebEngineProcess used by older versions of
// embedded Chromium) enable a highly restrictive sandbox profile which
// blocks access to that dylib. If anything calls
// imp_implementationWithBlock (as AppKit has started doing) then we'll
// crash trying to load it. Loading it here sets it up before the sandbox
// profile is enabled and blocks it.
// 在某些进程中渴望加载libobjc-trampolines.dylib。一些程序(最著名的是嵌入式Chromium的较早版本使用的QtWebEngineProcess)启用了严格限制的沙箱配置文件,从而阻止了对该dylib的访问。如果有任何调用imp_implementationWithBlock的操作(如AppKit开始执行的操作),那么我们将在尝试加载它时崩溃。将其加载到此处可在启用沙箱配置文件之前对其进行设置并阻止它。
// This fixes EA Origin (rdar://problem/50813789)
// and Steam (rdar://problem/55286131)
if (__progname &&
(strcmp(__progname, "QtWebEngineProcess") == 0 ||
strcmp(__progname, "Steam Helper") == 0)) {
Trampolines.Initialize();
}
#endif
}
该方法主要是
启动回调机制
,通常这不会做什么,因为所有的初始化都是惰性的,但是对于某些进程,我们会迫不及待地加载libobjc-trampolines.dylib
_dyld_objc_notify_register
dyld
注册回调函数
//
// Note: only for use by objc runtime
// Register handlers to be called when objc images are mapped, unmapped, and initialized.
// Dyld will call back the "mapped" function with an array of images that contain an objc-image-info section.
// Those images that are dylibs will have the ref-counts automatically bumped, so objc will no longer need to
// call dlopen() on them to keep them from being unloaded. During the call to _dyld_objc_notify_register(),
// dyld will call the "mapped" function with already loaded objc images. During any later dlopen() call,
// dyld will also call the "mapped" function. Dyld will call the "init" function when dyld would be called
// initializers in that image. This is when objc calls any +load methods in that image.
// 仅供objc运行时使用
// 注册处理程序,以便在映射、取消映射和初始化objc图像时调用
// dyld将会通过一个包含objc-image-info的镜像文件的数组回调mapped函数
void _dyld_objc_notify_register(_dyld_objc_notify_mapped mapped,
_dyld_objc_notify_init init,
_dyld_objc_notify_unmapped unmapped);
_dyld_objc_notify_register(&map_images, load_images, unmap_image);
map_images
:dyld将image(镜像文件)加载进内存时,会触发该函数load_images
: dyld初始化image会触发该函数unmap_image
: dyld将image移除时,会触发该函数
在上一篇应用程序加载之dydl的流程中,我们知道了load_images
是在notifySingle
方法中, 通过sNotifyObjCInit
调用的,如下所示:
map_images
调用时机
在dyld
中,全局搜索sNotifyObjcMapped
,
搜索notifyBatchPartial
,
也就是说,map_images
的调用时机比load_images
要提前,即先map_images
,再load_images
环境变量说明
环境变量名 | 说明 |
---|---|
OBJC_PRINT_OPTIONS | 输出OBJC已设置的选项 |
OBJC_PRINT_IMAGES | 输出已load的image信息 |
OBJC_PRINT_LOAD_METHODS | 打印 Class 及 Category 的 + (void)load 方法的调用信息 |
OBJC_PRINT_INITIALIZE_METHODS | 打印 Class 的 + (void)initialize 的调用信息 |
OBJC_PRINT_RESOLVED_METHODS | 打印通过 +resolveClassMethod: 或 +resolveInstanceMethod: 生成的类方法 |
OBJC_PRINT_CLASS_SETUP | 打印 Class 及 Category 的设置过程 |
OBJC_PRINT_PROTOCOL_SETUP | 打印 Protocol 的设置过程 |
OBJC_PRINT_IVAR_SETUP | 打印 Ivar 的设置过程 |
OBJC_PRINT_VTABLE_SETUP | 打印 vtable 的设置过程 |
OBJC_PRINT_VTABLE_IMAGES | 打印 vtable 被覆盖的方法 |
OBJC_PRINT_CACHE_SETUP | 打印方法缓存的设置过程 |
OBJC_PRINT_FUTURE_CLASSES | 打印从 CFType 无缝转换到 NSObject 将要使用的类(如 CFArrayRef 到 NSArray * ) |
OBJC_PRINT_GC | 打印一些垃圾回收操作 |
OBJC_PRINT_PREOPTIMIZATION | 打印 dyld 共享缓存优化前的问候语 |
OBJC_PRINT_CXX_CTORS | 打印类实例中的 C++ 对象的构造与析构调用 |
OBJC_PRINT_EXCEPTIONS | 打印异常处理 |
OBJC_PRINT_EXCEPTION_THROW | 打印所有异常抛出时的 Backtrace |
OBJC_PRINT_ALT_HANDLERS | 打印 alt 操作异常处理 |
OBJC_PRINT_REPLACED_METHODS | 打印被 Category 替换的方法 |
OBJC_PRINT_DEPRECATION_WARNINGS | 打印所有过时的方法调用 |
OBJC_PRINT_POOL_HIGHWATER | 打印 autoreleasepool 高水位警告 |
OBJC_PRINT_CUSTOM_RR | 打印含有未优化的自定义 retain/release 方法的类 |
OBJC_PRINT_CUSTOM_AWZ | 打印含有未优化的自定义 allocWithZone 方法的类 |
OBJC_PRINT_RAW_ISA | 打印需要访问原始 isa 指针的类 |
OBJC_DEBUG_UNLOAD | 卸载有不良行为的 Bundle 时打印警告 |
OBJC_DEBUG_FRAGILE_SUPERCLASSES | 当子类可能被对父类的修改破坏时打印警告 |
OBJC_DEBUG_FINALIZERS | 警告实现了 -dealloc 却没有实现 -finalize 的类 |
OBJC_DEBUG_NIL_SYNC | 警告 @synchronized(nil) 调用,这种情况不会加锁 |
OBJC_DEBUG_NONFRAGILE_IVARS | 打印突发地重新布置 non-fragile ivars 的行为 |
OBJC_DEBUG_ALT_HANDLERS | 记录更多的 alt 操作错误信息 |
OBJC_DEBUG_MISSING_POOLS | 警告没有 pool 的情况下使用 autorelease,可能内存泄漏 |
OBJC_DEBUG_DUPLICATE_CLASSES | 当出现类重名时停机 |
OBJC_USE_INTERNAL_ZONE | 在一个专用的 malloc 区分配运行时数据 |
OBJC_DISABLE_GC | 强行关闭自动垃圾回收,即使可执行文件需要垃圾回收 |
OBJC_DISABLE_VTABLES | 关闭 vtable 分发 |
OBJC_DISABLE_PREOPTIMIZATION | 关闭 dyld 共享缓存优化前的问候语 |
OBJC_DISABLE_TAGGED_POINTERS | 关闭 NSNumber 等的 tagged pointer 优化 |
OBJC_DISABLE_NONPOINTER_ISA | 关闭 non-pointer isa 字段的访问 |