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