iOS面試之定義NSString的屬性為什么要用copy修飾?什么情況下使用strong? 什么情況下使用copy?

在面試iOS程序員的時候,大家經常被問到的一個問題就是,在定義一個NSString類型的屬性時,為什么要用copy修飾?通常得到的回答都是,

“為了防止修改這個屬性時,會同時修改了原對象的值。”

我不知道這個結論他們是怎么得出來的,我只想說,錯,錯極了。

下面我就給大家解釋下為什么那么回答是錯的,直接上代碼。(文章最后有如何正確地回答這個問題,著急的同學可以直接翻到最后)

定義4個屬性

nameStrong為不用copy修飾的情況,nameCopy為用copy修飾的情況。normalName和mutableName為兩種原字符串。

@property (nonatomic, strong)   NSString         *nameStrong;    // 用strong修飾
@property (nonatomic, copy)     NSString         *nameCopy;      // 用copy修飾
@property (nonatomic, copy)     NSString         *normalName;    // 原字符串-不可變
@property (nonatomic, strong)   NSMutableString  *mutableName;   // 原字符串-可變

原字符串為不可變的情況

先說原字符串為不可變的情況,這種情況比較簡單。
給normalName賦值,并把normalName賦值給nameStrong和nameCopy,如下

    self.normalName     = @"1111";
    self.nameStrong     = self.normalName;
    self.nameCopy       = self.normalName;
    
    NSLog(@"\nnormalName: %@ - normalName地址: %p\nnameStrong: %@ - nameStrong地址: %p\nnameCopy: %@ - nameCopy地址: %p",
          self.normalName, _normalName, self.nameStrong, _nameStrong, self.nameCopy, _nameCopy);

打印結果為:

normalName: 1111 - normalName地址: 0x10c1a3220
nameStrong: 1111 - nameStrong地址: 0x10c1a3220
nameCopy: 1111 - nameCopy地址: 0x10c1a3220

你會發現,nameStrong和nameCopy同原字符串的地址是一樣的,所以值肯定也是一樣的。

如果對原字符串normalName進行改變呢?嚴謹來說,normalName為不可變類型,只能重新進行賦值,如下:

    self.normalName    = @"1111";
    self.nameStrong    = self.normalName;
    self.nameCopy      = self.normalName;
    
    NSLog(@"\nnormalName: %@ - normalName地址: %p\nnameStrong: %@ - nameStrong地址: %p\nnameCopy: %@ - nameCopy地址: %p",
          self.normalName, _normalName, self.nameStrong, _nameStrong, self.nameCopy, _nameCopy);
    
    self.normalName = @"2222";
    
    NSLog(@"\nnormalName: %@ - normalName地址: %p\nnameStrong: %@ - nameStrong地址: %p\nnameCopy: %@ - nameCopy地址: %p",
          self.normalName, _normalName, self.nameStrong, _nameStrong, self.nameCopy, _nameCopy);

打印結果為:

normalName: 1111 - normalName地址: 0x101a07220
nameStrong: 1111 - nameStrong地址: 0x101a07220
nameCopy: 1111 - nameCopy地址: 0x101a07220

normalName: 2222 - normalName地址: 0x101a07260
nameStrong: 1111 - nameStrong地址: 0x101a07220
nameCopy: 1111 - nameCopy地址: 0x101a07220

你會發現,nameStrong和nameCopy的地址并沒有發生變化,還是同最初normalName的地址是一樣的,所以值沒變,但normalName重新賦值后,地址發生了變化,指針指向了一塊新的地址。

結論:如果原字符串為不可變類型字符串,使用copy或strong修飾NSString效果是一樣的。

原字符串為可變的情況

之所以面試中會有這個問題,主要就是考慮到有這種情況。
給mutableName進行賦值,并把mutableName賦值給nameStrong和nameCopy,如下:

    self.mutableName    = [NSMutableString stringWithString:@"1111"];
    self.nameStrong     = self.mutableName;
    self.nameCopy       = self.mutableName;
    
    NSLog(@"\nmutableName: %@ - mutableName地址: %p\nnameStrong: %@ - nameStrong地址: %p\nnameCopy: %@ - nameCopy地址: %p",
          self.mutableName, _mutableName, self.nameStrong, _nameStrong, self.nameCopy, _nameCopy);

打印結果為:

mutableName: 1111 - mutableName地址: 0x604000258900
nameStrong: 1111 - nameStrong地址: 0x604000258900
nameCopy: 1111 - nameCopy地址: 0xa000000313131314

你會發現,三個屬性的值是一樣的,但nameStrong同mutableName指向的是同一塊地址,而nameCopy則是指向的一塊新的地址。那是因為在把mutableName賦值給nameCopy時,自動進行了深拷貝,把mutableName的內容復制了一份,并新開了一塊內存來存儲,然后讓nameCopy指向了這個新的地址。

如果對mutableName進行改變呢?如下:

    self.mutableName     = [NSMutableString stringWithString:@"1111"];
    self.nameStrong      = self.mutableName;
    self.nameCopy        = self.mutableName;
    
    NSLog(@"\nmutableName: %@ - mutableName地址: %p\nnameStrong: %@ - nameStrong地址: %p\nnameCopy: %@ - nameCopy地址: %p",
          self.mutableName, _mutableName, self.nameStrong, _nameStrong, self.nameCopy, _nameCopy);
    
    [self.mutableName appendString:@"aaaa"];

    NSLog(@"\nmutableName: %@ - mutableName地址: %p\nnameStrong: %@ - nameStrong地址: %p\nnameCopy: %@ - nameCopy地址: %p",
          self.mutableName, _mutableName, self.nameStrong, _nameStrong, self.nameCopy, _nameCopy);

打印結果為:

mutableName: 1111 - mutableName地址: 0x6000004453a0
nameStrong: 1111 - nameStrong地址: 0x6000004453a0
nameCopy: 1111 - nameCopy地址: 0xa000000313131314

mutableName: 1111aaaa - mutableName地址: 0x6000004453a0
nameStrong: 1111aaaa - nameStrong地址: 0x6000004453a0
nameCopy: 1111 - nameCopy地址: 0xa000000313131314

你會發現,nameStrong的值也被改變了,但nameCopy并沒改變。這就是為什么要使用copy的原因了。

如果是直接對mutableName進行賦值操作,則同normalName一樣,對strongName和copyName都不會有影響,只是改變的它自己,如下:

    self.mutableName     = [NSMutableString stringWithString:@"1111"];
    self.nameStrong      = self.mutableName;
    self.nameCopy        = self.mutableName;
    
    NSLog(@"\nmutableName: %@ - mutableName地址: %p\nnameStrong: %@ - nameStrong地址: %p\nnameCopy: %@ - nameCopy地址: %p",
          self.mutableName, _mutableName, self.nameStrong, _nameStrong, self.nameCopy, _nameCopy);
    
//    [self.mutableName appendString:@"aaaa"];
    self.mutableName = [NSMutableString stringWithString:@"2222"];

    NSLog(@"\nmutableName: %@ - mutableName地址: %p\nnameStrong: %@ - nameStrong地址: %p\nnameCopy: %@ - nameCopy地址: %p",
          self.mutableName, _mutableName, self.nameStrong, _nameStrong, self.nameCopy, _nameCopy);

打印結果為:

mutableName: 1111 - mutableName地址: 0x60400024e970
nameStrong: 1111 - nameStrong地址: 0x60400024e970
nameCopy: 1111 - nameCopy地址: 0xa000000313131314

mutableName: 2222 - mutableName地址: 0x60400024edf0
nameStrong: 1111 - nameStrong地址: 0x60400024e970
nameCopy: 1111 - nameCopy地址: 0xa000000313131314

同normalName情況一樣,不再解釋。

現在又有一個新的問題,如果為了防止自己被改變,必須要用copy修飾嗎?其實不是,你也可以用strong修飾它,但賦值的時候記得調用一下copy方法,比如我給nameStrong賦值時,調用copy方法,如下:

    self.mutableName    = [NSMutableString stringWithString:@"1111"];
    self.nameStrong     = [self.mutableName copy];
    self.nameCopy       = self.mutableName;
    
    NSLog(@"\nmutableName: %@ - mutableName地址: %p\nnameStrong: %@ - nameStrong地址: %p\nnameCopy: %@ - nameCopy地址: %p",
          self.mutableName, _mutableName, self.nameStrong, _nameStrong, self.nameCopy, _nameCopy);

打印結果為:

mutableName: 1111 - mutableName地址: 0x60000044ef40
nameStrong: 1111 - nameStrong地址: 0xa000000313131314
nameCopy: 1111 - nameCopy地址: 0xa000000313131314

你會發現,nameStrong的地址同mutableName的地址也不一樣了,nameStrong和nameCopy指向了同一塊新的地址。
雖然使用這種方式可以解決使用strong修飾的問題,但一般情況下定義屬性時直接使用copy修飾更方便。

結論

那應該怎么回答這個問題呢?我認為可以這樣回答:
為了防止在把一個可變字符串在未使用copy方法時賦值給這個字符串對象時,修改原字符串時,本字符串也會被動進行修改的情況發生。

Have fun!

最后編輯于
?著作權歸作者所有,轉載或內容合作請聯系作者
平臺聲明:文章內容(如有圖片或視頻亦包括在內)由作者上傳并發布,文章內容僅代表作者本人觀點,簡書系信息發布平臺,僅提供信息存儲服務。
  • 序言:七十年代末,一起剝皮案震驚了整個濱河市,隨后出現的幾起案子,更是在濱河造成了極大的恐慌,老刑警劉巖,帶你破解...
    沈念sama閱讀 228,119評論 6 531
  • 序言:濱河連續發生了三起死亡事件,死亡現場離奇詭異,居然都是意外死亡,警方通過查閱死者的電腦和手機,發現死者居然都...
    沈念sama閱讀 98,382評論 3 415
  • 文/潘曉璐 我一進店門,熙熙樓的掌柜王于貴愁眉苦臉地迎上來,“玉大人,你說我怎么就攤上這事。” “怎么了?”我有些...
    開封第一講書人閱讀 176,038評論 0 373
  • 文/不壞的土叔 我叫張陵,是天一觀的道長。 經常有香客問我,道長,這世上最難降的妖魔是什么? 我笑而不...
    開封第一講書人閱讀 62,853評論 1 309
  • 正文 為了忘掉前任,我火速辦了婚禮,結果婚禮上,老公的妹妹穿的比我還像新娘。我一直安慰自己,他們只是感情好,可當我...
    茶點故事閱讀 71,616評論 6 408
  • 文/花漫 我一把揭開白布。 她就那樣靜靜地躺著,像睡著了一般。 火紅的嫁衣襯著肌膚如雪。 梳的紋絲不亂的頭發上,一...
    開封第一講書人閱讀 55,112評論 1 323
  • 那天,我揣著相機與錄音,去河邊找鬼。 笑死,一個胖子當著我的面吹牛,可吹牛的內容都是我干的。 我是一名探鬼主播,決...
    沈念sama閱讀 43,192評論 3 441
  • 文/蒼蘭香墨 我猛地睜開眼,長吁一口氣:“原來是場噩夢啊……” “哼!你這毒婦竟也來了?” 一聲冷哼從身側響起,我...
    開封第一講書人閱讀 42,355評論 0 288
  • 序言:老撾萬榮一對情侶失蹤,失蹤者是張志新(化名)和其女友劉穎,沒想到半個月后,有當地人在樹林里發現了一具尸體,經...
    沈念sama閱讀 48,869評論 1 334
  • 正文 獨居荒郊野嶺守林人離奇死亡,尸身上長有42處帶血的膿包…… 初始之章·張勛 以下內容為張勛視角 年9月15日...
    茶點故事閱讀 40,727評論 3 354
  • 正文 我和宋清朗相戀三年,在試婚紗的時候發現自己被綠了。 大學時的朋友給我發了我未婚夫和他白月光在一起吃飯的照片。...
    茶點故事閱讀 42,928評論 1 369
  • 序言:一個原本活蹦亂跳的男人離奇死亡,死狀恐怖,靈堂內的尸體忽然破棺而出,到底是詐尸還是另有隱情,我是刑警寧澤,帶...
    沈念sama閱讀 38,467評論 5 358
  • 正文 年R本政府宣布,位于F島的核電站,受9級特大地震影響,放射性物質發生泄漏。R本人自食惡果不足惜,卻給世界環境...
    茶點故事閱讀 44,165評論 3 347
  • 文/蒙蒙 一、第九天 我趴在偏房一處隱蔽的房頂上張望。 院中可真熱鬧,春花似錦、人聲如沸。這莊子的主人今日做“春日...
    開封第一講書人閱讀 34,570評論 0 26
  • 文/蒼蘭香墨 我抬頭看了看天上的太陽。三九已至,卻和暖如春,著一層夾襖步出監牢的瞬間,已是汗流浹背。 一陣腳步聲響...
    開封第一講書人閱讀 35,813評論 1 282
  • 我被黑心中介騙來泰國打工, 沒想到剛下飛機就差點兒被人妖公主榨干…… 1. 我叫王不留,地道東北人。 一個月前我還...
    沈念sama閱讀 51,585評論 3 390
  • 正文 我出身青樓,卻偏偏與公主長得像,于是被迫代替她去往敵國和親。 傳聞我的和親對象是個殘疾皇子,可洞房花燭夜當晚...
    茶點故事閱讀 47,892評論 2 372

推薦閱讀更多精彩內容