Xcode開發調試技巧總結

作者：Silver_Bullet 2013-04-18 10:19:40

斷點(Breakpoint)斷點是調試中非常重要的一個手段。由于在執行到某些代碼前需要執行許多其它代碼,不可能用單步跟蹤一條一條執行過來,這時只要在需要暫停的地方設置一個斷點,然后讓程序運行,當執行到這個斷點位置時不需要用戶干預就會暫停并返回集成調試程序.斷點必須位于可執行代碼行上,凡設置在注釋,空白行,變量說明上的都是無效的。

一、概述

1.掌握調試技巧，調試技術

最基本,最重要的調試手段包括:單步跟蹤,斷點,變量觀察等。

單步跟蹤(Step)所謂單步跟蹤是指一行一行地執行程序,每執行一行語句后就停下來等待指示,這樣你就能夠仔細了解程序的執行順序,以及當時的各種狀況。

斷點(Breakpoint)斷點是調試中非常重要的一個手段。由于在執行到某些代碼前需要執行許多其它代碼,不可能用單步跟蹤一條一條執行過來,這時只要在需要暫停的地方設置一個斷點,然后讓程序運行,當執行到這個斷點位置時不需要用戶干預就會暫停并返回集成調試程序.斷點必須位于可執行代碼行上,凡設置在注釋,空白行,變量說明上的都是無效的。另外,斷點既可以在設計狀態下設置也可以在運行調試狀態下設置。根據斷點調試找到錯誤處。在程序開發中，為了找到程序的bug，通常采用的一種調試手段，一步一步跟蹤程序執行的流程，根據變量的值，找到錯誤的原因。在需要調試的代碼斷設置斷點，然后按預設的快捷鍵步進。調試狀態運行程序,程序執行到有斷點的地方會停下來。

2.內存泄漏解釋

簡單的說就是申請了一塊內存空間，使用完畢后沒有釋放掉。它的一般表現方式是程序運行時間越長，占用內存越多，最終用盡全部內存，整個系統崩潰。由程序申請的一塊內存，且沒有任何一個指針指向它，那么這塊內存就泄露了。一般我們常說的內存泄漏是指堆內存的泄漏。堆內存是指程序從堆中分配的，大小任意的（內存塊的大小可以在程序運行期決定），使用完后必須顯示釋放的內存。應用程序一般使用malloc，realloc，new等函數從堆中分配到一塊內存，使用完后，程序必須負責相應的調用free或delete釋放該內存塊，否則，這塊內存就不能被再次使用，我們就說這塊內存泄漏了。

使用leaks工具幫助查看內存泄漏問題.在的XCode工具列，Run=>“Run with Perfromance Tool=>Leak 在iPhone程式開發中，使用NSLog直接在控制臺印出retainCount也是一個檢視內存泄漏的方法，但是的XCode提供了更方便的泄漏工具供開發者使用。 http://blog.csdn.net/cloudhsu/archive/2010/07/22/5754818.aspx （重要）

二、常見錯誤

1.Objective-C EXC_BAD_ACCESS

程序遇到 Bug 并不可怕，大部分的問題，通過簡單的 Log 或者代碼分析并不難找到原因所在。但是在 Objective-C 編程中遇到 EXC_BAD_ACCESS 問題的時候，通過簡單常規的手段很難發現問題。這篇文章，給大家介紹一個常用的查找 EXC_BAD_ACCESS 問題根源的方法。首先說一下 EXC_BAD_ACCESS 這個錯誤，可以這么說，90%的錯誤來源在于對一個已經釋放的對象進行release操作。 舉一個簡單的例子來說明吧，首先看一段Java代碼：

public class Test{ 
        public static void main(String[] args){ 
                String s = “This is a test string”; 
                s = s.substring(s.indexOf(“a”),(s.length())); 
                System.out.println(s); 
        } 
}

這種寫法在Java中很常見也很普遍，這不會產生任何問題。但是到了 Objective-C 中，就會出事，考慮這個程序：

#import <Foundation/Foundation.h> 
int main (int argc, c*****t char * argv[]) 
{ NSAutoreleasePool * pool = [[NSAutoreleasePool alloc] init]; 
NSString* s = [[NSString alloc]initWithString:@”This is a test string”]; 
        s = [s substringFromIndex:[s rangeOfString:@"a"].location];//內存泄露 
        [s release];//錯誤釋放 [pool drain];//EXC_BAD_ACCESS return 0; 
}

這個例子當然狠容易的看出問題所在，如果這段代碼包含在一個很大的邏輯中，確實容易被忽略。Objective-C 這段代碼有三個致命問題：1，內存泄露。2，錯誤釋放。3，造成 EXC_BAD_ACCESS 錯誤。

1，內存泄露。 NSString* s = [[NSString alloc]initWithString:@”This is a test string”]; 創建了一個 NSString Object，隨后的 s = [s substringFromIndex:[s rangeOfString:@"a"].location]; 執行后，導致創建的對象引用消失，直接造成內存泄露。

2，錯誤釋放。[s release]; 這個問題，原因之一是一個邏輯錯誤，以為 s 還是我們最初創建的那個 NSString 對象。第二是因為從 substringFromIndex:(NSUInteger i) 這個方法返回的 NSString 對象，并不需要我們來釋放，它其實是一個被 substringFromIndex 方法標記為 autorelease 的對象。如果我們強行的釋放了它，那么會造成 EXC_BAD_ACCESS 問題。

3，造成 EXC_BAD_ACCESS 錯誤。EXC_BAD_ACCESS。由于 s 指向的 NSString 對象被標記為 autorelease, 則在 NSAutoreleasePool 中已有記錄。但是由于我們在前面錯誤的釋放了該對象，則當 [pool drain] 的時候，NSAutoreleasePool 又一次的對它記錄的 s 對象調用了 release 方法，但這個時候 s 已經被釋放不復存在，則直接導致了 EXC_BAD_ACCESS問題。

那么，知道了 EXC_BAD_ACCESS 的誘因之一后，如何快速高效的定位問題？ 1: 為工程運行時加入 NSZombieEnabled 環境變量，并設為啟用，則在 EXC_BAD_ACCESS 發生時，XCode 的 C*****ole 會打印出問題描述。首先雙擊 XCode 工程中，Executables 下的可執行模組，在彈出窗口中，Variables to be set in the environment，添加 NSZombieEnabled，并設定為 YES，點擊選中復選框啟用此變量。這樣，運行上述 Objective-C 時會看到控制臺輸出： Untitled[3646:a0f] *** -[CFString release]: message sent to deallocated instance 0x10010d340 這條消息對于定位問題有很好的提示作用。但是很多時候，只有這條提示是不夠的，我們需要更多的提示來幫助定位問題，這時候再加入 MallocStackLogging 來啟用malloc記錄。當錯誤發生后，在終端執行： malloc_history ${App_PID} ${Object_instance_addr} 則會獲得相應的 malloc 歷史記錄，比如對于上一個控制臺輸出 Untitled[3646:a0f] *** -[CFString release]: message sent to deallocated instance 0x10010d340 則我們可以在終端執行結果如下：

2. _OBJC_CLASS_$_ errors 造成這個錯誤，存在兩種原因： 1.項目未添加一個 CoreData framework； 2.由于某個或某幾個.m文件沒有被標記（打鉤）的原因造成的；我的錯誤原因是第二種原因造成的，我的解決方法是將與服務器端沖突的幾個先在項目中刪除，然后再將刪除的文件重新拖拽到xcode中，注意在添加文件是要記得打鉤。如果再次運行發現Failed to upload *.app問題，首先請先關閉xcode，然后將項目的build目錄刪除，再次重新打開xcode，運行程序，問題解決。

3.下面的錯誤：主要是在程序中加了中文符號；而不是在英文下 ; 引起的錯誤 在編寫程序時，需要注意一定要在英文下編寫。

link.c:69: error: stray ‘\357’ in program
link.c:69: error: stray ‘\274’ in program
link.c:69: error: stray ‘\233’ in program
link.c:70: error: expected ‘;’ before ‘insert_elem’
link.c:70: error: stray ‘\357’ in program
link.c:70: error: stray ‘\274’ in program
link.c:70: error: stray ‘\233’ in program

三、iPhone 開發經驗教訓總結參考

所有的UI操作,都要切換到主線程中進行.否則,會發生莫名其妙的錯誤.在主線程中，runloop默認是開啟狀態的。非主線程中，如果要用到 runloop，必須手動開啟runloop。關于runloop知識。對于常見的 EXEC_BAD_ACCESS，EXC_BAD_INSTRUCTION，錯誤，一般都是因為訪問已經被release的對象造成的。尤其是在一個線程中訪問另外一個線程的autorelease庫中的對象，尤其要注意此類問題。嚴格遵守iphone 內存管理手冊,對于不是由你創建的對象,不要越權release,否則,可能會導致程序crash.有時,一些看起來非常嚴重的bug,在經過N過次努力,多種思路嘗試fix之后,再回頭分析bug產生的原因,你會發現,造成這個嚴重bug的原因,很可能是你違反了一個眾所周知的規則引起的.這個規則你非常清楚,熟悉,但就是在coding的時候,稍不留神違反了它.于是就帶來了災難性后果.除了面向對象的cocoa外，iphone編程不要忘記非面向對象的Core Foundation。面向對象庫里很多沒有的功能，可以嘗試在Core Foundation里找找。比如：RSA算法，MD5算法，SHA1算法，AES加密算法等，cocoa對象庫里并沒有相應的實現，但在core foundation里，均有相應的實現。NSString類里沒有的字符串編碼GBK，GB2312，GB18030等，在 CoreFoundation里，能找到相應的編碼。建立socket連接，獲得輸入流和輸出流時，也需要使用Core Foundation里的CFNetwork api。等等。通過設置NSZombieEnabled參數，有非常有效幫助解決內存釋放錯誤。在消除某個對象時，如果為該對象設置了delegate, 則需要先將delegate設成nil，這是一種良好的代碼習慣。

在3.0 的Simulator上使用Instruments 檢測內存泄漏時,無法看到函數名,只能看到一些地址指針.在3.1,3.1.2,3.1.3的simulator都正常,能夠正常地看到是在哪個函數中存在的內存泄漏.通過Nib文件加載viewcontroller的各種UI控件時時，在viewDidLoad函數里，viewController的控件才能使用。在viewcontroller的構造函數里，nib里的控件都還沒有完成鏈接構造呢。 iPhone程序崩潰不要著急。可以結合使用C*****ole和objc_exception_throw可以快速定位根源所在。在CFNetwork 中，有時候使用CFWriteStreamWrite方法寫數據時，會導致該現成被長久block住。

原因：在 CFWriteStream不能接受數據時，寫數據了。具體解決辦法：在CFSriteStream收到異步的 kCFStreamEventCanAcceptBytes通知時，再開始寫數據。此時可避免CFWriteStreamWrite導致線程被block 的情形。使用Eavesdrop 抓取網絡數據包。

在Iphone上有兩種讀取圖片數據的簡單方法: UIImageJPEGRepresentation和UIImagePNGRepresentation. UIImageJPEGRepresentation函數需要兩個參數:圖片的引用和壓縮系數.而UIImagePNGRepresentation只需要圖片引用作為參數.通過在實際使用過程中,比較發現: UIImagePNGRepresentation(UIImage* image) 要比UIImageJPEGRepresentation(UIImage* image, 1.0) 返回的圖片數據量大很多.譬如,同樣是讀取攝像頭拍攝的同樣景色的照片, UIImagePNGRepresentation()返回的數據量大小為199K ,而 UIImageJPEGRepresentation(UIImage* image, 1.0)返回的數據量大小只為140KB,比前者少了50多KB.如果對圖片的清晰度要求不高,還可以通過設置 UIImageJPEGRepresentation函數的第二個參數,大幅度降低圖片數據量.譬如,剛才拍攝的圖片, 通過調用UIImageJPEGRepresentation(UIImage* image, 1.0)讀取數據時,返回的數據大小為140KB,但更改壓縮系數后,通過調用UIImageJPEGRepresentation(UIImage* image, 0.5)讀取數據時,返回的數據大小只有11KB多,大大壓縮了圖片的數據量 ,而且從視角角度看,圖片的質量并沒有明顯的降低.因此,在讀取圖片數據內容時,建議優先使用UIImageJPEGRepresentation,并可根據自己的實際使用場景,設置壓縮系數,進一步降低圖片數據量大小.

責任編輯：閆佳明來源： cnblogs

iOS開發 Xcode調試