iOS：項目中疑難Crash問題集錦

標籤：des   style   blog   http   color   io   os   ar   使用   

項目中疑難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 0x00000008Crashed Thread:  0Thread 0 name:  Dispatch queue: com.apple.main-threadThread 0 Crashed:0   libobjc.A.dylib               0x390b15b0 objc_msgSend + 161   UIKit                         0x33289182 -[_UIWebViewScrollViewDelegateForwarder forwardInvocation:] + 1382   CoreFoundation                0x31218616 ___forwarding___ + 6223   CoreFoundation                0x3116ff64 _CF_forwarding_prep_0 + 204   UIKit                         0x330d40c2 -[UIScrollView _getDelegateZoomView] + 985   UIKit                         0x330d3fc0 -[UIScrollView _zoomScaleFromPresentationLayer:] + 246   UIKit                         0x330d9fec -[UIWebDocumentView _zoomedDocumentScale] + 567   UIKit                         0x330d6ae8 -[UIWebDocumentView _layoutRectForFixedPositionObjects] + 1008   UIKit                         0x3327b292 -[UIWebDocumentView _updateFixedPositionedObjectsLayoutRectUsingWebThread:synchronize:] + 389   UIKit                         0x330dc6d4 -[UIWebDocumentView _updateFixedPositioningObjectsLayoutAfterScroll] + 2410  UIKit                         0x330dc6b0 -[UIWebBrowserView _updateFixedPositioningObjectsLayoutAfterScroll] + 5211  UIKit                         0x330dc566 -[UIWebDocumentView _restoreScrollPointForce:] + 50212  UIKit                         0x330dc25c -[UIWebDocumentView _resetForNewPage] + 40813  UIKit                         0x330a84c4 -[UIWebDocumentView layoutSubviews] + 7214  UIKit                         0x330217fe -[UIView(CALayerDelegate) layoutSublayersOfLayer:] + 25415  QuartzCore                    0x32dcbd86 -[CALayer layoutSublayers] + 21016  QuartzCore                    0x32dcb924 CA::Layer::layout_if_needed(CA::Transaction*) + 45617  QuartzCore                    0x32dcc858 CA::Layer::layout_and_display_if_needed(CA::Transaction*) + 1218  QuartzCore                    0x32dcc23e CA::Context::commit_transaction(CA::Transaction*) + 23419  QuartzCore                    0x32dcc04c CA::Transaction::commit() + 31220  UIKit                         0x330278e6 _afterCACommitHandler + 12221  CoreFoundation                0x311eb6ca __CFRUNLOOP_IS_CALLING_OUT_TO_AN_OBSERVER_CALLBACK_FUNCTION__ + 1822  CoreFoundation                0x311e99bc __CFRunLoopDoObservers + 27223  CoreFoundation                0x311e9d12 __CFRunLoopRun + 73824  CoreFoundation                0x3115ceb8 CFRunLoopRunSpecific + 35225  CoreFoundation                0x3115cd44 CFRunLoopRunInMode + 10026  GraphicsServices              0x34d262e6 GSEventRunModal + 7027  UIKit                         0x330722fc UIApplicationMain + 111628  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保留本文的一切權利

　　轉載請著名原文出處

　　本文在開發過程中隨時更新，歡迎交流

iOS：項目中疑難Crash問題集錦