iOS中的卡顿及crash的原因及解决办法

ios发现ANR或者crash排查的方法和需要哪些相关的信息，对于发现偶现的ANR和Crash应该如何做到避免影响到线上用户

ANR即（application not responding），即应用无响应。Crash 即程序崩溃。这两种情况的发生会给用户不友好的体验。在应用发布之前应尽量避免。所以在开发的过程中如何对这两种情况做到查漏补缺，主要有以下这些方案。

ANR：程序为何会出现“无响应”的状态。在iOS应用中，所有的UI操作及更新都是在主线程完成，并且主线程的runloop是逐个处理用户事件的（当然其他的runloop也一样），所以主线程必须等待上一次事件处理完成后才能继续响应下一次事件。绝大部分用户感知到的卡顿就是由于主线程阻塞了，在处理某次事件消耗了过长的时间，导致主线程处于等待状态，无法及时响应用户的下一次输入事件。由于iOS 上的 UIKit 只能在主线程进行处理，导致开发者在开发过程中不经意间在主线程做了一些消耗时间的工作，导致了应用卡顿。

避免卡顿的黄金法则就是不要让主线程干重活，例如网络请求，读写大文件，复杂的运算 等一些耗费大量系统资源及时间的任务。充分利用好 iOS 的多线程，如 NSThread、NSO peration Queue，GCD 等干脏活，累活，让主线程能及时迅速的响应用户事件。

Crash是用户使用应用的过程中最糟糕的体验，也是程序员最深恶痛绝的BUG。然而，每位程序员都免不了接触crash事件。应用Crash的产生主要有以下原因：

1.调用悬浮指针

2.数组越界访问

3.调用了未实现的方法

4.调用的库函数版本高于本机

5.返回空cell

6.类释放时未remove通知，之后收到通知

7.类释放时delegate未置空，之后被回调

8.使用nil做初始化操作，例如：

NSString*str =nil;



NSDictionary*dic =@{@"name":@"emma",@"age":str};

再如：

[NSString strWithFormat:nil];

9.NSRange访问越界，例如：

NSString *str = @"abcedfh";

NSRange range = NSMakeRange(5, 9);

[str substringWithRange:range];

10.对象对应关系异常。例如a实例removeObserver一个非a类关联的监听对象。

11.delegate先于tableview被置空，后收到关于table或者scroll的调用.

12.系统内存不足。

对于Crash的解决也都不同，一般必现的Crash可以通过对代码仔细的阅读辅以断点调试几乎都可以找出来。对于隐藏较深的Crash问题可以通过以下手段。

A ： 企业内部测试阶段：找到发包时的.ipa文件以及打包时archive生成的.dSYM文件以及应用使用过程中产生的.crash文件。通过对这三个文件的解析。可以查看应用程序具体的崩溃原因，以及崩溃什么地方。

B：应用已经安装到用户手机中，此时的crash可以通过一些第三方的工具进行获取，常用的有Bugly、Testin、友盟等。但是需要在研发的过程中将这些第三方的SDK集成到自己的代码中。

如果线上程序出现Crash的问题，首先要做的是定位BUG产生的原因。

1、如果是服务端返回的异常数据没做兼容，就由服务端确保格式正确，客户端看情况是否要做兼容；

2、如果是升级版本后的由于本地数据库或本地存储的数据格式未兼容等问题，一般需要撤下版本重新提交；

3、如果是业务代码中只是简单的数组越界之类，就很适合使用热修复技术，比如JSPatch，但是前提是已经发布的版本集成过热修复模块，否则也要重新发布版本。