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

BLock的内存泄露

  在我们代码中关于block的使用可以说随处可见,第一次接触block的时候是关于UIView的块动画,那时觉得block的使用好神奇,再后来分析总结为block其实就是一个c语言函数,只是我们可以在任意处调用此函数。有了这样的理解我开始经常使用block。在做项目以后发现使用block竟然会引起内存泄露,于是开始自己调试研究block的内存管理问题。

普通的block使用(包括块动画)

这里有一个简单的block使用,在里面我们可以添加任何自己想进行的操作,大部分的使用也是如此

1 void (^Block)(int) = ^(int num){
2    //此处还可添加其他代码 ....
3    NSLog(@"int number is %d",num);
4 };

包括UIView的块动画也是如此使用,在这里我们定义了一个图像视图的位置及透明度的变化

1 [UIView animateWithDuration:2.0 animations:^(void){
2     smallImage.frame = CGRectMake(150, 80, 30, 30);
3 } completion:^(BOOL finished) {
4      smallImage.alpha = 0;

这些block操作中,我一直都认为block中的对象会在block使用后就被释放(但UIView的操作好像是这么做的)

block内存管理初现

  直到我在项目中遇见这样一个情况:我设置有2个控制器first及second,其中second中包含一个block对象,而block的实现是在first中实现(一般的block传值都是这么做)。而界面的推送是由first控制器push出second控制器。但当我second控制器pop的时候,问题出现second控制器不走delloc方法,即pop后second控制器还存在没有被销毁(因为当时要做delloc中做一些操作,才发现这个问题)!block示例代码如下:

first控制器中block的实现

1 SecondViewController *secondVC = [[SecondViewController alloc] init];
2 secondVC .block = ^(NSString *text){
3         self.text = secondVC.text;
4 };

  这么一个简单的传值block使用,居然能引起second控制器无法释放,于是研究其原理,并网上搜索资料,得出一个结论:second控制器在block中被持有一次才导致其无法释放。因为block本质上是一个函数,而编译器不知道你什么时候会调用block里面的值,所以为了确保编译器内secondVC不会被释放,编译器会自动对其进行一次持有(在自身类中使用block方法操作自身的成员属性也会使自己的引用计算加1,造成无法释放)。

其解决办法也简单 在外部添加一个弱引用对象指向需要在block中操作的对象,即__weak typeof(对象名) 别名= 对象名;

1 SecondViewController *secondVC = [[SecondViewController alloc] init];
2 __weak typeof(secondVC) second = secondVC;
3 __weak typeof(self) vc = self;
4 2 secondVC .block = ^(NSString *text){
5 3         vc.text = second.text;
6 4 };

这样就能够有效的防止block使用引起的内存泄露问题。

NSTimer使用问题

另外在还在项目中遇见一个关于NSTimer的使用问题。我们想到在控制器销毁时同时停止NSTimer并置为nil

1 -(void)dealloc {
2     [self.timer invalidate];
3     self.timer = nil;
4     NSLog(@"%@ dealloc", NSStringFromClass([self class]));
5 }

然而控制器被pop后并没有走此方法(又是内存泄露),由于之前出现了Block内存泄露的问题,我就想是不是因为这个_timer加载的时候对self进行了一次持有

_timer = [NSTimer scheduledTimerWithTimeInterval:1.0 target:self selector:@selector(timerUp:) userInfo:nil repeats:YES];

进行调试测验,果然是这里出了问题,因为其对控制器持有了一次。于是我想到既然这样那我干脆就在viewWillDisappear()中做个判断,如果是pop控制器,我就先设置[self.timer invalidate]操作这样控制器就会走dealloc()方法。后来再网上找资料发现了一个更简单的解决办法,即同Block的内存管理一样使用弱引用对象

1 __weak typeof(self) vc = self;
2 _timer = [NSTimer scheduledTimerWithTimeInterval:1.0 target:vc selector:@selector(timerUp:) userInfo:nil repeats:YES];

这样的解决办法就要比我之前的要简单多了,唯一需要注意的就是此处vc的作用域!

时间: 2024-12-28 20:47:04

项目问题总结:Block内存泄露 以及NSTimer使用问题的相关文章

使用MLeaksFinder检测项目内存泄露总结

前几天看到开源工具MLeaksFinder,决定用在公司的项目中试一下,效果很不错,用法也很简单,直接把项目文件夹拖到项目中就可以了,依靠这个项目,我发现公司项目中有不少内存泄露的地方,在此总结一下: 1.block中用引用外界对象一定要先__weak,否则容易引起循环引用; 2.对象中的delegate属性,不能用strong修饰,要使用weak; MLeaksFinder开源地址: https://github.com/Zepo/MLeaksFinder 想要知道如何使用的请参阅以下文章:

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

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

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

@前面的文章讲到,在Block中用到self(self特指UIViewController),需要用__block或者__weak修饰(MRC与ARC的区别),因为Block调用会对其里面的对象引用计数加1,如果你不确定你调用的Block是否会产生循环引用的话,最好用__block或__weak修饰.当然,如果你确定并不会产生循环引用的情况,那你可以放心的self.  self. (~O(∩_∩)O~). @自从知道了block容易产生内存泄露的情况,我在很长的一段时间内,只要用到了block,

【C++】小项目——内存泄露检测器

在C++中,指针往往忘记释放.引起内存泄露. 1.内存泄露指: 内存泄漏也称作"存储渗漏",用动态存储分配函数动态开辟的空间,在使用完毕后未释放,结果导致一直占据该内存单元.直到程序结束.(其实说白了就是该内存空间使用完毕之后未回收)即所谓内存泄漏. 内存泄漏形象的比喻是"操作系统可提供给所有进程的存储空间正在被某个进程榨干",最终结果是程序运行时间越长,占用存储空间越来越多,最终用尽全部存储空间,整个系统崩溃.所以"内存泄漏"是从操作系统的角度

在iOS上自动检测内存泄露

手机设备的内存是一个共享资源.应用程序可能会不当的耗尽内存.崩溃,或者遭遇大幅度的性能降低. Facebook iOS客户端有很多功能,并且它们共享同一块内存空间.如果任何特定的功能消耗过多的内存,就会影响到整个应用程序.这是可能发生的,比如,这个功能导致了内存泄露. 当我们分配了一块内存,并设置了对象之后,如果在使用完了之后忘记释放,这就会发生内存泄露.这意味着系统是无法回收内存并交予他人使用,这也最终意味着我们的内存将会逐渐耗尽. 在Facebook,我们有很多工程师在代码库的不同部分上工作

c++内存泄露检测与定义

对于一个c/c++程序员来说,内存泄漏是一个常见的也是令人头疼的问题.已经有许多技术被研究出来以应对这个问题,比如 Smart Pointer,Garbage Collection等.Smart Pointer技术比较成熟,STL中已经包含支持Smart Pointer的class,但是它的使用似乎并不广泛,而且它也不能解决所有的问题:Garbage Collection技术在Java中已经比较成熟,但是在c/c++领域的发展并不顺畅,虽然很早就有人思考在C++中也加入GC的支持.现实世界就是这

Android 源码系列之<十四>从源码的角度深入理解LeakCanary的内存泄露检测机制(下)

转载请注明出处:http://blog.csdn.net/llew2011/article/details/52958567 在上边文章Android 源码系列之<十三>从源码的角度深入理解LeakCanary的内存泄露检测机制(中)由于篇幅原因仅仅向小伙伴们讲述了在Android开发中如何使用LeakCanary来检测应用中出现的内存泄露,并简单的介绍了LeakCanary的相关配置信息.根据上篇文章的介绍我们知道LeakCanary为了不给APP进程造成影响所以新开启了一个进程,在新开启的

iOS学习之block总结及block内存管理(必看)

Block简介(copy一段) Block作为C语言的扩展,并不是高新技术,和其他语言的闭包或lambda表达式是一回事.需要注意的是由于Objective-C在iOS中不支持GC机制,使用Block必须自己管理内存,而内存管理正是使用Block坑最多的地方,错误的内存管理 要么导致return cycle内存泄漏要么内存被提前释放导致crash. Block的使用很像函数指针,不过与函数最大的不同是:Block可以访问函数以外.词法作用域以内的外部变量的值.换句话说,Block不仅 实现函数的

【转】VLD(Visual LeakDetector)内存泄露库的使用

转载自http://blog.csdn.net/fan_hai_ping/article/details/8023433 VLD简介 由于C/C++语言没有所谓的垃圾收集器,内存的分配和释放都需要程序员自己来控制,这会给C/C++程序员带来一定的困难.当您的程序越来越复杂时,它的内存管理也会变得越来越困难.内存泄漏.内存越界是最常见的内存问题之一. 内存泄漏如果不是很严重的话,在短时间内对程序不会造成太大的影响,而且在进程终止的时候,所有分配的内存都会释放掉.但是对于长时间运行的程序,其破坏力是