__attribute__((constructor))与+lo

给iOS APP做启动耗时统计，需要取一个较早的时机作为开始时间戳，我们很容易想到OC的+load, 那么有没有比这个更早的呢？

一、__attribute__((constructor))与+load 方法哪个时机早

可以使用__attribute__((constructor))来标记函数，这个函数将在启动时自动被调用，并且在main函数之前。

比如下面FLEX库中的例子， 会在启动后，main函数之前自动执行。

__attribute__((constructor))
static void FLEXInitKnownRootClasses(void) {
    cNSObject = [NSObject class];
    cNSProxy = [NSProxy class];
}

但是经过运行后发现：
在模拟器和真机上，__attribute__((constructor))标记的函数和 Objective-C 中的 +load 方法的执行时机略有差异。并且如果有多个这样的函数，不能确定是所有__attribute__((constructor))先执行还是+load方法先执行，需要在真机上测试运行为准。

二、__attribute__((constructor))标记的函数是否可以有优先级

• 如果我们程序中定义了多个这样的函数，那么哪个会先执行？

它们的执行顺序可能会受到编译器、链接器和操作系统等因素的影响。一般来说，这些函数的执行顺序不能被预测，因此在代码中不应该依赖任何特定的执行顺序。

• 有什么方法可以设定执行顺序？

可以使用 __attribute__((constructor(N)))的形式来设置它们的优先级，其中 N 为一个整数值，表示这个函数应该在所有使用较低数字的函数之前执行。优先级值越小，执行越早。
void C() attribute((constructor(101)));
void B() attribute((constructor(102)));
void A() attribute((constructor(103)));

三、打断点调试结果

通过给attribute((constructor))的函数打断点，然后控制台打印函数调用栈：

* thread #1, queue = 'com.apple.main-thread', stop reason = breakpoint 9.1
    frame #0: 0x000000010c4f4cc8 FLEX`FLEXRuntimeSafteyInit at FLEXRuntimeSafety.m:23:30
  * frame #1: 0x00000001bc092280 dyld`invocation function for block in dyld4::Loader::findAndRunAllInitializers(dyld4::RuntimeState&) const + 156
    frame #2: 0x00000001bc0e812c dyld`invocation function for block in dyld3::MachOAnalyzer::forEachInitializer(Diagnostics&, dyld3::MachOAnalyzer::VMAddrConverter const&, void (unsigned int) block_pointer, void const*) const + 172
    frame #3: 0x00000001bc090968 dyld`invocation function for block in dyld3::MachOFile::forEachSection(void (dyld3::MachOFile::SectionInfo const&, bool, bool&) block_pointer) const + 524
    frame #4: 0x00000001bc08fcd8 dyld`dyld3::MachOFile::forEachLoadCommand(Diagnostics&, void (load_command const*, bool&) block_pointer) const + 296
    frame #5: 0x00000001bc08f17c dyld`dyld3::MachOFile::forEachSection(void (dyld3::MachOFile::SectionInfo const&, bool, bool&) block_pointer) const + 192
    frame #6: 0x00000001bc0e0f90 dyld`dyld3::MachOFile::forEachInitializerPointerSection(Diagnostics&, void (unsigned int, unsigned int, bool&) block_pointer) const + 160
    frame #7: 0x00000001bc09ad08 dyld`dyld3::MachOAnalyzer::forEachInitializer(Diagnostics&, dyld3::MachOAnalyzer::VMAddrConverter const&, void (unsigned int) block_pointer, void const*) const + 432
    frame #8: 0x00000001bc097788 dyld`dyld4::Loader::findAndRunAllInitializers(dyld4::RuntimeState&) const + 176
    frame #9: 0x00000001bc093ccc dyld`dyld4::Loader::runInitializersBottomUp(dyld4::RuntimeState&, dyld3::Array<dyld4::Loader const*>&) const + 216
    frame #10: 0x00000001bc093ca8 dyld`dyld4::Loader::runInitializersBottomUp(dyld4::RuntimeState&, dyld3::Array<dyld4::Loader const*>&) const + 180
    frame #11: 0x00000001bc09933c dyld`dyld4::Loader::runInitializersBottomUpPlusUpwardLinks(dyld4::RuntimeState&) const + 328
    frame #12: 0x00000001bc0cd244 dyld`dyld4::APIs::runAllInitializersForMain() + 360
    frame #13: 0x00000001bc0a266c dyld`dyld4::prepare(dyld4::APIs&, dyld3::MachOAnalyzer const*) + 3388
    frame #14: 0x00000001bc0a08d4 dyld`start + 2388

在不同的库中写__attribute__((constructor))函数，打断点，比对后发现：

• +load方法要比最开始的几个__attribute__((constructor))函数执行要晚，但是并不是比所有的都晚。
• 系统启动后先遍历所有的__attribute__((constructor))函数执行，再执行的+load,但是遍历执行__attribute__((constructor))过程中应该是异步，这样+load才可能穿插在中间。