崩溃集锦

1、isEqualToNumber

// 后面的number不能为空;
// isEqualToString前后都可以为空
    NSNumber *number = nil;
    if ([@(5) isEqualToNumber:number]) {

    }

2、不要在init和dealloc函数中使用accessor

摘自原文链接和唐巧博客链接
苹果也建议Don’t Use Accessor Methods in Initializer Methods and dealloc,应该把这当做编码规范去使用,从根本上避免这类问题,即使现在代码没有问题,难保将来维护或扩展时会出现问题。

案例:

@interface LBBaseModel ()

@property (nonatomic, strong) NSString *info;

@end

@implementation LBBaseModel

- (instancetype)init {
    if ([super init]) {
        NSLog(@"%s---start",__func__);
        self.info = @"baseInfo";
        NSLog(@"%s---end",__func__);
    }
    return self;
}

@end

@interface LBSubModel ()

@property (nonatomic, strong) NSString *subInfo;

@end

@implementation LBSubModel

- (instancetype)init {
    if (self = [super init]) {
        NSLog(@"%s---start",__func__);
        self.subInfo = @"subInfo";
        NSLog(@"%s---end",__func__);
    }
    return self;
}

- (void)setInfo:(NSString *)info {
    [super setInfo:info];
    NSString* copyString = [NSString stringWithString:self.subInfo];
    NSLog(@"%@",copyString);
}

@end
-[LBBaseModel init]---start
*** Terminating app due to uncaught exception 'NSInvalidArgumentException', reason: '*** -[NSPlaceholderString initWithString:]: nil argument'

当执行[[LBSubModel alloc]init]时会调用父类在Init方法。其中调用了accessor,去初始化父类部分的info属性。看起来十分正常,但一旦子类重写了该方法,那么由于多态此时调用的就是子类的accessor方法!子类的accessor实现中的代码都是以子类部分已初始化完全为前提编写,即子类部分已经初始化完毕,完全可用,而现实情况是其init方法并没有执行完,对此假设并不成立,从而可能造成崩溃。以上例子有人造的痕迹,现实中更多的是某个方法被少调用一次,出现逻辑错误。

你唯一不应该用 Accessor 的地方是 init 函数和 delloc 函数。在 init 函数中,对于一个 _count 成员变量应该像下面这样赋值:

-(id)init { 
     self = [super init]; 
     if (self) {
          _count = [[NSNumber alloc] initWithInteger:0]; 
     }
     return self;
}

对于一个带参数的 init 函数,你应该实现成下面这样:

- (id)initWithCount:(NSNumber *)startingCount { 
     self = [super init]; 
     if (self) {
          _count = [startingCount copy];
     }
     return self;
}

对于在 dealloc 中,对应的写法应该是调 release:

- (void)dealloc { 
     [_count release]; 
     [super dealloc];
}

3、assgin修饰引起的野指针

@interface LBViewController ()

@property (nonatomic, assign) UIView *testView;
@end

@implementation LBViewController

- (void)viewDidLoad
{
    [super viewDidLoad];
    
    [self.view addSubview:self.testView];
}

-(UIView *)testView{
    if (!_testView) {
        _testView = [[UIView alloc] initWithFrame:CGRectMake(0, 0, 50, 50)];
        _testView.backgroundColor = [UIColor redColor];
    }
    return _testView;
}

@end
*** -[UIView setBackgroundColor:]: message sent to deallocated instance 0x7f9996c179a0

assign:修饰的对象释放后,指针不会自动清空,依然指向销毁的对象,这就造成了野指针

weak: 修饰的对象释放后,指针会被自动清空(nil)


image.png

3、nonatomic多线程引起的崩溃

原文移步这里
nonatomic:不安全
atomic:加锁+耗性能

//有两个属性,分别设置为nonatomic和atomic
@interface ViewController : UIViewController
@property (nonatomic, strong) NSString *name;
@property (atomic, assign) int number;
@end

一、 10000个异步任务,修改name属性的值

    for (NSInteger i = 0; i < 10000; i++) {
        dispatch_async(dispatch_get_global_queue(0, 0), ^{
            self.name = [NSString stringWithFormat:@"name:%ld", I];
        });
    }
}
image.png

结果分析:
1、在MRC模式下,属性name的set方法如下:

-(void)setName:(NSString *)name{
    if (_name != name) {
        [_name release];
        [name retain];
        _name = name;
    }
}

2、虽然在ARC模式下不用写其set方法,但是在底层还是会走到这里
3、因为是多线程,且没有加锁保护,所以在一个线程走到[_name release]后,可能在另一个线程又一次去释放,这时候造成崩溃。
4、把name属性的nonatomic改成atomic就不会崩溃了,因为atomic加锁了,是安全的。

二、接着上步说用atomic就安全了,再进一步分析

number属性使用atomic修饰的

    _number = 0;
    dispatch_apply(10000, dispatch_get_global_queue(0, 0), ^(size_t index) {
        self->_number ++;
    });
    NSLog(@"_number:%d", _number);

执行结果:执行结果并不是10000,而且每次运行结果都不一样,即运行结果不可预见。
结果分析:

_number++等价于
 int temp = _number+1;
 _number = temp;

虽然atomic保证了number属性线程安全了,但是并不能保证temp变量的线程安全,又因为是多线程的,所以有可能同时执行多次 int temp = _number+1;才执行一次 _number = temp;导致结果每次都不同,而且结果不可预知。

这时候就可以知道为什么不用atomic了:因为atomic会耗性能,而且大部分情况下并不会保证线程安全。
什么时候可以用atomic呢:在最简单的,只有一个set时,简单的读写实例变量。
UIKIT不需要使用atomic:因为UIKIT是在主线程做的,不存在线程安全问题。

你可能感兴趣的:(崩溃集锦)