给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才可能穿插在中间。
