OC底层探索16 -应用程序加载
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
分别了解后,需要对整个流程有个认识。
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个函数:
notifySingle
doInitialization
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的冰山一角
,希望以后有机会可以更加深入。
最后求个赞,不过分吧~~~