静态库(.a .lib)
和 动态库 (framework .so .dll)
。动态链接
、静态链接
静态链接
:链接时会被完整的复制到可执行文件中去,所以如果两个进程(程序)都使用了某个静态库,则这两个进程中都需要包含这份静态库的代码。而且链接时机在编译时期
;静态库
:在编译时链接
的库,需要链接到mach-O
文件中去,如果需要更新则需要重新编译。静态库
动态链接
:链接时不复制,程序运行时由系统动态的添加到内存中供程序使用,系统只会添加一次,多个程序公用。动态库
:在运行时链接
的库,使用dyld动态链接器
完成链接。并没有参与mach-O
的编译。动态库
dyld(the dynamic link editor):【动态链接器】是苹果操作系统一个重要部分,在 iOS / macOS 系统中,仅有很少的进程只需内核就可以完成加载,基本上所有的进程都是动态链接的,所以 Mach-O 镜像文件中会有很多对外部的库和符号的引用,但是这些引用并不能直接用,在启动时还必须要通过这些引用进行内容填充,这个填充的工作就是由 dyld 来完成的。
库&静态库&动态库&dyld
分别了解后,需要对整个流程有个认识。
应用程序编译过程.png
在任意+(void)load
方法中打下断点。
启动入口
dyld
的_dydl_start函数
,通过下载dyld-源码来进一步探索。_dyld_start
dyldbootstrap::start
函数源文件-预编译-编译-汇编-链接-可执行文件 - dyld加载 链接: dyld链接器 - 动静态库(加载UIkit、FOunation库、libSystem) -读到 内存(表)-加载主程序中 -link(链接主程序-链接动态库)-库的初始化- main()
start
这就是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源码中一探究竟。
重点函数
,需要单独进行分析:
递归调用
存在。notifySingle
doInitialization
Objc...
,就一定不简单(*sNotifyObjCInit)(image->getRealPath(), image->machHeader());
传入镜像文件的真实地址进行sNotifyObjCInit调用(所有类的load方法的调用)。_dyld_objc_notify_register
这个方法一定不陌生。_objc_init
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方法
的函数调用
。在runtime的初始化方法_objc_init
中,将所有类load方法
的注册到了dyld中等待dyld的调用
。也就是说:所有类load方法调用是等:libobjc库加载完成后进行的。
3.5中提到了libobjc初始化时注册了所有类load方法
,这一步就是libobjc初始化_objc_init
调用的地方
所有动态库的init调用
所有c++函数的调用
执行完dyld_start
的所有函数之后,就会来到程序的入口main()
函数
验证一下:
在3.5中提到了_objc_init中做了部分处理,只知道是在3.6 -doInitialization函数
调用的,具体的调用时机需要在可执行的objc源码
打下一个符号断定_objc_init
。
libSystem-init
dyld
、pthread
、libdisPatch
等库libSystem库是第一个初始化的库
_objc_init
函数;动&静态库
到dyld
,着重分析了dyld
通过9个步骤完成了APP的启动;期间对第八步initializeMainExecutable
做了详细的分析;也分析了类的load方法
是在dyld
的完成调用的;同时也对libSystem
、libDispatch
、libObjc
的依次调用做了分析;最后还通过源码分析了load方法
、C++方法
、main()
的调用时机。dyld的冰山一角
,希望以后有机会可以更加深入。最后求个赞,不过分吧~~~