转：iOS程序main函数之前发生了什么

移动开发作者： 2024-08-24 18:05:01

原文地址：http://blog.sunnyxx.com/2014/08/30/objc-pre-main/ 我是前言一个iOS app的main()函数位于main.m中，这是我们熟知的程序入口。

我是前言

从dyld开始

这些framework将会在动态链接过程中被加载，另外还有隐含link的framework，可以测试出来：先找到可执行文件，我这里叫TestMain的工程，模拟器路径下找到TestMain.app，可执行文件默认同名，再通过otool命令：

1	$ otool -L TestMain

TestMain:
    /System/Library/Frameworks/CoreGraphics.framework/CoreGraphics 
    /System/Library/Frameworks/UIKit.framework/UIKit
    /System/Library/Frameworks/Foundation.framework/Foundation
    /System/Library/Frameworks/CoreFoundation.framework/CoreFoundation 
    /usr/lib/libobjc.A.dylib 
    /usr/lib/libSystem.dylib

代码共用：很多程序都动态链接了这些lib，但它们在内存和磁盘中中只有一份
易于维护：由于被依赖的lib是程序执行时才link的，所以这些lib很容易做更新，比如libSystem.dylib是libSystem.B.dylib的替身，哪天想升级直接换成libSystem.C.dylib然后再替换替身就行了
减少可执行文件体积：相比静态链接，可执行文件的体积要小很多

从kernel留下的原始调用栈引导和启动自己
将程序依赖的动态链接库递归加载进内存，当然这里有缓存机制
non-lazy符号立即link到可执行文件，lazy的存表里
Runs static initializers for the executable
找到可执行文件的main函数，准备参数并调用
程序执行中负责绑定lazy符号、提供runtime dynamic loading services、提供调试器接口
程序main函数return后执行static terminator
某些场景下main函数结束后调libSystem的_exit函数

调用dyldbootstrap::start()方法（省去参数）
上个方法返回了main函数地址，填入参数并调用main函数

这个函数是runtime的初始化函数，后面会提到。程序运行在很早的时候断住，这时候看调用栈：

看到了栈底的dyldbootstrap::start()方法，继而调用了dyld::_main()方法，其中完成了刚才说的递归加载动态库过程，由于libSystem默认引入，栈中出现了libSystem_initializer的初始化方法。

在程序运行时它先将动态链接的image递归加载（也就是上面测试栈中一串的递归调用的时刻）
再从可执行文件image递归加载所有符号

runtime与+load

1
2
3

dyld_register_image_state_change_handler(dyld_image_state_bound,1/*batch*/,&map_images);
dyld_register_image_state_change_handler(dyld_image_state_dependents_initialized,0/*not batch*/,&load_images);

dyld开始将程序二进制文件初始化
交由ImageLoader读取image，其中包含了我们的类、方法等各种符号
由于runtime向dyld绑定了回调，当image加载到内存后，dyld会通知runtime进行处理
runtime接手后调用map_images做解析和处理，接下来load_images中调用call_load_methods方法，遍历所有加载进来的Class，按继承层级依次调用Class的load方法和其Category的load方法