iOS程序启动流程概览

什么是Dyld? 它跟程序的启动有什么关系？

Dyld是动态库链接器。在程序启动过程中负责加载所有库和可执行文件。在此过程中完成对这些库和可执行文件的符号重定向(Rebase)和符号绑定(Binding)等操作。接下来我们可以通过配置xcode的环境变量大致查看App启动流程。

打印iOS程序启动流程

iOS APP的启动流程可以通过在xcode的Edit Scheme ->Run->Arguments -> Environment Variables中加入环境变量DYLD_PRINT_STATISTICS打印出来：

DYLD_PRINT_STATISTICS.png

运行APP，打印结果如下：

Total pre-main time:  31.70 milliseconds (100.0%)
         dylib loading time:  27.29 milliseconds (86.0%)
        rebase/binding time: 411015771.5 seconds (61552300.3%)
            ObjC setup time:  78.12 milliseconds (246.4%)
           initializer time:  74.97 milliseconds (236.4%)
           slowest intializers :
             libSystem.B.dylib :   6.10 milliseconds (19.2%)
   libBacktraceRecording.dylib :   7.03 milliseconds (22.1%)
               libobjc.A.dylib :   1.69 milliseconds (5.3%)
    libMainThreadChecker.dylib :  57.82 milliseconds (182.3%)

从结果可以看出四个阶段的名称以及它们对应的耗时。

dylib loading 阶段是动态链接库dylib加载动态库的阶段，包括系统动态库和我们自己的动态库。
rebase/binding这个阶段实际就是两个操作rebase和binding。rebase就是内部符号偏移修正，binding是外部符号绑定。
ObjC setup这一阶段主要是OC类相关的事务，比如类的注册，category、protocol的读取等等。
intializers 程序的初始化，包括所依赖的动态库的初始化。在这期间会调用 Objc 类的 + load 函数，调用 C++ 中带有constructor 标记的函数等。

上面打印出的这四个阶段还是比较粗略的，实际上dyld在启动过程中是比较复杂的。如果将上面的DYLD_PRINT_STATISTICS换成DYLD_PRINT_STATISTICS_DETAILS，打印得会更加详细：

  total time: 1.3 seconds (100.0%)
  total images loaded:  398 (392 from dyld shared cache)
  total segments mapped: 21, into 415 pages
  total images loading time: 944.18 milliseconds (68.5%)
  total load time in ObjC:  80.88 milliseconds (5.8%)
  total debugger pause time: 801.87 milliseconds (58.2%)
  total dtrace DOF registration time:   0.00 milliseconds (0.0%)
  total rebase fixups:  16,279
  total rebase fixups time:   7.47 milliseconds (0.5%)
  total binding fixups: 567,346

  total binding fixups time: 275.57 milliseconds (20.0%)
  total weak binding fixups time:   0.03 milliseconds (0.0%)
  total redo shared cached bindings time: 459.30 milliseconds (33.3%)
  total bindings lazily fixed up: 0 of 0
  total time in initializers and ObjC +load:  68.67 milliseconds (4.9%)
                         libSystem.B.dylib :   6.04 milliseconds (0.4%)
               libBacktraceRecording.dylib :   7.01 milliseconds (0.5%)
                libMainThreadChecker.dylib :  52.05 milliseconds (3.7%)
total symbol trie searches:    1378030
total symbol table binary searches:    0
total images defining weak symbols:  50
total images using weak symbols:  110

从打印结果可以看出，实际上也是上面四个阶段的扩展。比如说dyld loading包含了images loaded（共享缓存）和images loading等。这几个阶段都是通过dyld来完成的。那dyld到底具体做些什么呢？接下来就通过dyld源码来分析app启动过程dyld到底做了哪些事情。

断点查看启动时dyld的函数调用栈，查找源码位置

首先我们在+load方法打一个断点。然后通过函数调用栈找出启动过程中dyld都执行了那些函数：

dyld_start.jpg

可以看到APP启动时dyld中调用函数的流程是_dyld_start -> bootstrap::start -> dyld:: _main， 顺着流程分别找它们的实现：

• _dyld_start

_dyld_start.jpg

这里面都是汇编代码，根据注释大概意思是一些app相关的准备工作.根据注释可知会调用bootstrap类的start方法，跟调用栈是一致的，因此可以直接进入到bootstrap::start中。

• bootstrap::start

bootstrap_start.png

图中红圈1：这个方法的rebaseDyld是dyld完成自身重定位的方法。首先dyld本身也是一个动态库。对于普通动态库，符号重定位可以由dyld来加载链接来完成，但是dyld的重定位谁来做？只能是它自身完成。这就是为什么会有rebaseDyld的原因，它其实是在对自身进行重定位，只有完成了自身的重定位它才能使用全局变量和静态变量。
图中红圈2：部分就是进入了 dyld:: _main函数了。dyld在app启动中做的主要工作基本上都是在这里完成的。

• dyld:: _main
  App启动过程中Dyld的主要工作都是在这个dyld:: _main函数中完成的。函数中代码比较多，现在大概整理出如下流程：

1、环境变量配置
2、加载共享缓存
3、实例化主程序，并添加到allImages列表中；
4、加载动态库插入的动态库，并添加到allImages列表中；
5、链接主程序(完成Rebase/Binding/weakBind)
6、主程序初始化(ObjC setup/intializers是在这一过程进行的)
7、查找并返回主程序的main函数地址

APP启动流程详解

1、环境变量配置

环境变量是存在于系统中的一些共用数据，任何程序都可以访问。通常来说，环境变量存储的都是一些系统的公共信息，例如系统搜索路径，当前OS版本等。

// 主程序文件头部信息
sMainExecutableMachHeader = mainExecutableMH;
// 随机偏移值ASLR
sMainExecutableSlide = mainExecutableSlide;

setContext(mainExecutableMH, argc, argv, envp, apple);

2、共享缓存

当我们构建一个APP的时候，会链接各种各样的库。这些库同样又会依赖其他的一些框架和动态链接库。于是要加载的动态链接库会非常多。同样非独立的符号也非常多。这里就会有成千上万的符号要确定。这个工作将会话费很多时间——几秒钟。 为了优化这个过程，OS X和iOS上动态链接器使用了一个共享缓存，在/var/db/dyld/。对于每一种架构，操作系统有一个单独的文件包含了绝大多数的动态链接库，这些库已经互相连接并且符号都已经确定。当一个Mach-o文件被加载的时候，动态链接器会首先检查共享缓存，如果存在相应的库就用。每一个进程都把这个共享缓存映射到了自己的地址空间中。这个方法优化了OS X和iOS上程序的加载时间。以下是读取缓存的代码：

    // load shared cache
    checkSharedRegionDisable((dyld3::MachOLoaded*)mainExecutableMH, mainExecutableSlide);
    if ( gLinkContext.sharedRegionMode != ImageLoader::kDontUseSharedRegion ) {

    mapSharedCache();
    }

3、实例化主程序

初始化一个ImageLoader类型的主程序sMainExecutable。后面的主程序相关的操作包括初始化都是通过这个对象来完成的。mainExecutableMH是mach-o文件头部信息，mainExecutableSlide主程序随机偏移值，sExecPath程序的路径。初始化之后检查应用签名。

//
// instantiate ImageLoader for main executable
// instantiate ImageLoader for main executable
sMainExecutable = instantiateFromLoadedImage(mainExecutableMH, mainExecutableSlide, sExecPath);
gLinkContext.mainExecutable = sMainExecutable;
gLinkContext.mainExecutableCodeSigned = hasCodeSignatureLoadCommand(mainExecutableMH);

4、加载插入的动态库

这里会遍历所有插入的动态库（dylib），然后加载。

// load any inserted libraries
        if  ( sEnv.DYLD_INSERT_LIBRARIES != NULL ) {
            for (const char* const* lib = sEnv.DYLD_INSERT_LIBRARIES; *lib != NULL; ++lib) 
                loadInsertedDylib(*lib);
        }

5、链接主程序

这一步主要实现过程如下：

5.1、主程序及其依赖的动态库的Rebase
5.2、插入动态库的Rebase
5.3、主程序及其依赖的动态库的Binding
5.4、插入动态库的Binding
5.5、弱绑定weakBind

备注：这里的recursiveBind和recursiveRebase都是递归的，所以会自底向上地分别调用 doRebase() 和 doBind() 方法，这样被依赖的动态库总是先于依赖它的动态库执行 rebase 和 binding。因为只有所依赖的子动态库rebase和binding之后，符号地址才能被确定，这时候主动态库再进行binding就可以直接映射到相应的子动态库的符号地址。

• 5.1、主程序及其依赖的动态库的Rebase
  主程序调用link函数进行链接。其中重定向rebase就是在这一步完成的，过程是link->recursiveRebaseWithAccounting->recursiveRebase。recursiveRebase函数会递归对主程序及其所依赖的库和执行文件进行符号重定向（Rebase）。

// link main executable
gLinkContext.linkingMainExecutable = true;

link(sMainExecutable, sEnv.DYLD_BIND_AT_LAUNCH, true, ImageLoader::RPathChain(NULL, NULL), -1);

这其中虽然调用了link函数，但是这里主程序link函数中并没有调用recursiveBindWithAccounting函数。因为link函数内部判断linkingMainExecutable为false才执行recursiveBindWithAccounting，而此时linkingMainExecutable为true。以下是link函数的主要实现：

t2 = mach_absolute_time();
this->recursiveRebaseWithAccounting(context);
context.notifyBatch(dyld_image_state_rebased, false);

t3 = mach_absolute_time();
if ( !context.linkingMainExecutable )
    this->recursiveBindWithAccounting(context, forceLazysBound, neverUnload);

t4 = mach_absolute_time();
if ( !context.linkingMainExecutable ) this  ->weakBind(context);
t5 = mach_absolute_time();

• 5.2、插入动态库的Rebase
  链接插入的动态库，跟上一步一样都是调用link函数。

// link any inserted libraries
        // do this after linking main executable so that any dylibs pulled in by inserted 
        // dylibs (e.g. libSystem) will not be in front of dylibs the program uses
        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 ) {
                // only INSERTED libraries can interpose
                // register interposing info after all inserted libraries are bound so chaining works
                for(unsigned int i=0; i < sInsertedDylibCount; ++i) {
                    ImageLoader* image = sAllImages[i+1];
                    image->registerInterposing(gLinkContext);
                }
            }
        }

• 5.3、主程序及其依赖的动态库的Binding
  调用函数recursiveBindWithAccounting会递归对主程序及其所依赖的动态库进行符号绑定（Binding）。

/ Bind and notify for the main executable now that interposing has been registered
        uint64_t bindMainExecutableStartTime = mach_absolute_time();
        sMainExecutable->recursiveBindWithAccounting(gLinkContext, sEnv.DYLD_BIND_AT_LAUNCH, true);

• 5.4、插入动态库的Binding

// Bind and notify for the inserted images now interposing has been registered
        if ( sInsertedDylibCount > 0 ) {
            for(unsigned int i=0; i < sInsertedDylibCount; ++i) {
                ImageLoader* image = sAllImages[i+1];
                image->recursiveBind(gLinkContext, sEnv.DYLD_BIND_AT_LAUNCH, true);
            }
        }

• 5.5、弱绑定weakBind
  插入的动态库链接完成后就执行主程序的弱绑定，之后就会把状态linkingMainExecutable设置为false，表示主程序链接完成。

// <rdar://problem/12186933> do weak binding only after all inserted images linked
sMainExecutable->weakBind(gLinkContext);
gLinkContext.linkingMainExecutable = false;

6、主程序初始化

完成了rebase/binding之后就开始了初始化工作。通过调用函数 initializeMainExecutable进行初始化：

     // run all initializers
     initializeMainExecutable(); 

主程序初始化初始是app启动很重要的一个过程，在主程序初始化的过程中会同时初始化其所依赖的动态库，这一过程完成了包括ObjC的初始化等工作。+load和C++构造函数也是在这一过程中完成的。
initializeMainExecutable函数的初始流程大概整理如下：

dyld_sim`ImageLoader::runInitializers
  dyld_sim`ImageLoader::processInitializers
    dyld_sim`ImageLoader::recursiveInitialization
       dyld_sim`dyld::notifySingle
         libobjc.A.dylib`load_images
           libobjc.A.dylib`call_load_methods
             libobjc.A.dylib`call_class_loads
                + load
            libobjc.A.dylib`call_category_loads
                + load
/*备注：这里面可以看到，先调用所有class的+load再调用category的。因此我们本类的+load方法总是先于category被调用。*/

/**下面是调用C++构造函数的流程*/
       dyld_sim`ImageLoaderMachO::doInitialization
         dyld_sim`ImageLoaderMachO::doModInitFunctions
           __attribute__((constructor)) void func(void) 
              

主程序在初始化时是先递归调用其所依赖的动态库完成初始化然后在完成自身初始化。在上面的函数流程中load_images函数是在libobjc.A.dylib动态库里面的，它是在程序初始化之前被注册到dyld里面，等到初始化的时候执行，完成libobjc的映射，非懒加载类就是在这一过程中被加载并调用+load方法的。以下是initializeMainExecutable源码如下：

void initializeMainExecutable()
{
    // record that we've reached this step
    gLinkContext.startedInitializingMainExecutable = true;

    // run initialzers for any inserted dylibs
    ImageLoader::InitializerTimingList initializerTimes[allImagesCount()];
    initializerTimes[0].count = 0;
    const size_t rootCount = sImageRoots.size();
    if ( rootCount > 1 ) {
        for(size_t i=1; i < rootCount; ++i) {
            sImageRoots[i]->runInitializers(gLinkContext, initializerTimes[0]);
        }
    }
    
    // run initializers for main executable and everything it brings up 
    sMainExecutable->runInitializers(gLinkContext, initializerTimes[0]);
    
    // register cxa_atexit() handler to run static terminators in all loaded images when this process exits
    if ( gLibSystemHelpers != NULL ) 
        (*gLibSystemHelpers->cxa_atexit)(&runAllStaticTerminators, NULL, NULL);

    // dump info if requested
    if ( sEnv.DYLD_PRINT_STATISTICS )
        ImageLoader::printStatistics((unsigned int)allImagesCount(), initializerTimes[0]);
    if ( sEnv.DYLD_PRINT_STATISTICS_DETAILS )
        ImageLoaderMachO::printStatisticsDetails((unsigned int)allImagesCount(), initializerTimes[0]);
}

通过源码分析：首先是遍历插入的动态库进行初始化，然后就是主程序的初始化。到这里程序的初始化就算完成了，这一阶段其实就是完成了我们之前打印的ObjC setUp 和initializers两个阶段。主程序初始化完成之后就进入，dyld就通知各方主程序准备要调用main函数了，然后开始寻找主程序的main函数入口地址返回。

7、找到主程序的main函数地址并返回

完成主程序初始化之后，dyld就可以从主程序找到入口main函数，然后返回。

// main executable uses LC_UNIXTHREAD, dyld needs to let "start" in program set up for main()
result = (uintptr_t)sMainExecutable->getEntryFromLC_UNIXTHREAD();

另外程序启动过程中一些重要函数的解析

通过load_images作为符号断点查看调用栈，可以得到更详细的调用栈：

load_image断点.png

load_images调用栈.png

这个过程中涉及到几个重要的动态库和方法，主要有

动态库：
libSystem.B.dylib，系统基础动态库，其他动态库的初始化必须在他之后。其初始化函数是libSystem_initializer；
libdispatch.dylib，GCD所在的库，其初始化函数是libdispatch_init；
libobjc.dylib，OC代码库，其初始化函数是_objc_init 。
几个重要的函数：
_objc_init；
_dyld_objc_notify_register；
map_images；
load_images；

_objc_init

_objc_init是libobjc.A.dylib的初始化函数，其源码如下：

void _objc_init(void)
{
    static bool initialized = false;
    if (initialized) return;
    initialized = true;
    // fixme defer initialization until an objc-using image is found?
    environ_init();//环境变量相关初始化，逼比如我们之前添加的打印程序启动的环境变量就是在这里面处理的
    tls_init();
    static_init();// static_init() Run C++ static constructor functions. libc calls _objc_init() before dyld would call our static constructors,  so we have to do it ourselves.
    runtime_init(); // 类表allocatedClasses.init()和unattachedCategories.init(32)看似跟category相关的表
    exception_init();//异常处理回调函数初始化
    cache_init();
    _imp_implementationWithBlock_init();

    _dyld_objc_notify_register(&map_images, load_images, unmap_image);

#if __OBJC2__
    didCallDyldNotifyRegister = true;
#endif
}

总结如下:

environ_init()读取影响运行时的环境变量。如果需要，还可以打印环境变量帮助。
tls_init()关于线程key的绑定 - 比如每条线程数据的析构函数。
static_init()有注释可知运行C++静态析构函数。在dyld调用我们的静态构造函数之前，libc会调用_objc_init(), 因此我们必须自己调用。
runtime_init() 类表allocatedClasses.init()和unattachedCategories.init(32)看似跟category相关的表，这个在后面类的
imp_implementationWithBlock_init(void)启动回调机制。通常不会这么做。因为所有的初始话都是惰性的，但是对于某些进程，我们会迫不及待地加载trampolines dylib。
_dyld_objc_notify_register向dyld注册监听函数。以便在镜像文件映射、取消映射和初始化objc时调用。Dyld将使用包含objc-image-info的镜像文件的数组回调给map_images函数。
runtime_init() 运行时环境初始化，里面主要是类表allocatedClasses 和unattachedCategories
exception_init()初始化ibobjc的异常处理系统

_dyld_objc_notify_register

函数_dyld_objc_notify_register是负责向dyld注册相关的回调函数，这些函数会在合适的时机dyld会通知调用，这函数就是它的三个参数load_images、map_images和unmap_image。其实现是在dlyd中的：

void _dyld_objc_notify_register(_dyld_objc_notify_mapped    mapped,
                                _dyld_objc_notify_init      init,
                                _dyld_objc_notify_unmapped  unmapped)
{
    dyld::registerObjCNotifiers(mapped, init, unmapped);
}

void registerObjCNotifiers(_dyld_objc_notify_mapped mapped, _dyld_objc_notify_init init, _dyld_objc_notify_unmapped unmapped)
{
    // record functions to call
    sNotifyObjCMapped   = mapped;
    sNotifyObjCInit     = init;
    sNotifyObjCUnmapped = unmapped;

    // call 'mapped' function with all images mapped so far
    try {
        notifyBatchPartial(dyld_image_state_bound, true, NULL, false, true);
    }
    catch (const char* msg) {
        // ignore request to abort during registration
    }

    // <rdar://problem/32209809> call 'init' function on all images already init'ed (below libSystem)
    for (std::vector<ImageLoader*>::iterator it=sAllImages.begin(); it != sAllImages.end(); it++) {
        ImageLoader* image = *it;
        if ( (image->getState() == dyld_image_state_initialized) && image->notifyObjC() ) {
            dyld3::ScopedTimer timer(DBG_DYLD_TIMING_OBJC_INIT, (uint64_t)image->machHeader(), 0, 0);
            (*sNotifyObjCInit)(image->getRealPath(), image->machHeader());
        }
    }
}

可以看到dyld会把这三个函数缓存起来，以方便在合适的时机调用它们。

map_images（ObjC setUp）

函数map_images是在libobjc库中实现的，是在libobjc初始化的时候通过_dyld_objc_notify_register向dlyd注册，用于监听镜像文件的映射。OC相关的镜像文件在完成rebase/binding之后，就会发出一个通知去调用map_images。但是有些时候镜像文件是在libobjc初始化之前完成rebase/binding，这时候还没有map_images这个函数。所以在libobjc初始化并调用 _dyld_objc_notify_register向dyld注册的map_images时候，它会去把已经完成rebase/binding的镜像文件通过调用map_images进行OC代码相关的映射映射。所以map_images的调用是在rebase/binding之后，在动态库（镜像文件）调用initializer初始化之前的。函数map_images主要完成动态库中的类的映射、初始化等操作。也就是我们前面打印的ObjC setUp阶段。map_images通过镜像文件的读取类相关的信息进行初始化，然后保存在类表中。
在完成类的映射，并完成非懒加载类的加载之后就可以调用OC相关的动态库的初始化方法initializer了。initializer完成之后就会调用load_images函数。

load_images

load_images函数是在OC相关动态库完成初始化之后调用的，在这期间，这里首先会加载非懒加载类的category，然后调用所有已经加载的class和category的+load方法（点击了解类的加载流程）：

void
load_images(const char *path __unused, const struct mach_header *mh)
{
    if (!didInitialAttachCategories && didCallDyldNotifyRegister) {
        didInitialAttachCategories = true;
        loadAllCategories();
    }

    // Return without taking locks if there are no +load methods here.
    if (!hasLoadMethods((const headerType *)mh)) return;

    recursive_mutex_locker_t lock(loadMethodLock);

    // Discover load methods
    {
        mutex_locker_t lock2(runtimeLock);
        prepare_load_methods((const headerType *)mh);
    }

    // Call +load methods (without runtimeLock - re-entrant)
    call_load_methods();
}

void call_load_methods(void)
{
    static bool loading = NO;
    bool more_categories;

    loadMethodLock.assertLocked();

    // Re-entrant calls do nothing; the outermost call will finish the job.
    if (loading) return;
    loading = YES;

    void *pool = objc_autoreleasePoolPush();

    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);

    objc_autoreleasePoolPop(pool);

    loading = NO;
}