經歷————>感悟：
之後，我想這個就是我們需要借鑑的地方，雖然說這應該是產品考慮的問題。做開發的都知道，應用避免不了在某些特殊情況會出現崩潰，然而客戶就是上帝，為了維護好客戶，要給客戶最友好的提示，即使應用崩了，也要告訴使用者，給他們幾個選擇的餘地。
於是，我就在**裡面增加了崩潰監測，**如下：
nssetuncaughtexceptionhandler
(&uncaughtexceptionhandler
);//
監測崩潰！！！
void
uncaughtexceptionhandler(
n***ception
*exception)
} 然後如果萬一出現崩潰，就記錄下來 [[
nsuserdefaults
standarduserdefaults
]setbool
:yes
forkey
:@"exception"
];每次程式一啟動再去判斷有沒有這個崩潰，
[[nsuserdefaults
standarduserdefaults
]boolforkey
:@"exception"]//
判斷是否奔潰！！！
有的話再做版本公升級、清除快取、（讓後台處理之後）重新進入 等處理。。。這些在這裡就不詳說了
最後，別忘了清除本次的監測結果
[[nsuserdefaults
standarduserdefaults
]removeobjectforkey
:@"exception"
];//
取完要刪除掉
[[nsuserdefaults
standarduserdefaults
] synchronize];
IOS 網路監測
大部分的應用都與網路有關 如果你沒有網路監測 來監測是否連線網路 很容易讓背鍋 用法也特別的簡單 按照我下面的 二部曲 包你輕鬆過 2.第二部曲 使用方法 1 靜態 網路環境現在分三種 wifi 2g 3g 4g 無網路 所以 reachability 監測也是分三種 wifi reachabili...
IOS崩潰日誌
1.普通崩潰日誌 參考 1 程序資訊 incident identifier 30e46451 53fd 4965 896a 457fc11ad05f 崩潰報告的唯一識別符號 是與裝置標識相對應的唯一鍵值。雖然它不是真正的裝置識別符號，但也是乙個非常有用的情報 如果你看到100個崩潰日誌的crash...
iOS應用崩潰（三） 崩潰日誌
當我們在模擬器上除錯時，可能經常遇到下面的記憶體訪問錯誤 該錯誤是對乙個已經釋放的物件進行操作，定位如下 2 終端輸入 info malloc history 命令，即可得到堆疊資訊，從而分析具體問題所在 gdb info malloc history 0x12e4b0 3 也可輸入如下資訊 gdb...