依旧Block调用引起的内存泄露

@前面的文章讲到,在Block中用到self(self特指UIViewController),需要用__block或者__weak修饰(MRC与ARC的区别),因为Block调用会对其里面的对象引用计数加1,如果你不确定你调用的Block是否会产生循环引用的话,最好用__block或__weak修饰.当然,如果你确定并不会产生循环引用的情况,那你可以放心的self.  self. (~O(∩_∩)O~).

@自从知道了block容易产生内存泄露的情况,我在很长的一段时间内,只要用到了block,只要里面有self,我全部用__block修饰了(偷懒的做法),但是最近,即使我这样的写了,还是出现了内存泄露的情况,dealloc()一直不执行,找了很久,找了很久,全部都加了__block修饰,依旧泄露,最终发现问题是出现在一个属性上.

@先来看下面这段问题代码:

__block DNWThirdVideoSubclassViewController *otherSelf = self;
[_videoPlayView changeViewBackGround:^{

   [otherSelf pushDNWWedViewController:_thirdData.web_url];
}];

打了很多断点,测试出来问题就是出在这里,很多人可能会问,已经用__block修饰了,而且并没有出现self呀!请注意_thirdData这个属性,声明的时候是@property (nonatomic,retain)DNWThirdData *thirdData,它是被self所持有,一次释放操作是放在dealloc中,也就是self被释放,_thirdData也释放.在Block中,调用了_thirdData,虽然没有用self.thirdData,但是正如前面所说,它是被self持有,编译访问_thirdData时,会找到持有它的self,对其引用计数加1,所以这里就算没有用到self,self的引用计数也被加1了,这也说明并不是没显示的调用self就不会对其引用计数加1,这个错误真是让我郁闷了好久.接下来改正:[otherSelf
pushDNWWedViewController:otherSelf.thirdData.web_url];就OK了

@当然,还是得说明,如果你确定你的Block调用只是局部的或者不会发生循环引用的问题,那就不用考虑这些了.

@而我这个例子,changeViewBackGround这个Block是属性videoPlayView的属性,而videoPlayView又是self的属性,呗self持有,要等待self的释放才能释放,因为如果不用__block修饰,是一定会产生循环引用而导致内存泄露的问题

@最后套用一句:"具体问题具体分析啦!"

依旧Block调用引起的内存泄露

时间: 2024-08-04 13:51:51

依旧Block调用引起的内存泄露的相关文章

【转】performSelector延时调用导致的内存泄露

performSelector延时调用导致的内存泄露 转载:http://blog.csdn.net/wangqiuyun/article/details/7587929 前几天在给游戏做收尾测试时,发现了一个关于内存泄露的问题,一直没找着问题所在,经过反复调试和查找资料今天终于解决了,特此记录下来以免以后再犯! 关于objective-c的内存管理,我们都知道一个原则就是"谁创建,谁释放",换句话说,不是我们创建的,就不用我们去释放.但是实际上objective-c的内存管理远远没那

performSelector延时调用导致的内存泄露

关于objective-c的内存管理,我们都知道一个原则就是“谁创建,谁释放”,换句话说,不是我们创建的,就不用我们去释放.但是实际上objective-c的内存管理远远没那么简单,我的情况是这样的: 我在debug模式下面用CCLOG在dealloc函数里面输出一些信息,目的就是要检查场景的dealloc方法在replaceScene的 时候有没有被调用,按照子龙山人大哥的说法,如果场景切换的时候dealloc没有调用,说明你这个场景的内存有问题.有可能被某个对象retain了, 其retai

项目问题总结:Block内存泄露 以及NSTimer使用问题

BLock的内存泄露 在我们代码中关于block的使用可以说随处可见,第一次接触block的时候是关于UIView的块动画,那时觉得block的使用好神奇,再后来分析总结为block其实就是一个c语言函数,只是我们可以在任意处调用此函数.有了这样的理解我开始经常使用block.在做项目以后发现使用block竟然会引起内存泄露,于是开始自己调试研究block的内存管理问题. 普通的block使用(包括块动画) 这里有一个简单的block使用,在里面我们可以添加任何自己想进行的操作,大部分的使用也是

Swift - 内存泄露原因(循环强引用)及解决办法

Swift使用自动引用计数(ARC)来管理应用程序的内存使用.在大多是情况下,并不需要考虑内存的管理.当实例不再需要的时候,ARC会自动释放这些实例所使用的内存. 但ARC并不是绝对安全的.下面两种情况会发生内存泄露. 1,类实例之间的循环强引用 两个类实例都有一个强引用指向对方,这样的情况就是强引用循环,从而导致内存泄露. 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32

关于block的回调使用-防止内存泄露问题

block 一般用于回调,比方请求数据我们把asi封装好,仅仅用block调数据就方便很多 获取到得数据假设要给之加入数据,切记不能够使用self.(这个数组) 或者_(这个数组) addObject 这个函数 由于我们要在block内部改变外部变量,我们须要在使用blcok回调之前 声明 __weaktypeof(self) wekSelf = self;  (在这里我使用wekSelf) 在block回调代码段内 一切self(数组或者控件) 所有替换成wekSelf防止内存泄露. 呈现一段

UIActionSheet关闭动画过程中调用delegate = nil 导致的内存泄露

UIActionSheet在动画期间(ActionSheet button点击之后,到didDismissWithButtonIndex调用完成之前)设置delegate为空会导致delegate无法释放. 先来看个例子: 例子中创建一个UIActionSheet,并在按钮点击之后0.1秒(关闭动画结束前)设置delegate = nil. #import "LIViewController.h" @class UIActionSheetDelegateImpl; static UIA

Android内存泄露分析简要思路

工作中遇到挺多需要分析内存泄露问题的情况,现在大致简要写下思路,等之后时间相对比较充裕再进行补充. 1.明白内存泄露的判断依据? 个人总结为:持续增加,只增不减! 理解一下这8个字,配合几个命令和工具来确定一下你的应用是否存在内存泄露问题,这是很关键的,如果一开始就判断错误了,那么没有继续往下进行的理由. 命令如下: adb shell dumpsys meminfo 应用包名 [当然,比较粗略地话,可以用adb shell procrank] 这时候你可以看到一个内存使用情况表 而我们首先关注

android 内存泄露小计

1   今天在调试android 程序时候,发现即使程序退出了,发现还占用内存大概有15M.用MAT查看,经过多次GC操作,发现依旧是15.直觉告诉我,应该发生内存泄露了.然后利用MAT,查看Memory Leak.结果让我很吃惊,发现是InputMethodManager.这个对象一直引用着Context.也就是Activity,导致它无法释放内存.后来google 一下发现, 以下贴出解决办法,希望给遇到类似情况的人,提供帮助: @Override protected void onDest

深入Android内存泄露

深入内存泄露 Android应用的内存泄露,其实就是java虚拟机的堆内存泄漏. 1.知识储备 1.Java内存模型 相关内存对象模型,参照博客精讲Java内存模型 1) 寄存器(register).这是最快的保存区域,这是主要由于它位于处理器内部.然而,寄存器的数量十分有限,所以寄存器是需要由编译器分配的.我们对此没有直接的控制权,也不可能在自己的程序里找到寄存器存在的任何踪迹. (2) 堆栈(stack).在执行函数(方法)时,函数一些内部变量的存储都可以放在栈上面创建,函数执行结束的时候这