什么是Mach-O文件？

• Mach-O是Mach object的缩写，是Mac\iOS上用来存储程序、库的标准格式。

• 常见的Mach-O文件类型

Mach-O类型	示例文件
MH_OBJECT	目标文件（.o） 静态库文件（.a）注：静态库其实就是多个目标文件合并在一起
MH_EXECUTE	可执行文件，存放App的所有源码信息，在.app/xx
MH_DYLIB	动态库文件.dylib 或者 .framework/xx
MH_DYLINKER	动态链接编辑器，也就是/usr/lib/dyld工具
MH_DSYM	此文件中存储这二进制文件符号信息(.dSYM/Contents/Resources/DWARF/xx)，在开发中，我们经常使用此文件来分析App的崩溃信息

dyld和Mach-O

• dyld是iOS中用来加载可执行文件、动态库的工具，其实它本身也是一个Mach-O文件。

什么是dyld？

• dyld 动态加载器（又叫做动态链接编辑器）
• dyld的源码可以点击此处下载

dyld的作用。

dyld可以用来加载以下三种类型的Mach-O文件

• MH_EXECUTE
• MH_DYLIB
• MH_BUNDLE

ios平台的编译过程

• .h.m.cpp等文件-->预编译-->编译-->汇编-->链接.a .lib. so-->可执行文件

动态库和静态库的区别

• 静态库:链接时会被完整的复制到可执行文件中，所以如果两个程序都用了某个静态库，那么每个二进制可执行文件里面其实都含有这份静态库的代码。
• 动态库: 链接时不复制，在程序启动后用动态加载，然后再符号绑定，所以理论上动态库只用存在一份，好多个程序都可以动态链接到这个动态库上面，达到了节省内存(不是磁盘是内存中只有一份动态库)，还有另外一个好处，由于动态库并不绑定到可执行程序上，所以我们想升级这个动态库就很容易，windows和linux上面一般插件和模块机制都是这样实现的。

dyld加载应用程序做了什么

• 我们通过一个例子来分析，新建一个ios工程，在ViewController里面添加一个load方法，再在main.m增加一个c++函数，打印顺序如下

+[ViewController load]
来了 : kcFunc 
来了 : main 

• 打印函数调用堆栈

* thread #1, queue = 'com.apple.main-thread', stop reason = breakpoint 3.1
  * frame #0: 0x000000010fae5d87 Arm64Methd`+[ViewController load](self=ViewController, _cmd="load") at ViewController.m:32:5
    frame #1: 0x00007fff51402e4b libobjc.A.dylib`load_images + 1317
    frame #2: 0x000000010faf2d79 dyld_sim`dyld::notifySingle(dyld_image_states, ImageLoader const*, ImageLoader::InitializerTimingList*) + 418
    frame #3: 0x000000010faff990 dyld_sim`ImageLoader::recursiveInitialization(ImageLoader::LinkContext const&, unsigned int, char const*, ImageLoader::InitializerTimingList&, ImageLoader::UninitedUpwards&) + 438
    frame #4: 0x000000010fafe7a6 dyld_sim`ImageLoader::processInitializers(ImageLoader::LinkContext const&, unsigned int, ImageLoader::InitializerTimingList&, ImageLoader::UninitedUpwards&) + 188
    frame #5: 0x000000010fafe846 dyld_sim`ImageLoader::runInitializers(ImageLoader::LinkContext const&, ImageLoader::InitializerTimingList&) + 82
    frame #6: 0x000000010faf308c dyld_sim`dyld::initializeMainExecutable() + 199
    frame #7: 0x000000010faf70fc dyld_sim`dyld::_main(macho_header const*, unsigned long, int, char const**, char const**, char const**, unsigned long*) + 3831
    frame #8: 0x000000010faf21cd dyld_sim`start_sim + 122
    frame #9: 0x0000000112f9f8cc dyld`dyld::useSimulatorDyld(int, macho_header const*, char const*, int, char const**, char const**, char const**, unsigned long*, unsigned long*) + 2308
    frame #10: 0x0000000112f9d575 dyld`dyld::_main(macho_header const*, unsigned long, int, char const**, char const**, char const**, unsigned long*) + 818
    frame #11: 0x0000000112f98227 dyld`dyldbootstrap::start(dyld3::MachOLoaded const*, int, char const**, dyld3::MachOLoaded const*, unsigned long*) + 453
    frame #12: 0x0000000112f98025 dyld`_dyld_start + 37

• 通过上述堆栈及对应的dyld的源码可以得出dyld的执行流程如下

  
  dyld加载流程

• dyld_start是用汇编实现的，调用dyldbootstrap::start(c++实现)

__dyld_start:
        ......
    // call dyldbootstrap::start(app_mh, argc, argv, dyld_mh, &startGlue)
    bl  __ZN13dyldbootstrap5startEPKN5dyld311MachOLoadedEiPPKcS3_Pm
        ......

• dyldbootstrap::start

uintptr_t start(const dyld3::MachOLoaded* appsMachHeader, int argc, const char* argv[],
                const dyld3::MachOLoaded* dyldsMachHeader, uintptr_t* startGlue)
{

    // Emit kdebug tracepoint to indicate dyld bootstrap has started <rdar://46878536>
    dyld3::kdebug_trace_dyld_marker(DBG_DYLD_TIMING_BOOTSTRAP_START, 0, 0, 0, 0);

    // if kernel had to slide dyld, we need to fix up load sensitive locations
    // we have to do this before using any global variables
    rebaseDyld(dyldsMachHeader);  //苹果为了应用安全通过ASLR（地址空间随机布局）做了一些地址偏移处理，这一操作就是找到真正的地址

    // kernel sets up env pointer to be just past end of agv array
    const char** envp = &argv[argc+1];
    
    // kernel sets up apple pointer to be just past end of envp array
    const char** apple = envp;
    while(*apple != NULL) { ++apple; }
    ++apple;

    // set up random value for stack canary
    __guard_setup(apple);

#if DYLD_INITIALIZER_SUPPORT
    // run all C++ initializers inside dyld
    runDyldInitializers(argc, argv, envp, apple);
#endif

    // now that we are done bootstrapping dyld, call dyld's main
    uintptr_t appsSlide = appsMachHeader->getSlide();
    return dyld::_main((macho_header*)appsMachHeader, appsSlide, argc, argv, envp, apple, startGlue);
}

• 我们着重看下dyld::_main里面做了什么

  
  dyld::_main
• 我们主要研究第7步对应上图的流程
• 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]);
    ......
}

• runInitializers初始化方法

void ImageLoader::runInitializers(const LinkContext& context, InitializerTimingList& timingInfo)
{
    uint64_t t1 = mach_absolute_time();
    mach_port_t thisThread = mach_thread_self();
    ImageLoader::UninitedUpwards up;
    up.count = 1;
    up.imagesAndPaths[0] = { this, this->getPath() };
    processInitializers(context, thisThread, timingInfo, up);
    context.notifyBatch(dyld_image_state_initialized, false);
    mach_port_deallocate(mach_task_self(), thisThread);
    uint64_t t2 = mach_absolute_time();
    fgTotalInitTime += (t2 - t1);
}

• processInitializers方法

void ImageLoader::processInitializers(const LinkContext& context, mach_port_t thisThread,
                                     InitializerTimingList& timingInfo, ImageLoader::UninitedUpwards& images)
{
    uint32_t maxImageCount = context.imageCount()+2;
    ImageLoader::UninitedUpwards upsBuffer[maxImageCount];
    ImageLoader::UninitedUpwards& ups = upsBuffer[0];
    ups.count = 0;
    // Calling recursive init on all images in images list, building a new list of
    // uninitialized upward dependencies.
    for (uintptr_t i=0; i < images.count; ++i) {
        images.imagesAndPaths[i].first->recursiveInitialization(context, thisThread, images.imagesAndPaths[i].second, timingInfo, ups);
    }
    // If any upward dependencies remain, init them.
    if ( ups.count > 0 )
        processInitializers(context, thisThread, timingInfo, ups);
}

• recursiveInitialization方法

void ImageLoader::recursiveInitialization(const LinkContext& context, mach_port_t this_thread, const char* pathToInitialize,
                                          InitializerTimingList& timingInfo, UninitedUpwards& uninitUps)
{
        ......
        // let objc know we are about to initialize this image 即将初始化此镜像
            uint64_t t1 = mach_absolute_time();
            fState = dyld_image_state_dependents_initialized;
            oldState = fState;
            context.notifySingle(dyld_image_state_dependents_initialized, this, &timingInfo);
            
            // initialize this image 初始化此镜像
            bool hasInitializers = this->doInitialization(context);

            // let anyone know we finished initializing this image  初始化完成
            fState = dyld_image_state_initialized;
            oldState = fState;
            context.notifySingle(dyld_image_state_initialized, this, NULL);
       ......
}

• 第一个notifySingle写了回调函数(*sNotifyObjCInit)(image->getRealPath(), image->machHeader());，当执行doInitialization方法后会通过doModInitFunctions里面一系列初始化到libobjc里_objc_init的_dyld_objc_notify_register(&map_images, load_images, unmap_image);方法又回到dyld

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

• registerObjCNotifiers方法

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

• 在上述方法里面就有sNotifyObjCInit的赋值，也就是_dyld_objc_notify_register(&map_images, load_images, unmap_image);的第二个参数load_images,而&map_images赋值给了sNotifyObjCMapped并在下面的notifyBatchPartial方法里面有执行。

• 回到开始执行顺序的问题，通过上文知道调用load_images的时候会方法级别的调用(*load_method)(cls, @selector(load));，然后在doModInitFunctions有执行一些c++函数func(context.argc, context.argv, context.envp, context.apple, &context.programVars);,最后由notifyMonitoringDyldMain();进入我们熟知的main()函数
  

  image.png

• 总结,到这里我们的dyld就与objc关联起来了。