項目中疑難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棧如下：
Exception Type: EXC_BAD_ACCESS (SIGSEGV)
Exception Codes: KERN_INVALID_ADDRESS at 0x00000008
Crashed Thread: 0
Thread 0 name: Dispatch queue: com.apple.main-thread
Thread 0 Crashed:
0 libobjc.A.dylib 0x390b15b0 objc_msgSend + 16
1 UIKit 0x33289182 -[_UIWebViewScrollViewDelegateForwarder forwardInvocation:] + 138
2 CoreFoundation 0x31218616 ___forwarding___ + 622
3 CoreFoundation 0x3116ff64 _CF_forwarding_prep_0 + 20
4 UIKit 0x330d40c2 -[UIScrollView _getDelegateZoomView] + 98
5 UIKit 0x330d3fc0 -[UIScrollView _zoomScaleFromPresentationLayer:] + 24
6 UIKit 0x330d9fec -[UIWebDocumentView _zoomedDocumentScale] + 56
7 UIKit 0x330d6ae8 -[UIWebDocumentView _layoutRectForFixedPositionObjects] + 100
8 UIKit 0x3327b292 -[UIWebDocumentView _updateFixedPositionedObjectsLayoutRectUsingWebThread:synchronize:] + 38
9 UIKit 0x330dc6d4 -[UIWebDocumentView _updateFixedPositioningObjectsLayoutAfterScroll] + 24
10 UIKit 0x330dc6b0 -[UIWebBrowserView _updateFixedPositioningObjectsLayoutAfterScroll] + 52
11 UIKit 0x330dc566 -[UIWebDocumentView _restoreScrollPointForce:] + 502
12 UIKit 0x330dc25c -[UIWebDocumentView _resetForNewPage] + 408
13 UIKit 0x330a84c4 -[UIWebDocumentView layoutSubviews] + 72
14 UIKit 0x330217fe -[UIView(CALayerDelegate) layoutSublayersOfLayer:] + 254
15 QuartzCore 0x32dcbd86 -[CALayer layoutSublayers] + 210
16 QuartzCore 0x32dcb924 CA::Layer::layout_if_needed(CA::Transaction*) + 456
17 QuartzCore 0x32dcc858 CA::Layer::layout_and_display_if_needed(CA::Transaction*) + 12
18 QuartzCore 0x32dcc23e CA::Context::commit_transaction(CA::Transaction*) + 234
19 QuartzCore 0x32dcc04c CA::Transaction::commit() + 312
20 UIKit 0x330278e6 _afterCACommitHandler + 122
21 CoreFoundation 0x311eb6ca __CFRUNLOOP_IS_CALLING_OUT_TO_AN_OBSERVER_CALLBACK_FUNCTION__ + 18
22 CoreFoundation 0x311e99bc __CFRunLoopDoObservers + 272
23 CoreFoundation 0x311e9d12 __CFRunLoopRun + 738
24 CoreFoundation 0x3115ceb8 CFRunLoopRunSpecific + 352
25 CoreFoundation 0x3115cd44 CFRunLoopRunInMode + 100
26 GraphicsServices 0x34d262e6 GSEventRunModal + 70
27 UIKit 0x330722fc UIApplicationMain + 1116
28 MyApp 0x0000fc60 main (main.m:15)
29 libdyld.dylib 0x394edb1c start + 0
Crash棧咋一看，挂在系統的API調用上，再仔細看一下報EXC_BAD_ACESS錯誤，應該是對象被釋放後導緻了野指針調用問題。仔細檢視Apps中調用到Webview的地方發現，使用方法沒什麼問題。網上搜尋了一下發現，該問題可能是由于webview在動畫中，持有者(VC)已經被釋放導緻的。
解決辦法：在所有持有Webview的對象釋放前都添加了Webview的delegate置空操作。
在自動化測試中tableview，scrollview也遇到了Webview相似的問題，是以就在程式中相關地方都做了保護處理，之後自動化測試中該類問題沒有再出現過。
一點感想：拿到Crash棧，一看是挂在系統調用，估計就不想花時間解決了。有時候堅持一下，多看一會兒，多想一下，嘗試去Google上搜一下Crash資訊中的一些字段，或許别人也有遇到過相同或者相似的問題，說不定得到啟發進而解決了一個看似沒法解決的問題。
注：smileEvday保留本文的一切權利
轉載請著名原文出處
本文在開發過程中随時更新，歡迎交流
![Android中Webview使用經驗總結[圖]](data:image/gif;base64,R0lGODlhAQABAIAAAP///wAAACwAAAAAAQABAAACAkQBADs=)