iOS知識小集之NSString(轉)

原文?

廢話不多說症脂,原文文字描述的非常詳細句占,本文重在代碼實現,及個人觀點總結溪胶。

1搂擦、NSString屬性什么時候用copy,什么時候用strong?
這一點我的想法沒有什么出彩的地方就直接copy一下原話:

由于NSMutableString是NSString的子類哗脖,所以一個NSString指針可以指向NSMutableString對象盾饮,讓我們的strongString指針指向一個可變字符串是OK的。

而上面的例子可以看出,當源字符串是NSString時丘损,由于字符串是不可變的普办,所以,不管是strong還是copy屬性的對象徘钥,都是指向源對象衔蹲,copy操作只是做了次淺拷貝

當源字符串是NSMutableString時呈础,strong屬性只是增加了源字符串的引用計數舆驶,而copy屬性則是對源字符串做了次深拷貝,產生一個新的對象而钞,且copy屬性對象指向這個新的對象沙廉。另外需要注意的是,這個copy屬性對象的類型始終是NSString臼节,而不是NSMutableString撬陵,因此其是不可變的。

這里還有一個性能問題网缝,即在源字符串是NSMutableString巨税,strong是單純的增加對象的引用計數,而copy操作是執(zhí)行了一次深拷貝粉臊,所以性能上會有所差異草添。而如果源字符串是NSString時,則沒有這個問題扼仲。

所以远寸,在聲明NSString屬性時,到底是選擇strong還是copy屠凶,可以根據實際情況來定而晒。不過,一般我們將對象聲明為NSString時阅畴,都不希望它改變倡怎,所以大多數情況下,我們建議用copy贱枣,以免因可變字符串的修改導致的一些非預期問題监署。

關于字符串的內存管理,還有些有意思的東西纽哥,可以參考NSString特性分析學習钠乏。
這里跳轉的一篇博文非常有意思,主要說明的就是NSString初始化是調用的方法春塌,導致生成的變量內存地址問題晓避,和本文的copy簇捍、strong有異曲同工之妙。


再說一句廢話俏拱,一般情況下暑塑,對于代碼里面的變量NSString,我們并不需要淺拷貝锅必,而且在代碼邏輯不嚴謹的時候會出現各種各樣奇怪的問題事格,所以更贊成copy。

帖一段代碼:

@interface TestStringClass ()

@property (nonatomic, strong) NSString *strongString;

@property (nonatomic, copy) NSString *copyedString;

@end

調用:

- (void)test {

NSString *string = [NSString stringWithFormat:@"abc"];

self.strongString = string;

self.copyedString = string;

NSLog(@"origin string: %p, %p", string, &string);

NSLog(@"strong string: %p, %p", _strongString, &_strongString);

NSLog(@"copy string: %p, %p", _copyedString, &_copyedString);

}

結果:

origin string: 0x7fe441592e20, 0x7fff57519a48

strong string: 0x7fe441592e20, 0x7fe44159e1f8

copy string: 0x7fe441592e20, 0x7fe44159e200

分析:

strong和copy屬性的對象搞隐,其指向的地址都是同一個驹愚,即為string指向的地址。如果我們換作MRC環(huán)境劣纲,打印string的引用計數的話逢捺,會看到其引用計數值是3,即strong操作和copy操作都使原字符串對象的引用計數值加了1癞季。

把string由不可變改為可變對象:

NSString *string = [NSString stringWithFormat:@"abc"];

改為->

NSMutableString *string = [NSMutableString stringWithFormat:@"abc"];

結果:

origin string: 0x7ff5f2e33c90, 0x7fff59937a48

strong string: 0x7ff5f2e33c90, 0x7ff5f2e2aec8

copy string: 0x7ff5f2e2aee0, 0x7ff5f2e2aed0

copy屬性字符串已不再指向string字符串對象劫瞳,而是深拷貝了string字符串,并讓_copyedString對象指向這個字符串余佛。在MRC環(huán)境下,打印兩者的引用計數窍荧,可以看到string對象的引用計數是2辉巡,而_copyedString對象的引用計數是1。

這就是一般代碼的邏輯蕊退,所以說copy很適合一般人

最后編輯于
?著作權歸作者所有,轉載或內容合作請聯(lián)系作者
  • 序言:七十年代末郊楣,一起剝皮案震驚了整個濱河市,隨后出現的幾起案子瓤荔,更是在濱河造成了極大的恐慌净蚤,老刑警劉巖,帶你破解...
    沈念sama閱讀 222,946評論 6 518
  • 序言:濱河連續(xù)發(fā)生了三起死亡事件输硝,死亡現場離奇詭異今瀑,居然都是意外死亡,警方通過查閱死者的電腦和手機点把,發(fā)現死者居然都...
    沈念sama閱讀 95,336評論 3 399
  • 文/潘曉璐 我一進店門橘荠,熙熙樓的掌柜王于貴愁眉苦臉地迎上來,“玉大人郎逃,你說我怎么就攤上這事哥童。” “怎么了褒翰?”我有些...
    開封第一講書人閱讀 169,716評論 0 364
  • 文/不壞的土叔 我叫張陵贮懈,是天一觀的道長匀泊。 經常有香客問我,道長朵你,這世上最難降的妖魔是什么各聘? 我笑而不...
    開封第一講書人閱讀 60,222評論 1 300
  • 正文 為了忘掉前任,我火速辦了婚禮撬呢,結果婚禮上伦吠,老公的妹妹穿的比我還像新娘。我一直安慰自己魂拦,他們只是感情好毛仪,可當我...
    茶點故事閱讀 69,223評論 6 398
  • 文/花漫 我一把揭開白布。 她就那樣靜靜地躺著芯勘,像睡著了一般箱靴。 火紅的嫁衣襯著肌膚如雪。 梳的紋絲不亂的頭發(fā)上荷愕,一...
    開封第一講書人閱讀 52,807評論 1 314
  • 那天衡怀,我揣著相機與錄音,去河邊找鬼安疗。 笑死抛杨,一個胖子當著我的面吹牛,可吹牛的內容都是我干的荐类。 我是一名探鬼主播怖现,決...
    沈念sama閱讀 41,235評論 3 424
  • 文/蒼蘭香墨 我猛地睜開眼,長吁一口氣:“原來是場噩夢啊……” “哼玉罐!你這毒婦竟也來了屈嗤?” 一聲冷哼從身側響起,我...
    開封第一講書人閱讀 40,189評論 0 277
  • 序言:老撾萬榮一對情侶失蹤吊输,失蹤者是張志新(化名)和其女友劉穎饶号,沒想到半個月后,有當地人在樹林里發(fā)現了一具尸體季蚂,經...
    沈念sama閱讀 46,712評論 1 320
  • 正文 獨居荒郊野嶺守林人離奇死亡茫船,尸身上長有42處帶血的膿包…… 初始之章·張勛 以下內容為張勛視角 年9月15日...
    茶點故事閱讀 38,775評論 3 343
  • 正文 我和宋清朗相戀三年,在試婚紗的時候發(fā)現自己被綠了扭屁。 大學時的朋友給我發(fā)了我未婚夫和他白月光在一起吃飯的照片透硝。...
    茶點故事閱讀 40,926評論 1 353
  • 序言:一個原本活蹦亂跳的男人離奇死亡,死狀恐怖疯搅,靈堂內的尸體忽然破棺而出濒生,到底是詐尸還是另有隱情,我是刑警寧澤幔欧,帶...
    沈念sama閱讀 36,580評論 5 351
  • 正文 年R本政府宣布罪治,位于F島的核電站丽声,受9級特大地震影響,放射性物質發(fā)生泄漏觉义。R本人自食惡果不足惜雁社,卻給世界環(huán)境...
    茶點故事閱讀 42,259評論 3 336
  • 文/蒙蒙 一、第九天 我趴在偏房一處隱蔽的房頂上張望晒骇。 院中可真熱鬧霉撵,春花似錦、人聲如沸洪囤。這莊子的主人今日做“春日...
    開封第一講書人閱讀 32,750評論 0 25
  • 文/蒼蘭香墨 我抬頭看了看天上的太陽瘤缩。三九已至喇完,卻和暖如春,著一層夾襖步出監(jiān)牢的瞬間剥啤,已是汗流浹背锦溪。 一陣腳步聲響...
    開封第一講書人閱讀 33,867評論 1 274
  • 我被黑心中介騙來泰國打工, 沒想到剛下飛機就差點兒被人妖公主榨干…… 1. 我叫王不留府怯,地道東北人刻诊。 一個月前我還...
    沈念sama閱讀 49,368評論 3 379
  • 正文 我出身青樓,卻偏偏與公主長得像牺丙,于是被迫代替她去往敵國和親则涯。 傳聞我的和親對象是個殘疾皇子,可洞房花燭夜當晚...
    茶點故事閱讀 45,930評論 2 361

推薦閱讀更多精彩內容