顽兔crash总结
Crash引起的原因:release一个retainCount为0的对象,一般对象的引用计数控制不当,导致内存泄露,非常容易造成程序的crash,其他的像数组越界、1/0等这种也会引起crash。顽兔期间造成crash的原因总结了下:
引用计数:
顽图客户端里面没有用ARC,所有对象的引用计数都是我们自己控制的。
只有在alloc,copy,retain三种情况下的对象的引用计数才会加1,通过release,autorelease引用计数减1。
执行release会立即使得retainCount减1,一般确定不用的对象使用。
执行autorelease延时引用计数减1,该对象不会立即被释放,而是将该对象放到自动回收池中,当最近的一个pool被释放之后,该对象才会被执行dealloc释放,有些同学可能会说,那么可以都用autorelease来处理好了,一般不这样做,比如alloc一个很大的对象,或者你执行一个for循环,每个循环里面可能都alloc了一个值,处理完了又确定不需要,那么立即释放肯定会比较好。
属性赋值:
我们看下我们在.h文件中定义一个属性userName
@property (retain,nonatomic)NSString *userName;
这个语句是自动生成属性的get set方法的,我们看下这个属性的set方法
-(void)setUserName(NSString *)userName{
[userName retain];
[_userName release];
_userName = userName;
}
发现执行set方法的时候,属性加_userName的retainCount加1了。
赋值代码self.userName = @”tbtest93”;其实就是执行了userName的set方法,所以_userName的retainCount已经加1。
赋值代码_userName = @”tbtest93”;只是简单的引用赋值而已,它的引用计数没有加1,所以在它的retainCount还是0,在函数执行完成之后对象就dealloc掉了。其它地方引用就会出问题
其它:
@property的属性如果把retain设置成assgin,那么引用计数不会加1,只是简单的赋值
@property的属性nonatomic是非原子操作,在多线程情况下需要用atomic。而且默认为atomic,当有多个属性为atomic时候,每一个属性都是访问都会锁定整个对象。
在ios5之后,支持ARC之后又了Strong和week属性,strong和retain一样,但是week和assgin有点小区别,使用week之后,属性dealloc之后,它会把指针置为nil,你调用了它的一个方法,它也不会crash。assign则不会。
delegate:
之前碰到过一个问题,是由于delegate导致的内存溢出。
在顽兔新版本的WTOtherVC.m方法中,有个成员变量WTUserInfoView,并且它的引用类型是retain,而 WTUserInfoView 有个delegate方法,这个delegate的引用类型retain类型,看下WTOtherVC 里面的方法。
{
userInfoView.delegate = self;(WTUserInfoView retain住了这个WTOtherVC )
......................
self.userInfoView = userInfoView;(WTOtherVC retain住了这个WTUserInfoView )
}
这样就导致两个对象都释放不了,造成内存泄露。
看了下我们常用的tableView的delegate属性,它的引用类型也是assgin的,而不是retain,就是防止互相retain住。
viewDidunload:
在内存警告的情况下,会执行viewDidunload方法,在这个方法里面会当前被盖住的view给释放掉,如果处理不当,非常容易造成crash.一般我们会在viewDidunload里面把view设置为nil,self.xxxView=nil。一般在viewDidunload方法中不会去清空dataSource,因为下次viewDidload的时候,如果dataSource存在的话就没有必要在发起一次网络请求。
如果controller注册了NSNotification,那么返回的时候回调的方法如果没有view的相关处理,那么没有必要把这个NSNotification置为nil,但是如果对view有操作,那么必须把NSNotification给remove掉。同理Request也一样,如果回调方法没有涉及view的操作,那么Request没有必要置为nil,相反要设置为nil。一般我们都会在viewDidunload中把NSNotification,Request设置成nil。
Request:
如果你的view或者ViewController中发起了网络请求,那么你需要再viewDidunload和dealloc中把这个请求给cancel掉,因为在内存警告或者对象被释放掉时候,网络返回的数据找不到对应的处理方法,就会crash。
NSNotification:
如果你的ViewController 增加了一个Observer,那么你需要在viewDidunload和dealloc中把这个Observer移除掉,因为在内存警告或者对象被释放掉,post的notification找不到对应处理的方法,就会crash。
tableView:
tableView的delegate方法中,cell的个数或者dataSource中的数据处理不当,会导致数组越界,也容易发生crash.
Xib:我们大部分View都是用xib创建,在用xib拖拽属性到类中,会在dealloc方法里自动生成[xxx release],你重复拖的话,在dealloc里面也会重复生成[xxx release],这样就会导致一个对象在释放时重复被release,就会crash。建议在viewDidunload和dealloc方法里面把属性值统一设置为self.xxx=nil.
分享到:
相关推荐
一个无侵入的 iOS crash 防护框架
iOS Crash日志收集上报
2018秋招iOS面试总结 2018秋招iOS面试总结 2018秋招iOS面试总结 2018秋招iOS面试总结
Crash分析工具(Tool for analyse iOS Crash)
WOCrashProtector是一个无侵入的 iOS crash 防护框架,基于 Swizzle Method 的 Crash 防护。能有效的防止代码潜在的crash,自动在app运行时实时捕获导致app崩溃的破环因子,使app避免崩溃,照样可以继续正常运行。
iOS Crash日志-分析
ios 奔溃log 奔溃 左右摇动 进去奔溃log 分析,记录每次奔溃信息
iOS系统Crash文件分析方法参考.pdf
主要用于NSException 异常的捕捉,可以捕获对应的异常。
用symbolicatecrash工具分析iOS Crash文件
ios Crash闪退日志获取和上传至服务器
今天跟大家一起聊聊iOSCrash文件的几种分析方法,都是平时比较常用的,有需要的小伙伴可以参考下
IOS Crash Course 英文无水印pdf pdf所有页面使用FoxitReader和PDF-XChangeViewer测试都可以打开 本资源转载自网络,如有侵权,请联系上传者或csdn删除 本资源转载自网络,如有侵权,请联系上传者或csdn删除
IOS Crash的通用解决方法; 你还在位不能解决Crash问题而烦恼吗? 看这篇文章保证你再无忧虑, 用过,且能帮到你的,请给个好评,谢谢。
iOS开发中奔溃是非常恶心,但是我们如何能够做到Crash分析以及收集处理,恰恰体现了一个高质量iOS开发人员的能力!今晚Cooci老师从原理探索分析Crash的收集和处理,让APP起死回生!知识点:1-常见奔溃简析 2-...
一个无侵入的 iOS crash 防护框架,基于 Swizzle Method 的 Crash 防护。能有效的防止代码潜在的crash,自动在app运行时实时捕获导致app崩溃的破环因子,使app避免崩溃,照样可以继续正常运行。 主要参考了《大白...
iOS崩溃转储分析书本书HTML版本“ iOS崩溃转储分析”如下所示: 语关联英语 中国人 本书随附的是“分析故障排除”工作表。 可以从以下位置购买Kindle版本: , 和其他Amazon地理区域。 可以在以下位置购买平装印刷版...
工具详情请访问 http://godeyes.duapp.com/
iOS 分析crash工具,一键获取错误信息,位置定位相当精确
ios解析crash示例文件上传