iOS中NSString的strong、copy的使用

       iOS开发中关于内存的管理有两种,一种是基于ARC(Automatic Reference Counting)环境下的,另一种是MRC(Mannul Reference Counting)。这两种模式可以在工程中的Build Settings选项下设置,可参照下图所示:


ARC/MRC.png

说明:设置为Yes是ARC环境下,设置为NO是MRC环境下。


       进入正题,我们在声明一个NSString类型的属性时,会遇到这样的一个问题。就是应该使用strong呢?还是应该用copy呢?下面我们通过具体的代码来分析一下两者的区别跟用法。

操作:
       首先我们先声明两个不同的字符串属性,用来做比对,代码如下:

@interface ViewController ()
@property(nonatomic,strong) NSString *theStrongStr; //strong 字符串
@property(nonatomic,copy) NSString *theCopyStr;     //copy 字符串
@end

       theStrongStr的内存特性是strong,theCopyStr的内存特性是copy,以便我们区分。


       创建下面两个方法testString,testMutabelString:

-(void)testString{
    NSLog(@"-------------NString--------------");
    //创建一个不可变源字符串
    NSString *originStr = @"iOS";
    //初始化strong字符串
    self.theStrongStr = originStr;
    //初始化copy字符串
    self.theCopyStr = originStr;
    
    //打印字符串指向的地址,已经对应的内存地址
    NSLog(@"the origin string:%p, %p",originStr,&originStr);
    
    NSLog(@"the strong string:%p, %p",_theStrongStr,&_theStrongStr);
    
    NSLog(@"the copy string:%p, %p",_theCopyStr,&_theCopyStr);
    
}

-(void)testMutabelString{
    NSLog(@"-------------NSMutableString--------------");
    //创建一个可变源字符串
    NSMutableString *originStr = [NSMutableString stringWithFormat:@"iOS"];
    //初始化strong字符串
    self.theStrongStr = originStr;
    //初始化copy字符串
    self.theCopyStr = originStr;
    
    //打印字符串指向的地址,已经对应的内存地址
    NSLog(@"the origin string:%p, %p",originStr,&originStr);
    
    NSLog(@"the strong string:%p, %p",_theStrongStr,&_theStrongStr);
    
    NSLog(@"the copy string:%p, %p",_theCopyStr,&_theCopyStr);
}

       在viewDidLoad里调用这个两个方法:

- (void)viewDidLoad {
    [super viewDidLoad];
    [self testString];
    [self testMutabelString];
}

       运行看到输出的结果如下:

iOSCopyAndStrong[1076:1312388] -------------NString--------------
iOSCopyAndStrong[1076:1312388] the origin string:0x109eff098, 0x7fff55d00958
iOSCopyAndStrong[1076:1312388] the strong string:0x109eff098, 0x7fb0a2c55050
iOSCopyAndStrong[1076:1312388] the copy string:0x109eff098, 0x7fb0a2c55058
iOSCopyAndStrong[1076:1312388] -------------NSMutableString--------------
iOSCopyAndStrong[1076:1312388] the origin string:0x7fb0a2f79d50, 0x7fff55d00958
iOSCopyAndStrong[1076:1312388] the strong string:0x7fb0a2f79d50, 0x7fb0a2c55050
iOSCopyAndStrong[1076:1312388] the copy string:0xa00000000534f693, 0x7fb0a2c55058


testString:
       在testString方法里我们使用的原字符串string是一个不可变的字符串。在这种情况下,我的可以看到我们创建的strong特性的对象,跟copy特性的对象,它们所指向的地址都是同一个地址0x109eff098,也就是我们使用的不可变字符串NSString *originStr = @"iOS";它所指向的地址。我们可以开启MRC模式,打断点调试,查看当前定义这个不可变字符串originStr的引用计数,可以发现执行完操作后self.theStrongStr = originStr;self.theCopyStr = originStr;,originStr的引用计数发生了改变1->3。每次执行都使原来的字符串originStr对象的引用计数+1。

testMutabelString:
       在testMutabelString方法里面我们使用的原字符串string是一个可变的字符串NSMutableString *originStr = [NSMutableString stringWithFormat:@"iOS"];。可以看到输出结果,使用strong特性的对象仍然指向原字符串originStr的地址,而使用copy特性的对象,所指向的是一个新的地址。其实就是copy特性的对象对原字符串originStr进行了深考贝,并指向了这个这个新的地址。我们开启MRC模式,打断点调试,查看到在执行操作后,originStr对象的引用计数1->2,而_theCopyStr对象的引用计数为1。这也就验证copy创建了一个新对象的说法。
       在testMutabelString方法中,不管我们如何修改originStr字符串,_theStrongStr所指向的地址也是跟着originStr字符串指向的地址变动的,这也就证明了_theStrongStr的类型实际上是可变类型NSMutableString,而不是NSString。同理_theCopyStr是指向一个新创建的对象,是不可以改变的。


归纳总结:
       当原字符串是NSString类型时,由于它是不可变类型的,不管是使用strong特性,还是copy特性的对象,它们所指向的地址都跟原字符串是一样的,都指向原字符串对象。也就是说当原字符串是NSString类型时,copy特性的操作,只是做了一次浅拷贝,只是增加了指针指向原字符串所指向的地址。

       当原字符串是NSMutableString类型时,strong特性对象只是增加了原字符串的引用计数,但是copy特性对象则是对原字符串进行了深拷贝,创建了一个新对象,并且指向了这个新对象。此时,copy特性对象是NSString类型的不可变的,strong特性对象是NSMutableString类型的可变的。

       关于在声明NSString属性时,我们是要选择strong特性,还是选择copy特性,是需要通过开发过程中的实际情况来选择的。但是我们在大多数情况下,在生命NSString属性时,都是希望其不被改变,防止数据出错。所以大多数情况下还是选择copy特性,从而来避免一些无法预估的bug。在补充一下,当原字符串是NSMutableString类型,也就是可变类型的时候,strong特性操作只是增加了原字符串的引用计数,而copy特性操作则是进行深拷贝,所以在copy会耗费更多的内存资源跟性能。而对NSString类型不可变的,就不会有这种问题,但是基于现在这么强大的手机处理器性能,这些应该也不是什么大问题。

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

推荐阅读更多精彩内容