IOS 關鍵字self,super,copy, retain, assign , readonly , readwrite, nonatomic、@synthesize、@property、@dynamic

#synthesize關鍵字: 根據@property設置,自動生成成員變量相應的存取方法,從而可以使用點操作符來方便的存取該成員變量 。

@implementation 關鍵字,表明類的實現 @end 結束

self 關鍵字 :類似于java中的this,是隱藏參數,指向當前調用方法的類。

super 關鍵字 :調用父類的方法。

self = [super init]? 這里不是判斷self與[super init]是否相等,而是判斷是否可以成功初始化。[super init]:父類初始化成功的話,通過=給self,這樣self成為一個非空對象,整個來說即非false(非NO)。

#import 告訴預處理器,將頭文件的內容包含到本文件中. OC 中的import 能保證頭文件只會被包含一次 .@interface關鍵字:聲明一個Student類。@end 結束聲明.

冒號:表示繼承 后面跟的是父類.

NSObject是大多數對象都會用到的內存管理,和初始化框架,以及反射和類型操作. 相 當于Object。

NS是NextSTEP縮寫,表示這個函數來自Cocoa工具包。

聲明全局變量 , 與C中一樣。

property關鍵字:設置成員變量的屬性(有讀/寫,賦值assign,retain,copy ,以及對多線程的支持nonatomic)。

聲明一個方法,格式是? –(返回值) 方法關鍵字1 : (參數類型)參數名 方法關鍵字2 : (參數類型)參數名 …… (在讀方法的時候就可以先找方法關鍵字來確定參數)。

- 減號是實例方法, + 是類方法

另一個初始化方法中調用已有的初始化方法? 這種概念被稱為Designated Initializer.

NSLog是OC中的標準輸出, 附加輸出當時日期, 時間, 應用程序名稱 . 使用NSLog()輸出任意對象的值時,都會使用%@格式說明。在使用這個說明符時,對象通過一個名為description的方法提供自己的NSLog()格式。

使用@property配合@synthesize可以讓編譯器自動實現getter/setter方法,使用的時候也很方便,可以直接使用“對象.屬性”的方法調用;如果我們想要”對象.方法“的方式來調用一個方法并獲取到方法的返回值,那就需要使用@property配合@dynamic了

使用@dynamic關鍵字是告訴編譯器由我們自己來實現訪問方法。如果使用的是@synthesize,那么這個工作編譯器就會幫你實現了。

readonly此標記說明屬性是只讀的,默認的標記是讀寫,如果你指定了只讀,在@implementation中只需要一個讀取器。或者如果你使用@synthesize關鍵字,也是有讀取器方法被解析。而且如果你試圖使用點操作符為屬性賦值,你將得到一個編譯錯誤。

readwrite此標記說明屬性會被當成讀寫的,這也是默認屬性。設置器和讀取器都需要在@implementation中實現。如果使用@synthesize關鍵字,讀取器和設置器都會被解析。

nonatomic:非原子性訪問,對屬性賦值的時候不加鎖,多線程并發訪問會提高性能。如果不加此屬性,則默認是兩個訪問方法都為原子型事務訪問。

atomic和nonatomic用來決定編譯器生成的getter和setter是否為原子操作。

atomic

設置成員變量的@property屬性時,默認為atomic,提供多線程安全。

在多線程環境下,原子操作是必要的,否則有可能引起錯誤的結果。加了atomic,setter函數會變成下面這樣:

{lock}

if (property != newValue) {

[property release];

property = [newValue retain];

}

{unlock}

nonatomic

禁止多線程,變量保護,提高性能。

atomic是Objc使用的一種線程保護技術,基本上來講,是防止在寫未完成的時候被另外一個線程讀取,造成數據錯誤。而這種機制是耗費系統資源的,所以在iPhone這種小型設備上,如果沒有使用多線程間的通訊編程,那么nonatomic是一個非常好的選擇。

指出訪問器不是原子操作,而默認地,訪問器是原子操作。這也就是說,在多線程環境下,解析的訪問器提供一個對屬性的安全訪問,從獲取器得到的返回值或者通過設置器設置的值可以一次完成,即便是別的線程也正在對其進行訪問。如果你不指定 nonatomic ,在自己管理內存的環境中,解析的訪問器保留并自動釋放返回的值,如果指定了 nonatomic ,那么訪問器只是簡單地返回這個值。

assign: 簡單賦值,不更改索引計數

對基礎數據類型 (例如NSInteger,CGFloat)和C數據類型(int, float, double, char, 等)? ? ? 適用簡單數據類型

此標記說明設置器直接進行賦值,這也是默認值。在使用垃圾收集的應用程序中,如果你要一個屬性使用assign,且這個類符合NSCopying協? ? ? ? ? ? 議,你就要明確指出這個標記,而不是簡單地使用默認值,否則的話,你將得到一個編譯警告。這再次向編譯器說明你確實需要賦值,即使它是? ? ? ? ? 可拷貝的。

copy:建立一個索引計數為1的對象,然后釋放舊對象? ? ? ? ? ? ? ? 對NSString

對NSString 它指出,在賦值時使用傳入值的一份拷貝。拷貝工作由copy方法執行,此屬性只對那些實行了NSCopying協議的對象類型有效。更深入的討論,請參考“復制”部分。

retain:釋放舊的對象,將舊對象的值賦予輸入對象,再提高輸入對象的索引計數為1

對其他NSObject和其子類

對參數進行release舊值,再retain新值

指定retain會在賦值時喚醒傳入值的retain消息。此屬性只能用于Objective-C對象類型,而不能用于Core Foundation對象。(原因很明顯,retain會增加對象的引用計數,而基本數據類型或者Core Foundation對象都沒有引用計數——譯者注)。

注意: 把對象添加到數組中時,引用計數將增加對象的引用次數+1。

retain的實際語法為:

- (void)setName:(NSString *)newName {

if (name != newName) {

[name release];

name = [newName retain];

// name’s retain count has been bumped up by 1

}

}

copy與retain:

Copy其實是建立了一個相同的對象,而retain不是:

比如一個NSString對象,地址為0×1111,內容為@”STR”

Copy到另外一個NSString之后,地址為0×2222,內容相同,新的對象retain為1,舊有對象沒有變化

retain到另外一個NSString之后,地址相同(建立一個指針,指針拷貝),內容當然相同,這個對象的retain值+1

也就是說,retain是指針拷貝,copy是內容拷貝。哇,比想象的簡單多了…

retain的set方法應該是淺復制,copy的set方法應該是深復制了

copy另一個用法:

copy是內容的拷貝? ,對于像NSString,的確是這樣.

但是,如果是copy的是一個NSArray呢?比如,

NSArray *array = [NSArray arrayWithObjects:@"hello",@"world",@"baby"];

NSArray *array2 = [array copy];

這個時候,,系統的確是為array2開辟了一塊內存空間,但是我們要認識到的是,array2中的每個元素,,只是copy了指向array中相對應元素的指針.這便是所謂的"淺復制".

assign與retain:

1. 接觸過C,那么假設你用malloc分配了一塊內存,并且把它的地址賦值給了指針a,后來你希望指針b也共享這塊內存,于是你又把a賦值給(assign)了b。此時a和b指向同一塊內存,請問當a不再需要這塊內存,能否直接釋放它?答案是否定的,因為a并不知道b是否還在使用這塊內存,如果a釋放了,那么b在使用這塊內存的時候會引起程序crash掉。

2. 了解到1中assign的問題,那么如何解決?最簡單的一個方法就是使用引用計數(reference counting),還是上面的那個例子,我們給那塊內存設一個引用計數,當內存被分配并且賦值給a時,引用計數是1。當把a賦值給b時引用計數增加到2。這時如果a不再使用這塊內存,它只需要把引用計數減1,表明自己不再擁有這塊內存。b不再使用這塊內存時也把引用計數減1。當引用計數變為0的時候,代表該內存不再被任何指針所引用,系統可以把它直接釋放掉。

總結:上面兩點其實就是assign和retain的區別,assign就是直接賦值,從而可能引起1中的問題,當數據為int, float等原生類型時,可以使用assign。retain就如2中所述,使用了引用計數,retain引起引用計數加1, release引起引用計數減1,當引用計數為0時,dealloc函數被調用,內存被回收。

NSString *pt = [[NSString alloc] initWithString:@"abc"];

上面一段代碼會執行以下兩個動作

1 在堆上分配一段內存用來存儲@"abc"? 比如:內存地址為:0X1111 內容為 "abc"

2 在棧上分配一段內存用來存儲pt? 比如:地址為:0Xaaaa 內容自然為0X1111

下面分別看下assign retain copy

assign的情況:NSString *newPt = [pt assing];

此時newPt和pt完全相同 地址都是0Xaaaa? 內容為0X1111? 即newPt只是pt的別名,對任何一個操作就等于對另一個操作。 因此retainCount不需要增加。

retain的情況:NSString *newPt = [pt retain];

此時newPt的地址不再為0Xaaaa,可能為0Xaabb 但是內容依然為0X1111。 因此newPt 和 pt 都可以管理"abc"所在的內存。因此 retainCount需要增加1

copy的情況:NSString *newPt = [pt copy];

此時會在堆上重新開辟一段內存存放@"abc" 比如0X1122 內容為@"abc 同時會在棧上為newPt分配空間 比如地址:0Xaacc 內容為0X1122 因此retainCount增加1供newPt來管理0X1122這段內存

//——————————————————————————

看了這么多也許大家有點暈, 現在進行實際的代碼演示:

@property (nonatomic, assign) int number;

這里定義了一個int類型的屬性, 那么這個int是簡單數據類型,本身可以認為就是原子訪問,所以用nonatomic,? 不需要進行引用計數,所以用assign。 適用于所有簡單數據類型。

@property (nonatomic, copy) NSString * myString;

這里定義了一個NSString類型的屬性,不需要原子操作,所以用nonatomic.

為什么需要copy,而不是retain呢! 因為如果對myString賦值原字符串是一個可變的字符串(NSMutableString)對象的話,用retain的話,當原字符串改變的時候你的myString屬性也會跟著變掉。我想你不希望看到這個現象。 實際上博主測試, 如果原來的字符串是NSString的話,也只是retain一下,并不會copy副本

@property (nonatomic, retain) UIView * myView;

這里定義了一個UIView類型的屬性,不需要原子操作,所以用nonatomic.

當對myView 賦值的時候原來的UIView對象retainCount會加1

//接口文件

@interface MyClass : NSObject

@property (nonatomic, assign)? int? ? ? ? ? ? ? number;

@property (nonatomic, copy)? NSString? * myString;

@property (nonatomic, retain) UIView? ? * myView;

@end

//實現文件

@implementation MyClass

@synthesize number;

@synthesize myString;

@synthesize myView;

//釋放內存

-(void) dealloc

{

[myString release];? //copy的屬性需要release;

[myView release];? ? //retain的屬性需要release;

[super dealloc]; //傳回父對象

}

@end

假如你有一段代碼創建了一個MyClass對象

MyClass * instance? = [MyClass alloc] init];

//number賦值,沒什么可說的, 簡單數據類型就這樣

instance.number = 1;

//創建一個可變字符串

NSMutableString * string = [NSMutableString stringWithString:@"hello"];

instance.myString = string;? ? ? ? ? ? ? ? ? //對myString賦值

[string appendString:@" world!"];? ? ? //往string追加文本

NSLog(@”%@”,string);? ? ? ? ? ? ? ? ? ? ? ? //此處string已經改變, 輸出為 “hello world!”

NSLog(@”%@”,instance.myString);? //輸出myString,你會發現此處輸出仍然為 “hello” 因為 myString在string改變之前已經copy了一份副本

UIView * view = [[UIView alloc] init];

NSLog(@”retainCount = %d”,view.retainCount);

//輸出view的引用計數, 此時為1

instance.myView = view; //對myView屬性賦值

NSLog(@”retainCount = %d”,view.retainCount);

//再次輸出view的引用計數, 此時為2,因為myView對view進行了一次retain。

[view release];

//此處雖然view被release釋放掉了,但myView對view進行了一次retain,那么myView保留的UIView的對象指針仍然有效。

[instance release] ;

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

推薦閱讀更多精彩內容