优化内存泄漏的几点分析

很久很久没有写过文章了,割的时间有点长了,长的都让我忘却了学习.这里用小锤锤锤一下自己,咋就不知道学习啦!

好了废话不多说:导致内存泄漏的几点原因(不全面,请在回复区补充)

1.关于cf框架的使用

大家都知道在使用Core Foundation的API时要时刻注意自己需要手动释放创建的内存,凡是看到create,copy,mutablecopy,alloc等都要调用CFRelease

举例如下:

CFUUIDRef uuid = CFUUIDCreate(NULL);

appUID = (NSString *) CFUUIDCreateString(NULL, uuid);

CFRelease(uuid);


2.关于block的循环引用

这个东西已经被说过很多次了,导致循环引用的原因也是很容易分析的:实例对象引用了block,在block内部访问了实例对象(包括该对象的实例变量)就会产生循环引用的问题

举例如下:

//情况一

- (void)case1 {

NSLog(@"case 1 Click");

dispatch_after(dispatch_time(DISPATCH_TIME_NOW, (int64_t)(0.3 * NSEC_PER_SEC)), dispatch_get_main_queue(), ^{

self.name = @"case 1";

});

}

这种情况不会造成内存泄漏,原因很简单,他并不是一个闭环,虽然在block内部引用了self,但是self并没有持有block,这就是常见的系统级别的block不用使用weakself,和strongself的原因,如uiview的动画block,gcd等

//情况二

- (void)case2 {

NSLog(@"case 2 Click");

__weaktypeof(self) weakSelf = self;

[self.teacher requestData:^(NSData *data) {

typeof(weakSelf) strongSelf = weakSelf;

strongSelf.name = @"case 2";

}];

}

第二种情况就是我们常见的容易出现循环引用的地方,self持有了block,block持有了self,形成了一个完美的闭环,根本无法释放,要想释放内存就必须保证一端为弱引用.但是在block内部为了防止self提前释放,又转成了strongself,也就是强引用保证在block内部self永远存在!

//情况三

- (void)case3 {

NSLog(@"case 3 Click");

[self.teacher requestData:^(NSData *data) {

self.name = @"case 3";

}];

}

内存泄漏,循环引用,原因就是相互强引用导致

//情况四

- (void)case4 {

NSLog(@"case 4 Click");

[self.teacher requestData:^(NSData *data) {

self.name = @"case 4";

self.teacher = nil;

}];

}

不存在内存泄漏了和循环引用,在block执行结束后主动释放了block的持有者,最终或导致self的dealloc执行.所以并不会内存泄漏,常常会看见有些大神在解决block的问题时在block执行结束后手动释放掉block,原理就是如此.

//情况五

- (void)case5 {

NSLog(@"case 5 Click");

Teacher *t = [[Teacher alloc] init];

[t requestData:^(NSData *data) {

self.name = @"case 5";

}];

}

不会造成循环引用,不会内存泄漏,因为是局部变量持有block,在这个方法的大括号内部有效,出了大括号局部变量就会被释放.所以不存在内存问题.

//情况六

- (void)case6 {

NSLog(@"case 6 Click");

[self.teacher callCase6BlackEvent];

self.teacher.case6Block = ^(NSData *data) {

self.name = @"case 6";

//下面两句代码任选其一

self.teacher = nil;

//        self.teacher.case6Block = nil;

};

}

self.teacher = nil; , self.teacher.case6Block = nil;这两句代码任选其一即可解决内存泄漏,因为一端被置为nil,就会打破循环引用问题.

3.实际项目中可能会遇到AFNetworking的内存泄漏问题

为什么会有这样的问题?

在实例化 AFHTTPSessionManager中如果进行多次调用,就会导致内存泄漏例如在项目中同事发起多个请求,创建多个manager就会有这样的问题.

[[AFHTTPSessionManager alloc] initWithSessionConfiguration:[NSURLSessionConfiguration defaultSessionConfiguration]];

解决办法:采用单例的方式创建,或者是继承AFHTTPSessionManager并将该类做成一个单例类

4.在for循环较大数据时,不断创建局部变量导致的内存泄漏问题

for (NSDictionary *dic in regionList) {

@autoreleasepool {

RegionList *model = [RegionList yy_modelWithDictionary:dic];

NSString *city;

if (model.city.length == 0) {

city = [NSString stringWithFormat:@"%@",model.region];

model.cityName = city;

}

else {

city = [NSString stringWithFormat:@"%@·%@",model.city,model.region];

model.cityName = city;

}

if (city.length > 0) {

model.cityPinyin = [city pinYin];

NSString *str = [model.cityPinyin uppercaseString];

model.firstChar = [str substringToIndex:1];

}

[regionListModel addObject:model];

}

}

举例:

在项目中可能会遇到从服务端获取城市列表,全国大概有三百多个市,每个市估算有10个区那么就会有3000多条数据.

利用yymodel解析从后台拿到的数据时是不是需要在for循环中创建3000多个局部变量.3000多个局部变量占用的内存将会是爆发式的增长.到底有多恐怖还请自己测一下,可能3000看不出多少效果可以给大点数字试试.

结论:

这个for循环里如果不使用@autoreleasepool,那临时变量内存可能是爆发式的,但是使用了@autoreleasepool,在每个@autoreleasepool结束时,里面的临时变量都会回收,内存使用更加合理


5.mrc的基础

自己生成的对象,自己持有 (alloc ,new,create)

不是自己生成的对象,自己也能持有(retain,copy,mutablecopy)

谁持有,谁释放不持有,不能释放不再需要时,主动释放 (release)


6,使用工具调试内存泄漏问题

优化内存泄漏的几点分析_第1张图片
存在内存泄漏

如何查看找到源代码位置


优化内存泄漏的几点分析_第2张图片
选择calltreses

选择调用树


优化内存泄漏的几点分析_第3张图片
关闭掉系统方法的调用

这样你就能看到你带吗内存泄漏的问题所在了.

内存泄漏代码

可能看到的代码并不存在内存泄漏问题,需要通过上下文分析内存可能泄漏的原因.


本人联系方式:qq:513961360

email:[email protected]

也可以加我们的qq群希望能与朋友们一起聊天和学习.群里还有很多iOS开发者,帮助我们解决问题,并且同时学习.

qq群号:580284575

你可能感兴趣的:(优化内存泄漏的几点分析)