知识点:可变数组的属性使用copy修饰的后果
问题
视频What's New in LLVM
中,从12:05的时间开始有个关于NSMutableArray可变数组属性的使用问题。
运行后报错图如下:
image
分析
self.photos的实际类型是 __NSMutable0,也就NSArray类型。没有addObject的方法。
进一步探讨
-
OC是门动态型语言,在编译阶段不会做类型检测。OC的内存管理是引用计数,在ARC环境下,属性@property的内存管理语义关键字有copy,weak,strong,asssin。在编译阶段,默认情况下编译器会生成一个成员变量、一个setter方法、一个getter方法。而在setter方法中,会根据内存管理语义做相应的引用计数相关的操作。当使用copy修饰属性时,在setter中实际操作是拷贝了一份不可变的类型对象。这样的话,即使是其是可变类型,在被赋值后,我们得到的是却是不可变类型的对象。
-
OC具有多态性,父类可以指向子类。对象最终类型会在运行期根据实例化对象确认。在运行时阶段其isa指向的是[NSArray Class]。那么当向self.photos发送一个addObject消息时,self.photos对象是接收不到这个消息的。因为addObject是NSArray的子类NSMutbleArray的方法。
-
属性语义多种:
- 原子性(Atomicity):原子性(atomic)、非原子性(nonatomic)
- Setter语义(Setter Semantics):strong,weak,copy,asssin
- 读写属性(Writability): readwrite/readonly
原子性是具有线程安全的,会在属性的setter方法内部加个一个自旋锁、而非原子性是不会在setter方法中加锁的,是非线程安全的。在小型设备的上,内存空间是有限的。给属性加自旋锁是非常消耗资源的。并且不一定说使用了原子性就能保证该属性线程安全。这个仅仅是在setter方法中是安全的,这也是atomic该做的事。如果绕开setter方法使用其他的方式给属性赋值,依然是不安全的,比如使用KVC。
- ARC下,属性的默认语义是:
- 基本数据:atomic、assgin、readwrite
- 普通的OC对象:atomic、strong、readwrite
在此情况下,实际编译器添加setter方法如下:
// ARC
- (void)setPhotos:(NSMutableArray<UIImage *> *)photos{
// 1. 开始加锁,非自然语言,这里不写代码了
_photos = [photos copy];
// 2. 加锁结束
}
那么得到的是个self.photos实际是NSArray类。
从上就发现了2个问题:属性就是使用了关键字atomic、copy修饰。那么这里会加锁并且得到NSArray类的self.photos。
相关概念:
- 自旋锁:当上一个线程的任务没有执行完毕的时候(被锁住),那么下一个线程会一直等待(不会睡眠),当上一个线程的任务执行完毕,下一个线程会立即执行。
- 自旋锁应用场景:
比较适合做一些不耗时的操作
解决
1、修改copy语义在setter中默认内容:
方式一:
手动重写setter方法,使用赋值前mutableCopy。如下,这样获取到的就是NSMutableArray类型的对象。
- (void)setPhotos:(NSMutableArray<UIImage *> *)photos{
_photos = [photos mutableCopy];
}
方式二:
使用关键字strong
修饰属性。我们得到的依然是可变类型。
- (void)setPhotos:(NSMutableArray<UIImage *> *)photos{
_photos = photos;
}
2、原子性修改:
使用:nonatomic,减少小型设备中性能消耗。