main 函数是 iOS 程序的入口，我们写的代码都是在 main 函数之后执行的，但是在夜深人静的时候，我的脑海中经常会冒出这样的问题：main 函数之前到底发生了什么？用户点击程序图标之后，我们的 App 是怎样被启动的？这期间系统做了哪些事情、经历了哪些步骤才一步步地调用到程序 main 函数的？于是我又献祭了自己的空闲时间对 iOS 应用的启动流程进行了一番探究。
调研结论
咳咳，这里先把结论贴出来，然后再一步步分析，对总体流程有了一个大体的认识才不会在技术细节中迷路：
(1) 系统为程序启动做好准备
(2) 系统将控制权交给 Dyld，Dyld 会负责后续的工作
(3) Dyld 加载程序�所需的动态库
(3) Dyld 对程序进行 rebase 以及 bind 操作
(4) Objc SetUp
(5) 运行初始化函数
(6) 执行程序的 main 函数
步骤比较多，不过不用担心，我会结合代码对其进行进一步的讲解。
Dyld
在用户点击应用后，系统内核会去创建一个新的进程并为应用的执行做好准备，详情可参考趣探 Mach-O：加载过程，之后会去调用 Dyld 来接管后续的工作。Dyld 是 iOS 系统的动态链接器，它的代码在这里，整体来说它的机制还是比较复杂的，所里这里只是简单概括一下，感兴趣的同志可以下载源码阅读。
Dyld 的启动代码源于 dyldStartup.s 文件，在一大串的汇编代码中有个名为 __dyld_start 的方法，它会去调用 dyldbootstrap::start() 方法，然后进一步调用 dyld::_main() 方法，里面包含 App 的整个启动流程，该函数最终返回应用程序 main 函数的地址，最后 Dyld 会去调用它。dyld::_main() 函数的源码很长，所以这里只保留关键信息，并用伪代码进行简化从而得到整体流程：
uintptr_t _main(···/省略参数/···) {
// 1. 设置运行环境
......
// 2. instantiate ImageLoader for main executable
sMainExecutable = instantiateFromLoadedImage(mainExecutableMH, mainExecutableSlide, sExecPath);
......
//3. link main executable
link(sMainExecutable, sEnv.DYLD_BIND_AT_LAUNCH, true, ImageLoader::RPathChain(NULL, NULL), -1);
......
//4. run all initializers
initializeMainExecutable();
......
//5. find entry point for main executable
result = (uintptr_t)sMainExecutable->getThreadPC();
......
return result;
}
接下来我会对以上关键代码进行解读，希望大家对启动流程有着更为清晰的认识。�
加载可执行文件
二进制文件常被称为 image，包括可执行文件、动态库等，ImageLoader 的作用就是将二进制文件加载进内存。dyld::_main() 方法在设置好运行环境后，会调用 instantiateFromLoadedImage 函数将可执行文件加载进内存中，加载过程分为三步：
合法性检查。主要是检查可执行文件是否合法，是否能在当前的 CPU 架构下运行。
选择 ImageLoader 加载可执行文件。系统会去判断可执行文件的类型，选择相应的 ImageLoader 将其加载进内存空间中。
注册 image 信息。可执行文件加载完成后，系统会调用 addImage 函数将其管理起来，并更新内存分布信息。
以上三步完成后，Dyld 会调用 link 函数开始之后的处理流程。另外补充下，如果有同学对 ImageLoader 感兴趣的话，dyld 加载 Mach-O这篇文章是不错的，推荐大家看。
Load Dylibs
link(sMainExecutable, ......) 函数究竟做了些什么，我们可以从源码中一探究竟：
void ImageLoader::link(···/省略参数/···) {
//dyld::log("ImageLoader::link(%s) refCount=%d, neverUnload=%d\n", imagePath, fDlopenReferenceCount, fNeverUnload);
// clear error strings
(*context.setErrorStrings)(0, NULL, NULL, NULL);
uint64_t t0 = mach_absolute_time();
this->recursiveLoadLibraries(context, preflightOnly, loaderRPaths, imagePath);
context.notifyBatch(dyld_image_state_dependents_mapped, preflightOnly);
// we only do the loading step for preflights
if ( preflightOnly )
return;
uint64_t t1 = mach_absolute_time();
context.clearAllDepths();
this->recursiveUpdateDepth(context.imageCount());
uint64_t t2 = mach_absolute_time();
this->recursiveRebase(context);
context.notifyBatch(dyld_image_state_rebased, false);
uint64_t t3 = mach_absolute_time();
this->recursiveBind(context, forceLazysBound, neverUnload);
uint64_t t4 = mach_absolute_time();
if ( !context.linkingMainExecutable )
this->weakBind(context);
uint64_t t5 = mach_absolute_time();
context.notifyBatch(dyld_image_state_bound, false);
uint64_t t6 = mach_absolute_time();
std::vector<DOFInfo> dofs;
this->recursiveGetDOFSections(context, dofs);
context.registerDOFs(dofs);
uint64_t t7 = mach_absolute_time();
// interpose any dynamically loaded images
if ( !context.linkingMainExecutable && (fgInterposingTuples.size() != 0) ) {
this->recursiveApplyInterposing(context);
}
// clear error strings
(*context.setErrorStrings)(0, NULL, NULL, NULL);
fgTotalLoadLibrariesTime += t1 - t0;
fgTotalRebaseTime += t3 - t2;
fgTotalBindTime += t4 - t3;
fgTotalWeakBindTime += t5 - t4;
fgTotalDOF += t7 - t6;
// done with initial dylib loads
fgNextPIEDylibAddress = 0;
}
link 函数不是很长，这里就全部贴出来了，它首先调用 recursiveLoadLibraries，递归加载程序所需的动态链接库。使用 otool -L 二进制文件路径 可以列出程序的动态链接库：
$ otool -L gaoda
/System/Library/Frameworks/Foundation.framework/Foundation (compatibility version 300.0.0, current version 1349.55.0)
/usr/lib/libobjc.A.dylib (compatibility version 1.0.0, current version 228.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1238.50.2)
/System/Library/Frameworks/CoreFoundation.framework/CoreFoundation (compatibility version 150.0.0, current version 1349.56.0)
/System/Library/Frameworks/UIKit.framework/UIKit (compatibility version 1.0.0, current version 3600.7.47)
UIKit 和 Foundation 框架相信大家已经很熟悉了，那么 libobjc.A.dylib 以及 libSystem.B.dylib 是什么呢？libobjc.A.dylib 包含 runtime，而 libSystem.B.dylib 则包含像 libdispatch、libsystem_c 等系统级别的库，二者都是被默认添加到程序中的。动态链接库的加载也是借助 ImageLoader 完成的，但是由于动态链接库本身还可能依赖其他动态链接库，所以整个加载过程是递归进行的。当程序的动态链接库加载完毕后，link 函数进入下一流程。
Rebase && Bind
因为地址空间加载随机化(ASLR，Address Space Layout Randomization)的缘故，二进制文件最终的加载地址与预期地址之间会存在偏移，所以需要进行 rebase 操作，对那些指向文件内部符号的指针进行修正，在 link 函数中该项操作由 recursiveRebase 函数执行。rebase 完成之后，就会进行 bind 操作，修正那些指向其他二进制文件所包含的符号的指针，由 recursiveBind 函数执行。
当 rebase 以及 bind 结束时，link 函数就完成了它的使命，iOS 应用的启动流程也进入到下一阶段，即 Objc SetUp。
Objc SetUp
Objc Setup 算是 iOS 系统独有的流程了，在 runtime 的初始化函数 _objc_init 中，有这样的代码：
void _objc_init(void) {
......
// 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 在 bind 操作结束之后，会发出 dyld_image_state_bound 通知，然后与之绑定的回调函数 map_2_images 就会被调用，它主要做以下几件事来完成 Objc Setup：
读取二进制文件的 DATA 段内容，找到与 objc 相关的信息
注册 Objc 类
确保 selector 的唯一性
读取 protocol 以及 category 的信息
除了 map_2_images，我们注意到 _objc_init 还注册了 load_images 函数，它的作用就是调用 Objc 的 + load 方法，它监听 dyld_image_state_dependents_initialized 通知。
虽然我说的很简单，但是在读源码的时候，我发现这部分内容其实是十分复杂而又十分有趣的，鉴于本文主旨是讲启动流程，所以这一块内容先放下，以后有时间了再讲。
Initializers
Objc SetUp 结束后，Dyld 便开始运行程序的初始化函数，该任务由 initializeMainExecutable 函数执行。整个初始化过程是一个递归的过程，顺序是先将依赖的动态库初始化，然后在对自己初始化。初始化需要做的事情包括：
调用 Objc 类的 + load 函数
调用 C++ �中带有 constructor 标记的函数
非基本类型的 C++ 静态全局变量的创建
main
当初始化结束之后，可执行文件才处于可用状态，之后 Dyld 就会去调用可执行文件的 main 函数，开始程序的运行。
结语
同学们还可以开启 DYLD_PRINT_STATISTICS 选项来打印各个阶段的耗时，一般来说400ms以内是很棒的。
关于 iOS 应用启动流程的介绍到此就告一段落了，自己挖的坑总算是填上了，日后如果有了新的发现我会补充上去的，然后嘛，就开始挖新的坑了😳
