标签：des style blog http color io os ar 使用
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保留本文的一切权利
转载请著名原文出处
本文在开发过程中随时更新，欢迎交流
标签：des style blog http color io os ar 使用
原文地址：http://www.cnblogs.com/smileEvday/p/iOSCrash.html
