Hello World背后的逻辑

一门语言的开发入门，总是抬手就能整出一个「Hello World Demo」。比如下面这样：

显然，熟悉 iOS 开发的同学都知道，上面这个来自 Objective-C。

今天，我们就从这熟悉的代码入手，来一起研究研究「Hello World」出世的整个过程。

main 函数

众说周知，main 函数是我们程序的入口，我们不妨从此入手，开始我们的表演。

入手的姿势已经确定，甩手一个断点，拿到下图：

显然，在main函数执行之前，先是调用了start方法，那这个所谓的start方法又是什么呢？哪里来的呢？又是怎么调起来的呢？

从上图我们并不看的很真切，因+ (void)load {}方法的调用是在加载阶段（后面验证），而加载完之后才触发main函数的调用，所以我们在load方法时候再加上一个断点(这里可以随便弄个类，重写load方法)，看看究竟。

+load方法

再次运行代码之后很容易先确认前面提到的「load 方法调用在 main 调用前」，并拿到下面的调用堆栈（bt命令可打印更详细的堆栈信息）：

从上图我们可以清楚的看到一切的开始源于一堆dyld的东西，那么，dyld是个啥？

dyld（全名 the dynamic link editor）是苹果的动态链接器，用来链接所有的库和可执行文件，是苹果操作系统一个重要组成部分，在系统内核做好程序准备工作之后，交由 dyld 负责余下的工作。它的代码也是开源的，正常可以从这里下载

！！注意：网上有很多关于dyld执行流程的介绍，但都是基于稍老的一些版本，可以看到上面的堆栈信息与老版本的也有些许差异，但是总体流程上基本一致，这里介绍基于最新的dyld4版本，源码可从这里下载

我们接着说，在dyld做完加载库、可执行文件等一系列准备工作之后，通过dyld4::RuntimeState::notifyObjCInit 触发libobjc.A.dylib中的load_images函数，再到我们自定义的[Person load]方法的调用，最终到在之后的main函数。

此话怎么讲呢？iOS开发者对notify这样的字眼是不是有些熟悉？对的，通知！还是通知的触发，上面的过程很显然就是dyld触发通知到注册通知的接收方，哪里呢？libobjc.A.dylib中的load_images函数，这个库其实就是我们常念叨的Runtime。Runtime的代码也是在官方的开源库中，所以我们接下来可以直接验证一下我们的猜想。Runtime源码这里下载

这里额外说明一下，Runtime源码是可以运行起来的，当然需要一堆配置，这里提供一个可以直接跑起来的源码，在这里，下载下来之后，Target 选择KCObjcBuild就可以，源码中直接Debug，不要太爽。

load_images函数

哦了，接着说，我们怎么验证呢？直接在Runtime源码中直接搜索load_images，很容易定位到下面这里：

显然是load_images定义的地方，直接甩一断点验证看看，（源码直接编译优势凸显）：

这里调用的堆栈信息，很显然符合我们的猜想。

继续，是通知就该有注册的地方，不然怎么就能调用到上面的load_images函数呢？前面搜索load_images的时候其实就有这么个地儿：

上图中我们看到了什么呢？是的，_dyld_objc_notify_register，盲猜一下，应该就是通知的注册地了吧。

既然如此，我们知道要想实现上面的调用过程，那么，通知的注册应该要在调用触发之前，不然可说不过去，来来来，接着验证，甩手一个断点（就问源码直接debug爽还是爽？）：

果然如此吧，甚至上面的堆栈信息直接能看出来_objc_init的调用过程，算是意外之喜了。

_objc_init函数

_objc_init的调用过程，从上面的堆栈信息可以看到：

-> dyld`start 
-> dyld`dyld4::prepare() 
-> dyld`dyld4::APIs::runAllInitializersForMain() 
-> dyld`dyld4::Loader::findAndRunAllInitializers() 
-> dyld`dyld3::MachOAnalyzer::forEachInitializer() 
-> dyld`dyld3::MachOFile::forEachSection() const 
-> dyld`dyld3::MachOFile::forEachLoadCommand() 
-> dyld3::MachOFile::forEachSection() 
-> dyld3::MachOAnalyzer::forEachInitializer() 
-> dyld4::Loader::findAndRunAllInitializers() 
-> libSystem.B.dylib`libSystem_initializer 
-> libdispatch.dylib`libdispatch_init 
-> libdispatch.dylib`_os_object_init 
-> libobjc.A.dylib`_objc_init  
复制代码

dyld相关的函数在dyld开源库中，前面已经提到了，这里。

libSystem.B.dylib的相关代码在官方的开源库中能直接拿到，这里。

libdispatch.dylib相关的代码也在官方的开源库中能查询到，这里。

而libobjc.A.dylib就是上面提到的Runtime代码了，这里

运行轨迹

截止目前，我们大致了解了main函数调用的基本逻辑：

dyld的start开始 -> _objc_init函数加载（注册了load_images） -> 触发load_images函数 -> 触发+load方法 -> 在最后才调用main函数 -> 最终输出Hello World

可见，在main函数调用之前，确实还是有一大堆我们并没有意识到的操作，大部分是dyld在处理，我们姑且称之为--加载过程。

但是main函数究竟是怎么被唤起的呢？目前看着仍旧不是很明朗，还是要继续撸源码，那块儿的源码呢？从前面的堆栈来看，还是要从dyld的start跟prepare入手。

dyld唤起main函数

我们可以在dyld源码中全局搜索prepare(，最终找到能这个地方：

而这里正好是start函数的内部调用，符合我们前面的堆栈信息，地方应该可以确认了，没跑了。

其实从这里我们就可以在此大胆假设，然后去小心求证了：

// load all dependents of program and bind them together
MainFunc appMain = prepare(state, dyldMA);

// now make all dyld Allocated data structures read-only
state.decWritable();

// call main() and if it returns, call exit() with the result
// Note: this is organized so that a backtrace in a program's main thread shows just "start" below "main"
int result = appMain(state.config.process.argc, state.config.process.argv, state.config.process.envp, state.config.process.apple);
复制代码

从上面的命名及注释，很容易看到：prepare()主要就是处理main函数调用前的准备工作，比如加载所有的dependents，最终返回的就是main函数的入口（MainFunc类型），而后的appMain()实际上就是对main函数的调用了，我们可以看到其参数就跟我们main的参数神似了。

上面的这些，我们如果深入prepare()就会进一步得到验证，截取部分代码如下：

...
    // run all initializers
    state.runAllInitializersForMain();

    // notify we are about to call main
    notifyMonitoringDyldMain();
    if ( dyld3::kdebug_trace_dyld_enabled(DBG_DYLD_TIMING_LAUNCH_EXECUTABLE) ) {
        dyld3::kdebug_trace_dyld_duration_end(launchTraceID, DBG_DYLD_TIMING_LAUNCH_EXECUTABLE, 0, 0, 4);
    }
    ARIADNEDBG_CODE(220, 1);

    MainFunc result;
    if ( state.config.security.skipMain ) {
        return &fake_main;
    }
    else if ( state.config.process.platform == dyld3::Platform::driverKit ) {
        result = state.mainFunc();
        if ( result == 0 )
            halt("DriverKit main entry point not set");
#if __has_feature(ptrauth_calls)
        // HACK: DriverKit signs the pointer with a diversity different than dyld expects when calling the pointer.
        result = (MainFunc)__builtin_ptrauth_strip((void*)result, ptrauth_key_function_pointer);
        result = (MainFunc)__builtin_ptrauth_sign_unauthenticated((void*)result, 0, 0);
#endif
    }
    else {
        // find entry point for main executable
        uint64_t entryOffset;
        bool     usesCRT;
        if ( !state.config.process.mainExecutable->getEntry(entryOffset, usesCRT) )
            halt("main executable has no entry point");
        result = (MainFunc)((uintptr_t)state.config.process.mainExecutable + entryOffset);
        if ( usesCRT ) {
            // main executable uses LC_UNIXTHREAD, dyld needs to cut back kernel arg stack and jump to "start"
#if SUPPPORT_PRE_LC_MAIN
            // backsolve for KernelArgs (original stack entry point in _dyld_start)
            const KernelArgs* kernArgs = (KernelArgs*)(&state.config.process.argv[-2]);
            gotoAppStart((uintptr_t)result, kernArgs);
#else
            halt("main executable is missing LC_MAIN");
#endif
        }
#if __has_feature(ptrauth_calls)
        result = (MainFunc)__builtin_ptrauth_sign_unauthenticated((void*)result, 0, 0);
#endif
    }
复制代码

runAllInitializersForMain()也能在前面的堆栈中得以体现，函数名也很直观，为main函数的调用，做所有的初始化工作。

而下面的result赋值的过程，实际上就是main函数入口查找的过程。

总结

综上所述，main函数调用前的过程我们更清晰了，一切的开始是从dyld的start函数开始，其通过prepare()函数做好了main函数调用前的所有准备工作，如初始化、链接所有的动态库及可执行文件等，查找main函数的入口并返回到start函数后，实现main函数的调用触发。

当然，这中间实际上还有一些模糊的地方，比如_objc_init里面具体干了啥，load_images有什么用，以及上面的appMain就是我们最开始截图里面的main方法吗？(显然不是，参数数量对不上，哈哈，中间还有一些过程)。

有兴趣的小伙伴可以继续研究研究，后续我们再继续讨论。