iOS Debug 和 release(hoc 及App Store)版本Crash錯誤總結

在iOS開發過程當中，咱們常常會碰到莫名其妙的crash，而後咱們又很難定位到。
Debug版本：當咱們遇到EXC_BAD_ACCESS crash錯誤，頗有多是因爲咱們引用的對象被釋放，或者方法不存在，沒法調用，這是因爲內存操做錯誤引發的crash。當沒法定位錯誤時，咱們引入NSZombieEnabled模式。設置了NSZombieEnabled後，一個對象銷燬時會被轉化爲 _NSZombie，設置NSZombieEnabled後，當你向一個已經釋放的對象發送消息，這個對象就不會向以前那樣Crash或者產生 一個難以理解的行爲，而是放出一個錯誤消息，而後以一種可預測的能夠產生debug斷點的方式消失， 所以咱們就能夠找到具體或者大概是哪 個對象被錯誤的釋放了。在XCODE 中設置NSZombieEnabled模式。點擊菜單欄Product->Scheme->Edit Scheme->run->Argument->Environment variables ->+ 添加NSZombieEnabled 設爲YES 從新運行。

 

---

ps：在應用發佈時，記得去掉這一選項。

或者勾選Diagnostics選項中Enable Zombie Objects 

---

 

當咱們遇到SIGNAL SIGABRT等錯誤時候，咱們可使用斷點，斷點能夠分爲條件斷點及異常斷點。斷點的做用很是重要，它可以幫咱們查看應用程序在給定時間點上的所在位置。
條件斷點，顧名思義是指只會在特定條件下觸發的斷點：

異常斷點。當咱們遇到異常狀況crash的時候，系統通常都會自動指向主方法中。當咱們添加了異常斷點後，就會再引起問題的地方中斷。

 

Release 版本：程序的異常當咱們處於調試階段，經過上面方法通常都能過定位到錯誤。那當咱們用發佈app store版本或者分發版本 出現異常閃退的時候應該怎麼定位錯誤呢？

你們在項目中通常都會加入log日誌，我使用的是友盟的錯誤日誌。當用戶使用咱們的應用crash時，友盟日誌會收集這些錯誤信息，這樣咱們就能夠經過dysm文件去定位到錯誤位置。

dysm文件是咱們編譯後會自動生成的，它是保存16進制函數地址映射信息的中轉文件，咱們調試的symbol 都在這文件中。這個文件很重要，咱們每次發佈版本都會保存對應.xcarchive文件。有了這個文件咱們就能夠在發佈版中定位用戶使用奔潰時的信息，而不須要經過該用戶的設備log信息。那究竟應該怎麼經過錯誤信息去定位呢？
下面介紹我使用umeng的錯誤日誌定位錯誤：
one step 咱們打開友盟的錯誤日誌。dsym uuId <Universally unique identifer>咱們須要找到咱們對應的.archives 的文件

dsym uuid  : dwarfdump --uuid xx.app.dSYM

app uuid :dwarfdump --uuid xx.app/xx

和錯誤文件中uuid 把.app 文件和dYSM 文件放到同一目錄 一致咱們就能夠查詢了：

xcrun atos -arch armv7 -o Wherecom.app/Wherecom 0x2a32f 亦能夠用dwarfdump 命令查詢

這樣咱們就能夠定位到可能引發的錯誤函數名了。

網上也有熱心的網友就這些命令寫成了Mac工具附上下載地址， 可是仍是建議你們經常使用命令 熟悉這些常見的命令.