新手開發IOS的疑惑，待補充

 

1.Prefix.pch 是做什麼用的？

是一個加快編譯速度的工具。只有永遠不會變化或很少發生變化的標頭檔才能被添加到首碼檔案中。這樣做可以使架構的代碼提前編譯，並對所有類可見。但是，如果添加到首碼檔案中的標頭檔發生變化，那麼所有的代碼會被重新編譯，這也是為什麼只能向首碼檔案添加不變檔案的原因。

2.if((self = [super init])) 為什麼會這麼寫？

- (id) init{    if((self = [super init]))    {        //do init stuff here ...    }    return self;}

在 self = [super init] 的調用中，self被賦值為向父物件發送 init 訊息後的傳回值。如果你之前是一名C++程式員，看到這一幕一定會感到痛苦萬分。請不必太過沮喪。這行代碼錶示：在Objective-C中，我們必須手動調用父類的 init 方法，改操作不會自動完成。我們之所以用 self 來接受傳回值，是為了防止傳回值為 nil 的情況發生。

如果你無法很好的理解Objective-C程式員調用[super init]的方式，另一種方法也許能令你比較容易接受。這種方式基本上和上面的方法一樣，但它也是有別於傳統的寫法的：

- (id) init{    self = [super init];    if(self != nil)    {        //do init stuff here ...    }    return self;}

3.IOS目前版本的記憶體管理差異

iOS6.0以前版本

UIViewController 增加了 viewDidUnload 方法。該方法和 viewDIdLoad 相配對。當系統記憶體不足時，首先 UIViewController 的 didReceiveMemoryWarining 方法會被調用，而 didReceiveMemoryWarining 會判斷當前 ViewController 的 view 是否顯示在 window 上，如果沒有顯示在 window 上，則 didReceiveMemoryWarining 會自動將 viewcontroller 的view 以及其所有子  view全部銷毀，然後調用 viewcontroller 的 viewdidunload 方法。如果當前 UIViewController 的 view 顯示在 window 上，則不銷毀該 viewcontroller 的 view，當然，viewDidunload 也不會被調用了。

收到記憶體警告：調用 didReceiveMemoryWarning 內調用 super 的 didReceiveMemoryWarning 會將 controller 的 view 進行釋放。所以我們不能將controller的view再次釋放。
處理方法：

-(void)didReceiveMemoryWarning{    [super didReceiveMemoryWarning];//如沒有顯示在window上，會自動將self.view釋放。    // ios6.0以前，不用在此做處理，self.view釋放之後，會調用下面的viewDidUnload函數，在viewDidUnload函數中做處理就可以了。}-(void)viewDidUnload{    // Release any retained subviews of the main view.不包含self.view    [super viewDidUnload];    //處理一些記憶體和資源問題。}

但是到了IOS 6.0之後，這裡又有所變化，IOS 6.0記憶體警告的 viewDidUnload 被屏蔽，即又回到了IOS 6.0以前版本時期的記憶體管理方式。   

收到記憶體警告：調用 didReceiveMemoryWarning 內調用 super 的 didReceiveMemoryWarning 調只是釋放 controller 的 resouse，不會釋放view。
處理方法:

-(void)didReceiveMemoryWarning{    [super didReceiveMemoryWarning];//即使沒有顯示在window上，也不會自動的將self.view釋放。    // Add code to clean up any of your own resources that are no longer necessary.        // 此處做相容處理需要加上ios6.0的宏開關，保證是在6.0下使用的,6.0以前屏蔽以下代碼，否則會在下面使用self.view時自動載入viewDidLoad    if ([self.view window] == nil)// 是否是正在使用的視圖    {        // Add code to preserve data stored in the views that might be        // needed later.                // Add code to clean up other strong references to the view in        // the view hierarchy.        self.view = nil;// 目的是再次進入時能夠重新載入調用viewDidLoad函數。    }}

 

 4.訊息調度 @selector

 看到 @selector(...) 語句的時候可能覺得有些陌生，這在 Objective-C 中用來指定某個特定方法。關鍵在於，絕不能忘記函數後面的冒號！冒號告訴 Objective-C：“去找一個名為XXX的方
 法，這個方法有且只有一個參數”。如果忘記寫冒號，編譯器還是可以通過的，但是程式一運行就會發生崩潰。在 Debugger Console 視窗中，你會看到這樣的錯誤記錄檔：“unrecoginized  
 selector sent to instance...”。

 @selector(...) 中的冒號個數一定要與所指定的方法參數個數相同。例如：

- (void) example:(ccTime)delta sender:(id)sender flag:(bool)aBool

 那麼，對應的@selector語句就應該是:

@selector(example:sender:flag:);

 不論是在調度訊息時還是在其他情況下使用 @selector(...), 都需要注意一個很重要的問題：在預設情況下，如果方法名不存在，編譯器並不會報錯；但是，一旦程式運行時調用用了指向不存在的方法的 @selector 語句，應用程式就會立即崩潰。由於這個調用是在內部完成的，所以很難找到問題所在。好在，xcode可以設定來強制編譯器報錯。

 

5.#import與@class的區別

1.import會包含這個類的所有資訊，包括實體變數和方法，而@class只是告訴編譯器，其後面聲明的名稱是類的名稱，至於這些類是如何定義的，暫時不用考慮，後面會再告訴你。

2.在標頭檔中， 一般只需要知道被引用的類的名稱就可以了。 不需要知道其內部的實體變數和方法，所以在標頭檔中一般使用@class來聲明這個名稱是類的名稱。 而在實作類別裡面，因為會用到這個引用類的內部的實體變數和方法，所以需要使用#import來包含這個被引用類的標頭檔。

3.在編譯效率方面考慮，如果你有100個標頭檔都#import了同一個標頭檔，或者這些檔案是依次引用的，如A–>B, B–>C, C–>D這樣的參考關聯性。當最開始的那個標頭檔有變化的話，後面所有引用它的類都需要重新編譯，如果你的類有很多的話，這將耗費大量的時間。而是用@class則不會。

4.如果有循環相依性關係，如:A–>B, B–>A這樣的相互依賴關係，如果使用#import來相互包含，那麼就會出現編譯錯誤，如果使用@class在兩個類的標頭檔中相互聲明，則不會有編譯錯誤出現。

所以，一般來說，@class是放在interface中的，只是為了在interface中引用這個類，把這個類作為一個類型來用的。 在實現這個介面的實作類別中，如果需要引用這個類的實體變數或者方法之類的，還是需要import在@class中聲明的類進來.