项目中疑难Crash问题集锦

时间 2019-12-14

标签项目疑难 crash 问题集锦繁體版

原文原文链接

iOS App运行中遇到Crash的状况相信你们都遇到过，开发和者测试中遇到了可能很方便的办法就是直接拿着设备链接一下，而后使用Xcode自带的工具就能够解析出Crash地址了。对于线上App运行时的Crash收集也有不少好用的第三方工具，具备表明性的就是Crashlytics，经过打包时上传dSYM文件，收集到的Crash就能够解析为可读的格式了。web

　　尽管Crashlytics功能已经很强大了，统计出来的Crash信息也足够详细，仍是会有一些难缠的问题，例如程序直接就挂在main函数中，剩下的就是系统的调用了。下面就聊了一下咱们App中遇到的几个难缠的Crash：app

一、屡次弹出AlertView时存在的问题函数

在咱们App中有一些地方由于业务会弹出一些二次确认框，当弹出AlertView时切换到后台，接着再切到前台，快速点击触发二次确认操做，会再弹出一个AlertView，此时点击该AlertView后，以前已经弹出的AlertView会恢复出来，再点击程序就会Crash掉。在iPhone采用相同步骤验证该问题，发现没法重现，每次程序切回前台时，AlertView现场迅速恢复，因而可知该问题是iPad上才会存在。工具

正常状况下程序退到后台时，系统会自动隐藏AlertView，等到下次程序切换到前台时，若是退出前弹出了AlertView，系统会恢复该AlertView的展现。问题就出如今这儿，系统恢复AlertView的展现时是有延迟的，而非当即恢复。在此时若是再触发先关时间，弹出新的AlertView，就会损坏中断的现场，从而致使程序运行状态出现异常，以后再操做可能就会Crash掉。oop

这个问题当时想到了两种解决办法：测试

a、在程序退到后台以前就对弹出层作默认操做动画

b、程序中设置标志，标识当前是否已经弹出AlertView，若是已经弹出，再操做时就不会再弹出AlertViewspa

第一种方法，会存在一些问题，由于有些界面的AlertView弹出之后，点击默认操做可能会影响view层级，这样从后台再回来的时候现场界面发生变化，会给用户形成没必要要的困惑。指针

第二种方法，在Apps的基类里面添加一个标记位，弹出AlertView时置为YES，关闭AlertView时置为NO。当前App若是已经弹出了AlertView，则后续操做再也不触发弹出AlertView的操做，这样就能避免程序从后台切回来时快速点击致使的Crash问题。rest

二、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信息中的一些字段，或许别人也有遇到过相同或者类似的问题，说不定获得启发从而解决了一个看似无法解决的问题。