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是在主线程做的，不存在线程安全问题。
网友评论