給iOS APP做啟動(dòng)耗時(shí)統(tǒng)計(jì)予跌，需要取一個(gè)較早的時(shí)機(jī)作為開始時(shí)間戳挪挤，我們很容易想到OC的+load, 那么有沒有比這個(gè)更早的呢温治？
一剧劝、__attribute__((constructor))與+load 方法哪個(gè)時(shí)機(jī)早
可以使用__attribute__((constructor))來標(biāo)記函數(shù)悠菜，這個(gè)函數(shù)將在啟動(dòng)時(shí)自動(dòng)被調(diào)用舰攒，并且在main函數(shù)之前。
比如下面FLEX庫中的例子悔醋， 會(huì)在啟動(dòng)后摩窃，main函數(shù)之前自動(dòng)執(zhí)行。
__attribute__((constructor))
static void FLEXInitKnownRootClasses(void) {
cNSObject = [NSObject class];
cNSProxy = [NSProxy class];
}
但是經(jīng)過運(yùn)行后發(fā)現(xiàn)：
在模擬器和真機(jī)上芬骄，__attribute__((constructor))標(biāo)記的函數(shù)和 Objective-C 中的 +load 方法的執(zhí)行時(shí)機(jī)略有差異猾愿。并且如果有多個(gè)這樣的函數(shù)，不能確定是所有__attribute__((constructor))先執(zhí)行還是+load方法先執(zhí)行账阻，需要在真機(jī)上測試運(yùn)行為準(zhǔn)蒂秘。
二、__attribute__((constructor))標(biāo)記的函數(shù)是否可以有優(yōu)先級(jí)
- 如果我們程序中定義了多個(gè)這樣的函數(shù)宰僧，那么哪個(gè)會(huì)先執(zhí)行材彪？
它們的執(zhí)行順序可能會(huì)受到編譯器、鏈接器和操作系統(tǒng)等因素的影響琴儿。一般來說段化，這些函數(shù)的執(zhí)行順序不能被預(yù)測，因此在代碼中不應(yīng)該依賴任何特定的執(zhí)行順序造成。
- 有什么方法可以設(shè)定執(zhí)行順序显熏？
可以使用
__attribute__((constructor(N)))的形式來設(shè)置它們的優(yōu)先級(jí)，其中 N 為一個(gè)整數(shù)值晒屎，表示這個(gè)函數(shù)應(yīng)該在所有使用較低數(shù)字的函數(shù)之前執(zhí)行喘蟆。優(yōu)先級(jí)值越小，執(zhí)行越早鼓鲁。
void C() attribute((constructor(101)));
void B() attribute((constructor(102)));
void A() attribute((constructor(103)));
三蕴轨、打斷點(diǎn)調(diào)試結(jié)果
通過給attribute((constructor))的函數(shù)打斷點(diǎn)，然后控制臺(tái)打印函數(shù)調(diào)用棧：
* 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))函數(shù)骇吭，打斷點(diǎn)橙弱，比對(duì)后發(fā)現(xiàn)：
-
+load方法要比最開始的幾個(gè)__attribute__((constructor))函數(shù)執(zhí)行要晚，但是并不是比所有的都晚。 - 系統(tǒng)啟動(dòng)后先遍歷所有的
__attribute__((constructor))函數(shù)執(zhí)行棘脐，再執(zhí)行的+load,但是遍歷執(zhí)行__attribute__((constructor))過程中應(yīng)該是異步斜筐，這樣+load才可能穿插在中間。
