做了一段時間的iphone應用，感觸最深的就是對記憶體問題的處理，這個問題幾乎一直是自己在工作中必須要解決的，而最近這些日子則更是選入了記憶體的迷局之中。而我需要做的就是扒開雲霧見天日。
當然記憶體問題的產生原因是多樣的，同時也是我們必須在遇到了某種問題之後，才知道該怎樣去處理的，但是，曾經的經驗和他人的分享卻總是會對我們處理一些問題減少很多的工作量。而今天我想分享的就是一些關於iphone應用程式中遇到的一些記憶體處理的方法。
首先，單個應用測試沒有報記憶體問題，並不表示在集合中就不會存在記憶體問題。而且對iphone的記憶體問題最麻煩的也就在這裡，很多單個發布的應用程式，在被整合成為集合之後，記憶體問題就可能變得極其嚴重，而且隨著集合中加入的新專案的不斷增加，記憶體問題的嚴重性也迅速增加。所以，這裡需要保證的一點就是我們在做單個iphone程式時，應盡量做到：（1）分配和釋放一定要對應，比如alloc,retain,copy一定要與release或者autorelease相對應。這是減少記憶體問題的很基礎的一步，特別是對那些用有alloc功能的函式分配了記憶體，並做為了return的直的變數，我們也應盡量將其用autorelease或者其他可行的方式來釋放。保證了這一點，整合時，就要輕鬆的多。（2）對於那些在**中設定的delegate一定要將其置空。（3）對於nstimer物件一定要記得關掉，而且最好是採用條件式置空。如圖中**，對timer1先判斷其是否可用在決定是否將其置空。（4）對於那些定義的訊息中心的資料也要記得進行移除操作。
圖 1
接下來，最好採用build and analyze方式對其進行記憶體分析，把出現的記憶體分析中的記憶體警告也盡可能地解決掉。當然還應當盡可能處理掉所有的編譯警告。
這之後，就是在整合的專案中進行處理了，在這裡我們最好已開始就做好如下兩部操作。
- (void)didreceivememorywarning
- (void)dealloc
其中的省略號自己去處理，我們只關心兩句：nslog(@"didreceivememorywarning = %@",[[self class] description]);和nslog(@"dealloc = %@",[[self class] description]);千萬別小看了這兩句哦，這可以幫助我們在報了記憶體警告是讓我們檢測到在那些早已經被釋放掉的頁面是否留下了未處理的記憶體問題。以幫我們定位大致目標。
最後我們在必要的時候還可以採用leaks來幫助我們分析，採用這種比較花時間，所以我們應當盡量在正對某個具體的頁面無法處理時，在用他來幫助我們。對於出現在我們**中的某些具體的問題它甚至可以幫我們定位到具體位置，並標註出出錯率。具體使用就不介紹了。
iPhone應用程式委託
iphone的軟體棧有好幾層組成，而應用程式是位於棧裡面最高的抽象層，系統核心服務 作業系統層 則是位於最底層的。這中間還有 層 cocoatouch層 核心服務層等等 但一般在開發應用程式的過程中，與我們主要打交道的是gui框架和cocoatouch層所提供的物件導向抽象。cocoa的founda...
iphone應用程式結構
classes 源程式檔案 h m other sources main.m 等，不需要程式設計師修改 prefix.pch resources 介面檔案 xib 配置檔案 info.plist frameworks 鏈結的庫 targets 專案的不同target 資源 編譯配置不同 execut...
iPhone應用程式生命週期
int argc,char argv,nsstring principalclassname,nsstring delegateclassname 來獲取應用程式的控制代碼。2 從給定的應用程式委託類，初始化乙個應用程式委託。並把該委託設定為應用程式的委託，這裡就有如果傳入引數為nil，會呼叫函式訪...