「iOS」深拷贝和浅拷贝的区别

为什么要写这篇博客?
在iOS开发中,我们往往将copy和mutableCopy这两个OC的Api的意思来理解深浅拷贝。尚且不说苹果爸爸对两个Api所做的优化,浅显的把Api的copy和mutableCopy来和深浅拷贝画上等号,那真的就像被OC这座大山阻挡了外面的世界。
🙅‍♂️🙅

首先我们要明确,什么是拷贝?为什么要拷贝?
比如在Java中,除了基本数据类型之外,还存在类的实例对象这个引用数据类型。而一般的"="做赋值操作的时候。对于基本数据类型,实际上是拷贝他的值,但是对于对象而言,其实赋值的只是这个对象的引用,将原对象的引用传递过去,他们实际上还是指向同一个对象。

而深浅拷贝就是基于这个基础之上做的区分,如果在拷贝这个对象的时候,只对基本数据类型进行拷贝,而对引用数据类型之作引用传递,而没有真实的创建一个新的对象,则认为是浅拷贝。反之,在对数据进行拷贝的时候,创建了一个新的对象,并复制其内的成员变量,则认为是深拷贝。

其实,以上的解释在OC上同样适用。

首先我们要明确一点,不管是深浅拷贝,都会创建新的对象。这也是拷贝的意义所在。

那么iOS的同学有话要说~便搬出了如下的数据
对数组的实验如下:

NSArray *a1 = @[@"1",@"2",@"3",@"4"];
NSArray *a2 = a1.copy;
NSMutableArray *a3 = a1.mutableCopy;
NSArray *a4 = a3.copy;

NSLog(@"%p == %p == %p == %p",a1[0],a2[0],a3[0],a4[0]);
NSLog(@"%p == %p == %p == %p",a1,a2,a3,a4);

输出如下:

2018-12-07 14:17:00.341990+0800 CopyDemo[74771:1634466] 0x100002070 == 0x100002070 == 0x100002070 == 0x100002070
2018-12-07 14:17:00.342254+0800 CopyDemo[74771:1634466] 0x10052e800 == 0x10052e800 == 0x101869990 == 0x10052e090

对字符串的实验如下:

NSString *str1 = @"bob";
NSString *str2 = str1.copy;
NSString *str3 = str1.mutableCopy;
NSString *str4 = str3.copy;

NSLog(@"%p == %p == %p == %p",str1,str2,str3,str4);

输出如下:

2018-12-07 14:24:59.383537+0800 CopyDemo[74871:1640100] 0x100002060 == 0x100002060 == 0x100748b10 == 0x626f6235

分析一下:
NSString(非容器类型),str1和a2地址相同,说明没有创建新的对象,所以是浅拷贝。
a2和a3地址不一样,所以是深拷贝。
a3和a4地址不一样,所以是深拷贝。
便得出了下面的结论

非容器类型:

对象类型 不可变对象 可变对象
copy 浅拷贝 深拷贝
mutableCopy 深拷贝 深拷贝

NSArray(容器类型),a1和str2地址相同,说明没有创建新的对象,所以是浅拷贝。
str2和str3地址不一样,所以是深拷贝。
str3和str4地址不一样,所以是深拷贝。
便得出了下面的结论

容器类型:

对象类型 不可变对象 可变对象
copy 浅拷贝 深拷贝
mutableCopy 深拷贝 深拷贝

...当然根据以上的输出,得出以上结论也不意外。但是答案是错误的~正是因为很多人的认知停留在以上的结论,所以造成了很多人在实际开发中还是会有很多的问题。
比如有一次在iOS讨论群里有位同学发出了一下疑问:

1.jpg

他的问题是array2和array3写法有什么区别?对于数组来说,浅拷贝的意义是啥,有啥意义?

如果根据我们在上面得出的结论,确实会有和这位同学有意义的疑问。从地址输出来看引用和浅拷贝(copy)都是地址的引用,那数组的浅拷贝又有什么意义呢?

造成这些问题的根本原因是很多同学把OC的copy这个API和浅拷贝画上了等号。在OC中,对于字面量和数组编译器都是有优化操作的。所以对他们进行实验是根本体现不了我们想要观察深浅拷贝的区别。最合理的方式是写一个NSObject然后实现NSCopying协议。对非容器类型的观察应该用这样的对象而不是NSString。然后把这些对象扔到数组里,然后再去观察容器类型的copy和mutableCopy的区别。这才是在OC中去观察深浅拷贝的正确打开方式。

所以就有了如下的实验。。

创建Person类,有一个NSString类型的name和Son类型的son对象。实现了copy和mutableCopy协议。Son对象有NSString类型的name也实现了copy协议。

//================.h====================
@interface Son : NSObject<NSCopying>
@property (nonatomic, copy) NSString *name;
@end


@interface Person : NSObject<NSCopying,NSMutableCopying>
@property (nonatomic, copy) NSString *name;
@property (nonatomic, strong) Son *son;

- (instancetype)initWithName:(NSString *)name
                         Son:(Son *)son;
@end

//================.m====================

@implementation Son
- (id)copyWithZone:(NSZone *)zone
{
    Son *s = [[Son alloc] init];
    s.name = self.name.mutableCopy;
    return s;
}

- (id)mutableCopyWithZone:(NSZone *)zone
{
    Son *s = [[Son alloc] init];
    s.name = self.name.mutableCopy;
    return s;
}
@end

@implementation Person

- (instancetype)initWithName:(NSString *)name
                         Son:(Son *)son {
    if (self = [super init]) {
        self.name = name;
        self.son = son;
    }
    
    return self;
}

- (id)copyWithZone:(NSZone *)zone
{
    Person *p = [[Person alloc] init];
    p.name = self.name.copy;
    p.son = self.son.copy;
    return p;
}

- (id)mutableCopyWithZone:(NSZone *)zone
{
    Person *p = [[Person alloc] init];
    p.name = self.name.mutableCopy;
    p.son = self.son.copy;
    return p;
}
@end

具体的测试代码如下:

Son *s = [Son new];
s.name = @"jack";
Person *p = [[Person alloc] initWithName:@"bob" Son:s];
Person *p2 = p.copy;
Person *p3 = p.mutableCopy;
NSLog(@"%p == %p == %p",p,p2,p3);
NSLog(@"name isa:%p == %p == %p",p.name,p2.name,p3.name);
NSLog(@"Son isa:%p == %p == %p",p.son,p2.son,p3.son);

输出:

2018-12-07 16:48:49.050049+0800 CopyDemo[76533:1726380] 0x1005896e0 == 0x1005879c0 == 0x1005872c0
2018-12-07 16:48:49.050250+0800 CopyDemo[76533:1726380] name isa:0x100002068 == 0x100002068 == 0x626f6235
2018-12-07 16:48:49.050262+0800 CopyDemo[76533:1726380] Son isa:0x100550d40 == 0x100550d40 == 0x100588ee0
2018-12-07 16:48:49.050272+0800 CopyDemo[76999:1743990] Son.Name isa:0x100002068 == 0x100002068 == 0x6b63616a45

以上结果可以看到,无论是copy和mutableCopy,都创建了新的对象。那所谓的深浅拷贝的实质是对象内部属性是否拷贝。
可以看到在Person的copy实现中,name属性使用了copy,由于OC编译器的优化,所以浅拷贝前后属性地址相同。Son属性也使用了copy,由于Son是自定义对象,所以copy操作也创建了新的地址。Son对象内部name属性,在浅拷贝的时候使用了copy操作,所以地址相同。
在Person的MutableCopy实现中,name属性使用了mutableCopy,所以深拷贝前后属性地址不同,Son属性是对象类型,所以mutableCopy创建了新地址。Son对象内部的name,在深拷贝中用了mutableCopy去操作,所以创建了新的地址。

接下来我们把对象放入到数组:

Son *s1 = [Son new];
s1.name = @"jack";
Person *p1 = [[Person alloc] initWithName:@"bob" Son:s1];
Son *s2 = [Son new];
s2.name = @"rule";
Person *p2 = [[Person alloc] initWithName:@"lisa" Son:s2];
NSArray *a1 = @[p1,p2];
NSArray *a2 = a1.copy;
NSMutableArray *a3 = a1.mutableCopy;
NSArray *a4 = a3.copy;
NSMutableArray *a5 = a3.mutableCopy;
NSMutableArray *a6 = [[NSMutableArray alloc] initWithArray:a1 copyItems:YES];
NSLog(@"a1==%p a2==%p a3==%p a4==%p a5==%p a6==%p",a1,a2,a3,a4,a5,a6);
NSLog(@"a1[0]==%p a2[0]==%p a3[0]==%p a4[0]==%p a5[0]==%p a6[0]==%p",a1[0],a2[0],a3[0],a4[0],a5[0],a6[0]);

输出如下:

2018-12-08 09:53:52.387513+0800 CopyDemo[83327:2002823] a1==0x1028018a0 a2==0x1028018a0 a3==0x1028019a0 a4==0x102801c40 a5==0x102801c70 a6==0x102801f10
2018-12-08 09:53:52.387960+0800 CopyDemo[83327:2002823] a1[0]==0x1028004a0 a2[0]==0x1028004a0 a3[0]==0x1028004a0 a4[0]==0x1028004a0 a5[0]==0x1028004a0 a6[0]==0x1006000c0

第一个输出说明了,对数组进行copy可以看到对NSArray的copy并没有创建新地址,所以可以同理猜想编译器对NSArray做了和NSString相同的优化。数组的mutableCopy创建了新地址,mutableArray的copy和mutableCopy都创建了新地址。
第二组输出可以看到数组中的元素地址全部相同,也就是说无论是copy还是mutableCopy,都只拷贝了数组容器(不考虑编译器优化)。所以使用OC中的copy和mutableCopy实际都是浅拷贝。OC有一个==[[NSMutableArray alloc] initWithArray:arr1 copyItems:YES]==方法可以进行深拷贝操作(见a6的输出)。

对于自定义对象来说,深浅拷贝的意义在于对象的属性是否创建新的对象。对于数组来说深浅拷贝的意义在于数组内元素是否被拷贝。

深浅拷贝的应用场景

在iOS开发中,我们经常会遇到需要维护一个全局id唯一的对象池。比如我们在开发一个小说app,我们可以每次都通过一个id去服务器请求,去刷新本地数据。也可以去维护一个全局的book对象池,这样,即便服务器不下发,我们本地也可以有最全的数据,但是如果一处接口服务器更新,全局的UI都得跟着被更新。所以我们在每个页面的book对象都应该是book对象池的浅拷贝。但是这样做并不是特别的好。因为当业务量大,开发人员多,就会造成一个人对某个对象的错误修改而影响了全局。所以在很多状态和响应流的设计框架里都引入了不可变编程的概念。。保持不可变的要求就是一旦数据变化那就必须是深拷贝。只影响下游数据,而不影响上游数据。在这种程度上来讲,其实每个页面去重新构造数据是一个更好的选择。一旦遵循这个思想,就可以避免一些破坏性编程带来的危害。

最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 199,711评论 5 468
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 83,932评论 2 376
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 146,770评论 0 330
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 53,799评论 1 271
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 62,697评论 5 359
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 48,069评论 1 276
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 37,535评论 3 390
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 36,200评论 0 254
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 40,353评论 1 294
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 35,290评论 2 317
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 37,331评论 1 329
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 33,020评论 3 315
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 38,610评论 3 303
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 29,694评论 0 19
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 30,927评论 1 255
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 42,330评论 2 346
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 41,904评论 2 341