背景
眾所周知，對于移動客戶端而言，crash對于用戶是一種非常糟糕的體驗，crash率對于一款移動應用而言也是一個非常重要的質量指標。因此對于開發者而言，如何在代碼中規避一些容易出現crash的場景，養成良好的編碼習慣，就顯得非常重要了。本文僅以總結項目中經常遇到的crash場景為例，分析如何規避開發iOS平臺應用過程中容易遇到的一些可能會造成crash的問題。
crash場景
野指針訪問
表現
EXC_BAD_ACCESS
具體場景
- 定義property該用
strong/weak修飾誤用成assign - 在
objc_setAssociatedObject方法中該用OBJC_ASSOCIATION_RETAIN_NONATOMIC修飾的對象誤用成OBJC_ASSOCIATION_ASSIGN - CoreFoundation層對象
Toll-Free Bridging到Foundation層中，已經用了__bridge_transfer關鍵字轉移了對象的所有權之后，又對CoreFoundation層對象調用了一次CFRelease，如：
CFUUIDRef uuid = CFUUIDCreate(NULL);
CFStringRef cfString = CFUUIDCreateString(NULL, uuid);
NSString *string = (__bridge_transfer NSString *)cfString;
CFRelease(cfString);
- NSNotification/KVO 只addObserver并沒有removeObserver
- block回調之前并沒有判空而是直接調用
解決方案
- 深刻了解各種關鍵字修飾內存語義的區別，正確運用，例如delegate屬性一般都用weak修飾（可以引入靜態代碼檢查 和commit檢查 對assign關鍵字做警告??）
Toll-Free Bridging中三個關于內存語義關鍵字的含義：
(__bridge T) op：告訴編譯器在 bridge 的時候不要做任何事情
(__bridge_retained T) op：（ ObjC 轉 CF 的時候使用）告訴編譯器在 bridge 的時候 retain 對象，開發者需要在CF一端負責釋放對象
(__bridge_transfer T) op：（ CF 轉 ObjC 的時候使用）告訴編譯器轉移 CF 對象的所有權，開發者不再需要在CF一端負責釋放對象 - debug階段啟動僵尸對象模式，enbale Zombie Objects幫助輔助定位問題
原理:在對象釋放（retainCount為0)時，使用一個內置的Zombie對象，替代原來被釋放的對象。無論向該對象發送什么消息（函數調用），都會觸發異常，拋出調試信息。 - 對于NSNotificatio/KVO addObserver和removeObserver一定要成對出現，推薦使用FaceBook開源的第三方庫FBKVOController
- block回調之前先做判空，如：
if (self.didDelete) {
self.didDelete(sender == self.clearAllButton ? YES : NO, self.viewModel);
}
查找不到指定的方法
表現
Terminating app due to uncaught exception 'NSInvalidAgumentException', reason: '-[Class methodName]: unrecognized selector sent to instance 0x1dd96160'
場景
- 頭文件聲明方法但是在.m文件中沒有實現/把方法名修改但是沒有在頭文件中同步
- 調用代理類的方法的時候沒有判斷代理類是否已經實現對應的方法而直接調用，編譯可以通過但是運行時會crash
- 對于id類型的對象沒有判斷類型直接強轉調用方法
-
@property (nonatomic, copy) NSMutableArray *mutableArray;
用copy修飾的可變屬性在賦值之后會變成不可變屬性，比如這里調用addObject方法之后就會crash - 在低版本的系統用了高版本才有的api 如：
//do something
} ```
iOS7下會crash，因為該api是從iOS8系統才開始支持
###解決方案
1. 新建方法時先在.m文件中寫方法實現，再把方法名拷貝到頭文件中，修改方法名時先改頭文件中的聲明
2. **調用代理類的方法前先用 `respondsToSelector` 方法先判斷一下，然后再進行調用。**
如：
if ([self.delegate respondsToSelector:@selector(methodNotExist)]) {
[self.delegate methodNotExist];
}
3. swizzle掉`NSObject`的`- (void)doesNotRecognizeSelector`方法給一個空的實現（風險比較大），因為方法查找不到在正常消息派發和三次消息轉發之后crash之前一定會調用到此方法。
4. 判斷類型之后再強轉調用對應類中的方法 或者**從設計階段規避這種問題，如父類定義接口，子類重載實現**
5. 牢記一些高本版才有的api，如
if([str containsString:@"a"]){
//do something
}
可以替換為
if ([str rangeOfString:@"a"]].location != NSNotFound) {
//do something
}
##集合類相關
###表現
- `Terminating app due to uncaught exception 'NSRangeException', reason: '*** -[__NSArrayI objectAtIndex:]: index 8 beyond bounds [0 .. 7]`
- `failed: caught "NSInvalidArgumentException", " * -[__NSPlaceholderDictionary initWithObjects:forKeys:count:]: attempt to insert nil object from objects[1]`
- `failed: caught "NSInvalidArgumentException", " * setObjectForKey: object cannot be nil (key: no_nillKey)`
- `failed: caught "NSInvalidArgumentException", " * setObjectForKey: key cannot be nil"`
- `Terminating app due to uncaught exception 'NSInvalidArgumentException', reason: '*** -[__NSArrayM insertObject:atIndex:]: object cannot be nil'`
###場景
1. 數組越界
NSArray *array = @[@"a",@"b",@"c"];
id letter = [array objectAtIndex:3];
2. 向數組中插入空對象
NSMutableArray *mutableArrray = [NSMutableArray array];
[mutableArray addObject:nil];
3. 調用可變字典`setObject:ForKey`方法，key或者value為空，特別注意字面量寫法
@{@"itemID":article.itemID}//這里itemID可能為空
4.一邊遍歷數組，一邊修改數組內容
for(id item in self.itemArray) {
if (item != self.currentItem) {
[self.itemArray removeItem:item];
}
}
或者多線程環境中，一個線程在讀另外一個線程在寫
###解決方案
1. 從數組中的某個下標取對于元素的時候先判斷下標與數組長度的關系，如：
if (index < [[self currentUsers] count]) {
UserModel * model = [[self currentUsers] objectAtIndex:index];
return model;
}
2. **對`NSMutableArray`以及`NSMutableDictionary`自定義一些安全的擴展方法**，如：
-(id)objectAtIndexSafely:(NSUInteger)index {
if (index >= self.count) {
return nil;
}
return [self objectAtIndex:index];
}
-(void)setObjectSafely:(id)anObject forKey:(id <NSCopying>)aKey {
if (!aKey) {
return;
}
if (!anObject){
return;
}
[self setObject:anObject forKey:aKey];
}
3. **調用`NSMutableDictionary`的`setValue:ForKey:`方法而不是`setObject:ForKey:`方法，少用字面量語法**
`NSDictionary`內部對value做了處理,`[mutableDictionary setValue:nil ForKey:@"name"]`不會崩潰
4. 保證多線程中讀寫操作的原子性：
方法：加鎖，信號量，GCD串行隊列，GCD `dispatch_barrier_async`方法等，`dispatch_barrier_async`用法示例：
_cache = [[NSMutableDictionary alloc] init];
_queue = dispatch_queue_create("com.mutablearray.safety", DISPATCH_QUEUE_CONCURRENT);
-(id)cacheObjectForKey: (id)key {
__block obj;
dispatch_sync(_queue, ^{
obj = [_cache objectForKey: key];
});
return obj;
}
-(void)setCacheObject: (id)obj forKey: (id)key {
dispatch_barrier_async(_queue, ^{
[_cache setObject: obj forKey: key];
});
}
遍歷時需要修改原數組的時候可以遍歷原數組的一個拷貝，如：
NSMutableArray *copyArray = [NSMutableArray arrayWithArray:self.items];
for(id item in copyArray) {
if (item != self.currentItem) {
[self.items removeGuideViewItem:item];
}
}
##KVO 對同一keypath多次removeObserver
###表現
`*** Terminating app due to uncaught exception 'NSRangeException', reason: 'Cannot remove an observer <UIView 0x7f9a90f0a0d0> for the key path "frame" from <ViewController 0x7f9a90e07010> because it is not registered as an observer.'`
###場景
當對同一個keypath進行兩次removeObserver時會導致程序crash，這種情況常常出現在父類有一個KVO，父類在dealloc中remove了一次，子類又remove了一次
解決方案：
1. try&catch(容易掩蓋問題)
2. 確保addObserver和removeObserver一定要成對出現，推薦使用FaceBook開源的第三方庫FBKVOController
3. **可以分別在父類以及本類中定義各自的context字符串，比如在本類中定義context為@"ThisIsMyKVOContextNotSuper";然后在dealloc中remove observer時指定移除的自身添加的observer。這樣iOS就能知道移除的是自己的KVO，而不是父類中的KVO，避免二次remove造成crash。**
##KVC相關
###表現
- ` *** Terminating app due to uncaught exception 'NSInvalidArgumentException', reason: '[ setNilValueForKey]: could not set nil as the value for the key age.' // 調用setNilValueForKey拋出異常`
- `*** Terminating app due to uncaught exception 'NSUnknownKeyException', reason: '[<ViewController 0x7ff968606ee0> setValue:forUndefinedKey:]: this class is not key value coding-compliant for the key undefined.'//在類中找不到對應的key`
###場景
1.
value為nil，如：
`
[people1 setValue:nil forKey:@"age"]
`
2.
在本類中找不到對應的key，如：
`
[viewController setValue:@"crash" forKey:@"undefined"];
`
###解決方案
1. **重寫setNilValueForKey方法**
-(void)setNilValueForKey:(NSString *)key{
NSLog(@"不能將%@設成nil",key);
}
2. **重寫setValue:forUndefinedKey:方法**
-(void)setValue:(id)value forUndefinedKey:(NSString *)key{
NSLog(@"出現異常，該key不存在%@",key);
}
##UITableView或者UICollectionView的代理方法中返回空的cell
###表現
以UITableView為例：
`*** Terminating app due to uncaught exception 'NSInternalInconsistencyException', reason: 'UITableView (<ContainerTableView: 0x7fec623a6400; baseClass = UITableView; frame = (0 0; 375 567); clipsToBounds = YES; autoresize = W+H; gestureRecognizers = <NSArray: 0x608002844bf0>; layer = <CALayer: 0x60800183eec0>; contentOffset: {0, 0}; contentSize: {375, 2946}>) failed to obtain a cell from its dataSource (<FeedBaseDelegate: 0x600003668540>)'`
###場景
`UITableView`的 `cellForRowAtIndexPath`方法或者`UICollectionView`的`cellForItemAtIndexPath`方法因為異常返回了nil
出現這種情況的原因有：
- `numberOfRowsInSection`返回的數目不正確，導致行數比cellForRoAtIndexPath預期的多，于是`cellForRowAtIndexPath`方法就不能正確返回超出預期的cell了。
- `cellForRowAtIndexPath`中邏輯有誤，漏了一些情況，導致有些cell不能正確返回。
###解決方案
**在相應的代理方法返回之前加一層如果cell為空就返回一個默認cell的兜底保護策略**，如：
- (UITableViewCell *)tableView:(UITableView *)tableView cellForRowAtIndexPath:(NSIndexPath *)indexPath {
ExploreCellBase * cell = nil;
if (!cell) {
UITableViewCell *cell = [tableView dequeueReusableCellWithIdentifier:@"preventCrashCellIdentifier"];
if (!cell) {
cell = [[UITableViewCell alloc] initWithStyle:UITableViewCellStyleDefault reuseIdentifier:@"preventCrashCellIdentifier"];
}
cell.textLabel.text = @"";
return cell;
}
return cell;
}
