近來，發現xcode的模擬器越來越不靠不住了，應用開發完，在模擬器上面各種流暢各種執行得飛起，但是安裝到真機之後，就崩潰了，是閃退啊！~~o(>_
為了迅速定位並解決問題，最終還是選擇了方法三，並且最終解決了問題。
從xcode7之後，真機除錯已經是沒有任何門檻了，我們只需要註冊乙個蘋果的開發者賬號即可以無證書也可以真機除錯，操作如下：
第一步、開啟xcode 選擇螢幕左上角xcode-> preferencese
至此，真機除錯的過程就搞好了，是不是比以前簡單多了
經過上面的真機除錯之後，發現我們的程式崩在了乙個方法裡，並且報錯 「thread 1:exc_bad_access(code=1,address=0x4000)」，這種錯誤通常是記憶體管理的問題，一般是訪問了已經釋放的物件導致的，可以開啟殭屍物件（zombie objects）來定位問題。
第一步：還是開啟xcode 選擇螢幕左上角xcode-> preferencese，不過我們這次是要設定一下輸出資訊，除錯的時候輸出更多的資訊，如下截圖，勾上：
第二步：再對環境變數進行設定：選單product > scheme > edit scheme
把紅色圈裡面的三個選項都勾上
開啟該選項後，程式在執行時，如果訪問了已經釋放的物件，則會給出較準確的定位資訊，可以幫助確定問題所在。
該功能的原理是，在物件釋放（retaincount為0)時，使用乙個內建的zombie物件，替代原來被釋放的物件。無論向該物件傳送什麼訊息（函式呼叫），都會觸發異常，丟擲除錯資訊。
記得在問題被修復後，關閉該功能！！
第三步：設定好後除錯程式，在輸出介面發現了-[cfstring retain]: message sent to deallocated instance錯誤日誌
到這裡，就已經很明顯看出來是什麼原因導致程式崩潰的了，然後再去分析**，靜下心來肯定能解決問題的了。
我這裡是因為向乙個空的nsstring型別傳送訊息導致崩潰的，但是這個問題只在ios9版本崩潰，ios10就沒問題，這個還值得深究。
為了能夠更加詳細地說明除錯殭屍物件，並定位到崩潰的原因，下面列出乙個簡單的例子來說明：
先建立乙個 debu**iewcontroller，然後裡面建立乙個陣列，然後釋放，在controller將要出現的時候，向該陣列傳送乙個訊息：
#import "debu**iewcontroller.h"
@inte***ce debu**iewcontroller ()
@end
@implementation debu**iewcontroller
/*定義乙個陣列*/
static nsmutablearray*array;
-(void)viewdidload
在我們意料之中，程式崩潰了，報錯資訊如下：
我們用lldb po我們的陣列array物件，同樣沒有返回
從上面標下劃線的地方，我們得到兩個主要的資訊：
開啟「終端」，輸入以下命令：
sudo malloc_history 21122 0x60008170cfd0
得到錯誤日誌，這樣就能定位到最後呼叫的那行**
就是我們上面的release釋放掉了array物件導致的。
使用xcode除錯殭屍物件
在寫obj c 的時候,殭屍物件是比較麻煩的問題.殭屍物件是指,提前釋放記憶體的物件.對於iphone mac程式來說,出現這個問題的原因一般有 2個,第一,程式設計師自己過早釋放記憶體,第二,使用了外部框架導致的.第一點很容易查出來,第二點來說,主要是因為外部框架一般會使用 autorelease...
iOS殭屍物件之研究
zombie objects物件研究 一 xcode 關閉arc project build settings 搜尋 automatic reference counting 設定為no 二 開啟 殭屍物件 選項 三 驗證 void viewdidload nsstring classname id...
IOS開源專案 殭屍來襲
殭屍來襲的畫面大家有沒有想過。那麼如果如何通過oc來實現呢。閒來無事寫了乙個開源專案放到github共享。下面一起分析一下核心 網上找來4張。每張裡面有8個殭屍。我們需要切圖來把8個殭屍放到乙個陣列中，然後使用陣列動畫。我們需要乙個殭屍類，下面有4個子類。每一種殭屍有自己的奔跑速度。這又涉及到繼承和...