我們開發(fā)APP纳胧，雖然在極力避免出現(xiàn)線上crash,但是某些情況還是沒法把控霉撵，比如和后端約定好的數(shù)據(jù)格式磺浙，突然哪天給你換了，很容易導(dǎo)致crash徒坡。但是如果我們在任何地方都做防御性判斷撕氧，代碼會寫得特別難受。
之前看到有人開源了防止crash的代碼喇完，所以分析了下伦泥。這些方案主要利用runtime的方法交換和消息轉(zhuǎn)發(fā)來實(shí)現(xiàn)，對那些容易引起crash的方法，添加判斷奄喂，或者在crash之后走消息轉(zhuǎn)發(fā)铐殃。
之前項(xiàng)目用到這個，NSObjectSafe就是這么一個開源庫跨新，只需要拖進(jìn)工程就可以起作用富腊。
NSObjectSafe代碼地址：github鏈接
比如，向NSArray插入一個nil域帐、獲取NSArray長度之外的元素等等赘被，從而導(dǎo)致APP奔潰。NSObjectSafe能有效避免這些奔潰肖揣。這些方案民假，基本都在load中交換這些容易引起crash的方法，并且添加判斷龙优，以此來避免異常羊异。簡化版就是下面這樣：
@implementation NSArray (Safe)
+ (void)load
{
static dispatch_once_t onceToken;
dispatch_once(&onceToken, ^{
/* 沒內(nèi)容類型是__NSArray0 */
swizzleInstanceMethod(NSClassFromString(@"__NSArray0"), @selector(objectAtIndex:), @selector(hookObjectAtIndex:));
/* 有內(nèi)容obj類型才是__NSArrayI */
swizzleInstanceMethod(NSClassFromString(@"__NSArrayI"), @selector(objectAtIndex:), @selector(hookObjectAtIndex:));
.
.//還有很多
.
});
}
- (id) hookObjectAtIndex:(NSUInteger)index {
@synchronized (self) {
if (index < self.count) {
return [self hookObjectAtIndex:index];
}
SFAssert(NO, @"NSArray invalid index:[%@]", @(index));
return nil;
}
}
可以看到，這里面用了個+load 方法彤断、runtime的方法交換野舶。
那么 +load 到底是如何被調(diào)用的呢？
在 iOS 開發(fā)中宰衙，我們經(jīng)常會使用 +load 方法來做一些在 main 函數(shù)之前的操作平道，比如方法交換（Method Swizzle）等。
+load()方法的調(diào)用時機(jī)是這樣的：
1供炼、當(dāng)類或分類被添加到 Obj-C 運(yùn)行時的時候被調(diào)用一屋；可以實(shí)現(xiàn)該方法用來在加載時刻執(zhí)行特定類的操作。
2袋哼、動態(tài)加載和靜態(tài)鏈接都能將 load 消息發(fā)送到類和分類冀墨，但前提是新加載類或分類實(shí)現(xiàn)了要響應(yīng)的方法。
3先嬉、初始化的順序如下：
鏈接的所有框架（Framework）中全部的構(gòu)造器轧苫。
鏡像（Image）中所有的 +load 方法。
鏡像中所有的 C++ 靜態(tài)構(gòu)造器疫蔓，以及 C/C++ 的 attribute(constructor) 函數(shù)含懊。
框架中鏈接的所有構(gòu)造器。
4衅胀、類的 +load 方法在其所有父類的 +load 方法調(diào)用之后調(diào)用岔乔。
5、分類的 +load 方法在其主類的 +load 方法調(diào)用之后調(diào)用滚躯。
了解到 +load 在運(yùn)行時初始化加載鏡像時就會被調(diào)用雏门，使得可以有機(jī)會預(yù)先做很多事情嘿歌。但正是因?yàn)槠浼虞d的時機(jī)非常靠前茁影，如果在 +load 方法中做比較復(fù)雜且在主線程的操作宙帝，將會影響 App 啟動時間，降低用戶體驗(yàn)募闲。所以APP啟動優(yōu)化可以盡量把放到這個方法的任務(wù)往后放步脓，比如+(void)initialize中，他會在每個類初始化的時候調(diào)用一次浩螺。
runtime會在運(yùn)行時調(diào)用工程中的類的+load方法靴患，并且不需要類在代碼中被顯示import，所以有些第三方可拖進(jìn)工程就會起作用要出，而不需要顯示import鸳君。比如：IQKeyboad、NSObjectSafe...
從這里可以解開我之前的一個誤解：一直以為垃圾代碼（尤其是第三方庫）留在工程里面不管他患蹂，以為它不會起作用或颊，如果他里面實(shí)現(xiàn)了 +load 方法，還是可能會起作用的况脆，一旦出bug了饭宾，那叫一個難找批糟。
接著格了，看看runtime的方法交換：
+ (void)load{
NSLog(@"UIViewController Hook load");
static dispatch_once_t onceToken;
dispatch_once(&onceToken, ^{
Method oriMethod = class_getInstanceMethod([self class], NSSelectorFromString(@"dealloc"));
Method repMethod = class_getInstanceMethod([self class], @selector(xx_dealloc));
method_exchangeImplementations(oriMethod, repMethod);
});
}
- (void)xx_dealloc{
NSLog(@"%@ dealloc",NSStringFromClass([self class]));
}
或者像這樣（根據(jù)系統(tǒng)版本修改字號）：
@implementation UIFont (hook)
+ (void)load{
static dispatch_once_t onceToken;
dispatch_once(&onceToken, ^{
[self swizzleClassMethod:@selector(systemFontOfSize:) withMethod:@selector(xx_systemFontOfSize:)];
});
}
+ (UIFont *)xx_systemFontOfSize:(CGFloat)fontSize{
NSString *version = [UIDevice currentDevice].systemVersion;
if (version.doubleValue >= 11.0) {
return [UIFont xx_systemFontOfSize:25.0f];
} else {
return [UIFont xx_systemFontOfSize:14.0f];
}
}
@end
為什么xx_systemFontOfSize里面又調(diào)用了xx_systemFontOfSize？不會死循環(huán)么徽鼎？
嗯盛末，這里不會，因?yàn)榻粨Q了方法的IMP否淤，這里不細(xì)說悄但。
看NSObjectSafe源碼，hook那么多不常見的類石抡，為什么呢檐嚣？比如__NSArray0、__NSArrayI啰扛、__NSSingleObjectArrayI等等嚎京。
這些都是NSArray在某些情況下的實(shí)際類，NSArray在這里使用了類簇的模式隐解。
類簇是一種設(shè)計(jì)模式鞍帝，它包含了一組私有的具體的類，這些類繼承一個公開的抽象類煞茫，也即是基類帕涌，基類負(fù)責(zé)提供對外接口供調(diào)用者使用摄凡，具體類負(fù)責(zé)方法的真正實(shí)現(xiàn)， 我們只需要調(diào)用基類提供的接口來實(shí)現(xiàn)相關(guān)功能蚓曼，而無需關(guān)心背后的具體實(shí)現(xiàn)細(xì)節(jié)亲澡。
在Cocoa中，許多類實(shí)際上是以類簇的方式實(shí)現(xiàn)的纫版，即它們是一群隱藏在通用接口之下的與實(shí)現(xiàn)相關(guān)的類谷扣。例如創(chuàng)建NSString對象時，實(shí)際上獲得的可能是NSLiteralString捎琐、NSCFString会涎、NSSimpleCString、NSBallOfString或者其他未寫入文檔的與實(shí)現(xiàn)相關(guān)的對象瑞凑。
NSNumber就是最常用的類簇實(shí)現(xiàn)的類之一末秃。
這種模式的好處就是，可以隱藏私有類籽御，調(diào)用者只能使用基類暴露的API练慕，而無需關(guān)心里面是什么類，以及背后的具體實(shí)現(xiàn)細(xì)節(jié)技掏。即使將來添加更多的私有類铃将，對外的基類API也沒什么變化。
技術(shù)分享記錄~
