什么是Mach-O文件？

• Mach-O是Mach object的縮寫，是Mac\iOS上用來存儲程序、庫的標準格式。

• 常見的Mach-O文件類型

dyld和Mach-O

• dyld是iOS中用來加載可執(zhí)行文件、動態(tài)庫的工具，其實它本身也是一個Mach-O文件。

什么是dyld？

• dyld 動態(tài)加載器（又叫做動態(tài)鏈接編輯器）
• dyld的源碼可以點擊此處下載

dyld的作用。

dyld可以用來加載以下三種類型的Mach-O文件

• MH_EXECUTE
• MH_DYLIB
• MH_BUNDLE

ios平臺的編譯過程

• .h.m.cpp等文件-->預編譯-->編譯-->匯編-->鏈接.a .lib. so-->可執(zhí)行文件

動態(tài)庫和靜態(tài)庫的區(qū)別

• 靜態(tài)庫:鏈接時會被完整的復制到可執(zhí)行文件中，所以如果兩個程序都用了某個靜態(tài)庫，那么每個二進制可執(zhí)行文件里面其實都含有這份靜態(tài)庫的代碼。
• 動態(tài)庫: 鏈接時不復制，在程序啟動后用動態(tài)加載，然后再符號綁定，所以理論上動態(tài)庫只用存在一份，好多個程序都可以動態(tài)鏈接到這個動態(tài)庫上面，達到了節(jié)省內(nèi)存(不是磁盤是內(nèi)存中只有一份動態(tài)庫)，還有另外一個好處，由于動態(tài)庫并不綁定到可執(zhí)行程序上，所以我們想升級這個動態(tài)庫就很容易，windows和linux上面一般插件和模塊機制都是這樣實現(xiàn)的。

dyld加載應用程序做了什么

• 我們通過一個例子來分析，新建一個ios工程，在ViewController里面添加一個load方法，再在main.m增加一個c++函數(shù)，打印順序如下

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

• 打印函數(shù)調用堆棧

* 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的執(zhí)行流程如下

  
  
  dyld加載流程

• dyld_start是用匯編實現(xiàn)的，調用dyldbootstrap::start(c++實現(xiàn))

__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 對插入的所有動態(tài)庫初始化
    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寫了回調函數(shù)(*sNotifyObjCInit)(image->getRealPath(), image->machHeader());，當執(zhí)行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);的第二個參數(shù)load_images,而&map_images賦值給了sNotifyObjCMapped并在下面的notifyBatchPartial方法里面有執(zhí)行。

• 回到開始執(zhí)行順序的問題，通過上文知道調用load_images的時候會方法級別的調用(*load_method)(cls, @selector(load));，然后在doModInitFunctions有執(zhí)行一些c++函數(shù)func(context.argc, context.argv, context.envp, context.apple, &context.programVars);,最后由notifyMonitoringDyldMain();進入我們熟知的main()函數(shù)
  

  image.png

• 總結,到這里我們的dyld就與objc關聯(lián)起來了。