iOS：專案中疑難Crash問題集錦

iOS App執行中遇到Crash的情況相信大家都遇到過，開發和者測試中遇到了可能很方便的辦法就是直接拿著裝置連線一下，然後使用Xcode自帶的工具就可以解析出Crash地址了。對於線上App執行時的Crash收集也有很多好用的第三方工具，具有代表性的就是Crashlytics，通過打包時上傳dSYM檔案，收集到的Crash就可以解析為可讀的格式了。

儘管Crashlytics功能已經很強大了，統計出來的Crash資訊也足夠詳細，還是會有一些難纏的問題，例如程式直接就掛在main函式中，剩下的就是系統的呼叫了。下面就聊了一下我們App中遇到的幾個難纏的Crash：

1、多次彈出AlertView時存在的問題

在我們App中有一些地方因為業務會彈出一些二次確認框，當彈出AlertView時切換到後臺，接著再切到前臺，快速點選觸發二次確認操作，會再彈出一個AlertView，此時點選該AlertView後，之前已經彈出的AlertView會恢復出來，再點選程式就會Crash掉。在iPhone採用相同步驟驗證該問題，發現無法重現，每次程式切回前臺時，AlertView現場迅速恢復，由此可見該問題是iPad上才會存在。

正常情況下程式退到後臺時，系統會自動隱藏AlertView，等到下次程式切換到前臺時，如果退出前彈出了AlertView，系統會恢復該AlertView的展示。問題就出現在這兒，系統恢復AlertView的展示時是有延遲的，而非立即恢復。在此時如果再觸發先關時間，彈出新的AlertView，就會損壞中斷的現場，從而導致程式執行狀態出現異常，之後再操作可能就會Crash掉。

這個問題當時想到了兩種解決辦法：

a、在程式退到後臺之前就對彈出層做預設操作

b、程式中設定標誌，標識當前是否已經彈出AlertView，如果已經彈出，再操作時就不會再彈出AlertView

第一種方法，會存在一些問題，因為有些介面的AlertView彈出以後，點選預設操作可能會影響view層級，這樣從後臺再回來的時候現場介面發生變化，會給使用者造成不必要的困惑。

第二種方法，在Apps的基類裡面新增一個標記位，彈出AlertView時置為YES，關閉AlertView時置為NO。當前App如果已經彈出了AlertView，則後續操作不再觸發彈出AlertView的操作，這樣就能避免程式從後臺切回來時快速點選導致的Crash問題。

2、webview動畫引發的Crash問題

在執行自動化測試過程中，不規律的出現了幾次Crash，無法找到固定的重現步驟，Crash棧如下：

Crash棧咋一看，掛在系統的API呼叫上，再仔細看一下報EXC_BAD_ACESS錯誤，應該是物件被釋放後導致了野指標呼叫問題。仔細檢視Apps中呼叫到Webview的地方發現，使用方法沒什麼問題。網上搜尋了一下發現，該問題可能是由於webview在動畫中，持有者(VC)已經被釋放導致的。

解決辦法：在所有持有Webview的物件釋放前都新增了Webview的delegate置空操作。

在自動化測試中tableview，scrollview也遇到了Webview相似的問題，因此就在程式中相關地方都做了保護處理，之後自動化測試中該類問題沒有再出現過。

一點感想：拿到Crash棧，一看是掛在系統呼叫，估計就不想花時間解決了。有時候堅持一下，多看一會兒，多想一下，嘗試去Google上搜一下Crash資訊中的一些欄位，或許別人也有遇到過相同或者相似的問題，說不定得到啟發從而解決了一個看似沒法解決的問題。