iOS引起内存延迟释放的N种可能和解决方法(附demo)
文章背景
在很多的时候 , 我们项目中的控制器会延迟释放 ,为了了解为什么会延迟释放和延迟释放的解决方式特制作了一个demo, 项目中延迟释放会带来很多问题, 因为延迟师范项目中的资源清理不敢放在dealloc 中 进行, 因为一旦延迟释放了, 可能存在已经在viewdidload 修改的变量, 被延迟释放的控制器将数据修改了
延迟释放的原因
根据苹果官方文档中对 NSAutoreleasePool 的描述，我们可知，在主线程的 NSRunLoop 对象（在系统级别的其他线程中应该也是如此，比如通过 dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0) 获取到的线程）的每个 event loop 开始前，系统会自动创建一个 autoreleasepool ，并在 event loop 结束时 drain 。我们推出一个控制器的时候 中创建的 autoreleased 对象就是被系统添加到了这个自动创建的 autoreleasepool 中，并在这个 autoreleasepool 被 drain 时得到释放。如果有定时器的任务没有执行完, 是不会调用drain的 , 知道定时器事件执行完, 才会调用drain 来释放控制器 ,如果定时器一致在行走, 对象是不释放的, 除非使用weak
本文所述的延迟释放情形在release 模式下也会存在延迟释放
image.png
延迟释放情形一)
dispatch_after , dispatch_after延时N秒, 控制器就会在N秒之后释放
dispatch_after(dispatch_time(DISPATCH_TIME_NOW, (int64_t)(10 * NSEC_PER_SEC)), dispatch_get_main_queue(), ^{
// for(int i = 0;i< 10;i++){
// [weakSelf requst:@"http://forspeed.onlinedown.net/down/YJPDFViewer2.0.zip"];
// }
// });
解决方案1) - weakSelf
// 方案一 weak 下 会 可以解决延迟释放
__weak typeof(self) weakSelf = self;
dispatch_after(dispatch_time(DISPATCH_TIME_NOW, (int64_t)(10 * NSEC_PER_SEC)), dispatch_get_main_queue(), ^{
for(int i = 0;i< 10;i++){
[weakSelf requst:@"http://forspeed.onlinedown.net/down/YJPDFViewer2.0.zip"];
}
});
解决方案2) weak strong
weak strong 的代码
#ifndef weakify
#if DEBUG
#if __has_feature(objc_arc)
#define weakify(object) autoreleasepool{} __weak __typeof__(object) weak##_##object = object;
#else
#define weakify(object) autoreleasepool{} __block __typeof__(object) block##_##object = object;
#endif
#else
#if __has_feature(objc_arc)
#define weakify(object) try{} @finally{} {} __weak __typeof__(object) weak##_##object = object;
#else
#define weakify(object) try{} @finally{} {} __block __typeof__(object) block##_##object = object;
#endif
#endif
#endif
#ifndef strongify
#if DEBUG
#if __has_feature(objc_arc)
#define strongify(object) autoreleasepool{} __typeof__(object) object = weak##_##object;
#else
#define strongify(object) autoreleasepool{} __typeof__(object) object = block##_##object;
#endif
#else
#if __has_feature(objc_arc)
#define strongify(object) try{} @finally{} __typeof__(object) object = weak##_##object;
#else
#define strongify(object) try{} @finally{} __typeof__(object) object = block##_##object;
#endif
#endif
#endif
// 方案2 weak strong 可以解决延迟释放 为加 weak strong 会延迟释放
// @weakify(self)
// dispatch_after(dispatch_time(DISPATCH_TIME_NOW, (int64_t)(10 * NSEC_PER_SEC)), dispatch_get_main_queue(), ^{
// @strongify(self)
// for(int i = 0;i< 10;i++){
// [self requst:@"http://forspeed.onlinedown.net/down/YJPDFViewer2.0.zip"];
// }
// });
延迟释放情形二)
这种定时器会引起延时释放 , 如果非repeat 的话 直到 5 秒之后才会释放 , 如果是repeat 的话 控制器 会一致导致控制器不释放
// 这种定时器会引起延时释放 , 如果非repeat 的话 直到 5 秒之后才会释放 , 如果是repeat 的话 控制器 会一致导致控制器不释放
// _timer = [NSTimer scheduledTimerWithTimeInterval:5 target:self selector:@selector(handleTimer:)
// userInfo:nil repeats:NO];
问题分析：
原因是 Timer 添加到 Runloop 的时候，会被 Runloop 强引用，然后 Timer 又会有一个对 Target 的强引用（也就是 self ）也就是说 NSTimer 强引用了 self ，导致 self 一直不能被释放掉，所以 self 的 dealloc 方法也一直未被执行.
知道了错误原因，就先查一下NSTimer的官方文档看看具体用法细节，发现NSTimer还有一个规则：（在哪个线程创建就要在哪个线程停止，否则会导致资源不能被正确的释放。）那么问题来了：如果我就是想让这个 NSTimer 一直输出，直到控制器 销毁才停止并且释放NSTimer。
问题关键：
问题的关键就在于 self 被 NSTimer 强引用了，如果能打破这个强引用，问题应该就能决了。
解决方案:
使用weaktimer, HWWeakTimer , 不仅可以避免循环引用, 还可以解决延迟释放
image.png
HWWeakTimer的源码在本文中的demo中
// 这里使用了weaktimer 之后 不管 是否repeat 控制器都可以及时的释放
_timer = [HWWeakTimer scheduledTimerWithTimeInterval:5 target:self selector:@selector(handleTimer:)
userInfo:nil repeats:YES];
延迟释放情形三)
此时准确的说控制器未被释放 是控制器被循环引用了, 这是一种很常见的情形, 此处不赘述
不会导致延迟释放但是会导致对象不释放的情形
// 这里的不会引起延迟释放 但是会导致 a 对象和b 对象不释放 , 当前的控制器对a b 对象无引用, 但是a b 对象内部会形成引用环
ClassA *a = [[ClassA alloc] init];
ClassB *b = [[ClassB alloc] init];
a.classb = b;
b.classa = a;
image.png
