1、库&静态库&动态库&dyld
1.1 库
库是已写好的、供使用的可复用代码集合，每个程序都要依赖很多基础的底层库，而且是已经编译好的二进制文件。
从本质上，库是一种可执行代码的二进制形式。可以被操作系统载入内存执行。库分为两种：
静态库（.a .lib）和动态库 （framework .so .dll）。动&静的不同主要区分在链接方式：
动态链接、静态链接
1.2 静态库
- 使用
静态链接:链接时会被完整的复制到可执行文件中去，所以如果两个进程（程序）都使用了某个静态库，则这两个进程中都需要包含这份静态库的代码。而且链接时机在编译时期; -
静态库:在编译时链接的库，需要链接到mach-O文件中去，如果需要更新则需要重新编译。 -
优点：加载快；缺点：会增加程序体积，更新需要重新编译
静态库
1.3 动态库
-
动态链接:链接时不复制，程序运行时由系统动态的添加到内存中供程序使用，系统只会添加一次，多个程序公用。 -
动态库:在运行时链接的库，使用dyld动态链接器完成链接。并没有参与mach-O的编译。 -
优点：不增加程序体积；缺点：动态链接是一个耗时的操作
动态库
1.4 dyld动态链接器
dyld（the dynamic link editor）:【动态链接器】是苹果操作系统一个重要部分，在 iOS / macOS 系统中，仅有很少的进程只需内核就可以完成加载，基本上所有的进程都是动态链接的，所以 Mach-O 镜像文件中会有很多对外部的库和符号的引用，但是这些引用并不能直接用，在启动时还必须要通过这些引用进行内容填充，这个填充的工作就是由 dyld 来完成的。
2、应用程序加载流程
库&静态库&动态库&dyld分别了解后，需要对整个流程有个认识。
应用程序编译过程.png
3、APP启动加载流程
在任意+(void)load方法中打下断点。
启动入口
- 根据堆栈信息得知：程序加载的第一步就是
dyld的_dydl_start函数，通过下载dyld-源码来进一步探索。
3.1 _dyld_start函数
_dyld_start
- 会有不同的硬件架构对于的处理，最终指向这个
dyldbootstrap::start函数
3.2 start函数
源文件-预编译-编译-汇编-链接-可执行文件 - dyld加载
链接： dyld链接器 - 动静态库（加载UIkit、FOunation库、libSystem） -读到 内存（表）-加载主程序中 -link（链接主程序-链接动态库）-库的初始化- main（）
start
3.3 dyld::main函数
这就是dyld最重要的方法。
uintptr_t
_main(const macho_header* mainExecutableMH, uintptr_t mainExecutableSlide,
int argc, const char* argv[], const char* envp[], const char* apple[],
uintptr_t* startGlue)
{
......
// 第一步、设置运行环境，可执行文件准备工作
......
// 第二步、 加载共享缓存(已经加载到内存中的动态库无需再次加载，如：UIKit、Founation等)
//load shared cache
mapSharedCache();
......
reloadAllImages:
......
// 第三步、 加载可主执行文件并生成一个ImageLoader实例对象
// instantiate ImageLoader for main executable
sMainExecutable = instantiateFromLoadedImage(mainExecutableMH, mainExecutableSlide, sExecPath);
......
// 第四步、 加载插入的动态库
// load any inserted libraries
if ( sEnv.DYLD_INSERT_LIBRARIES != NULL ) {
for (const char* const* lib = sEnv.DYLD_INSERT_LIBRARIES; *lib != NULL; ++lib)
loadInsertedDylib(*lib);
}
// 第五步、 链接主程序
// link main executable
link(sMainExecutable, sEnv.DYLD_BIND_AT_LAUNCH, true, ImageLoader::RPathChain(NULL, NULL), -1);
......
// 第六步、 链接所有插入的动态库
// link any inserted libraries
if ( sInsertedDylibCount > 0 ) {
for(unsigned int i=0; i < sInsertedDylibCount; ++i) {
ImageLoader* image = sAllImages[i+1];
link(image, sEnv.DYLD_BIND_AT_LAUNCH, true, ImageLoader::RPathChain(NULL, NULL), -1);
image->setNeverUnloadRecursive();
}
if ( gLinkContext.allowInterposing ) {
for(unsigned int i=0; i < sInsertedDylibCount; ++i) {
ImageLoader* image = sAllImages[i+1];
// 注册符号插入
image->registerInterposing(gLinkContext);
}
}
}
......
// 第七步、 弱符号绑定
sMainExecutable->weakBind(gLinkContext);
sMainExecutable->recursiveMakeDataReadOnly(gLinkContext);
......
// 第八步、 执行初始化方法
// run all initializers
initializeMainExecutable();
// 第九步、 main()调用
// enter main()
notifyMonitoringDyldMain();
return result;
}
由于方法实在过长就简练最重要步骤，有兴趣的同学可以去dyld源码中一探究竟。
3.4 第八步initializeMainExecutable
重点函数，需要单独进行分析：
3.4.1 ImageLoader::runInitializers
3.4.2 ImageLoader::processInitializers
- 虽然该方法中循环只执行一次，但是processInitializers会有
递归调用存在。
3.4.3 ImageLoader::recursiveInitialization
- 需要重点关注2个函数：
notifySingledoInitialization
3.5 notifySingle函数
- 在dyld中出现了
Objc...,就一定不简单 -
(*sNotifyObjCInit)(image->getRealPath(), image->machHeader());传入镜像文件的真实地址进行sNotifyObjCInit调用（所有类的load方法的调用）。
3.5.1 sNotifyObjCInit赋值
- sNotifyObjCInit在该方法中进行了赋值
3.5.2 registerObjCNotifiers调用
-
_dyld_objc_notify_register这个方法一定不陌生。
3.5.3 _objc_init
_objc_init
- 第二个参数：就是所有类的load方法调用
3.5.4 load_image
void
load_images(const char *path __unused, const struct mach_header *mh)
{
// Call +load methods (without runtimeLock - re-entrant)
call_load_methods();
}
void call_load_methods(void)
{
do {
// 1. Repeatedly call class +loads until there aren't any more
while (loadable_classes_used > 0) {
call_class_loads();
}
// 2. Call category +loads ONCE
more_categories = call_category_loads();
// 3. Run more +loads if there are classes OR more untried categories
} while (loadable_classes_used > 0 || more_categories);
}
static void call_class_loads(void)
{
int i;
// Call all +loads for the detached list.
for (i = 0; i < used; i++) {
Class cls = classes[i].cls;
load_method_t load_method = (load_method_t)classes[i].method;
(*load_method)(cls, @selector(load));
}
}
- 通过一系列的调用后，通过循环完成所有
类load方法的函数调用。
3.5 小结
在runtime的初始化方法_objc_init中，将所有类load方法的注册到了dyld中等待dyld的调用。也就是说：所有类load方法调用是等：libobjc库加载完成后进行的。
3.6 doInitialization函数
3.5中提到了libobjc初始化时注册了所有类load方法,这一步就是libobjc初始化_objc_init调用的地方
- 在第一步中完成了
所有动态库的init调用 - 在第二步中完成了
所有c++函数的调用
3.7 main()
执行完dyld_start的所有函数之后，就会来到程序的入口main()函数
验证一下：
4、_objc_init调用时机
在3.5中提到了_objc_init中做了部分处理，只知道是在3.6 -doInitialization函数调用的,具体的调用时机需要在可执行的objc源码打下一个符号断定_objc_init。
4.1 libSystem库
libSystem-init
- 不但完成自己的初始化，还调起了
dyld、pthread、libdisPatch等库 libSystem库是第一个初始化的库
4.2 libdispatch库
- 最终调起
_objc_init函数;
5、 总结
- 本文从
动&静态库到dyld，着重分析了dyld通过9个步骤完成了APP的启动；期间对第八步initializeMainExecutable做了详细的分析；也分析了类的load方法是在dyld的完成调用的；同时也对libSystem、libDispatch、libObjc的依次调用做了分析；最后还通过源码分析了load方法、C++方法、main()的调用时机。 - 其实这只是
dyld的冰山一角，希望以后有机会可以更加深入。
最后求个赞，不过分吧~~~
