Xcode8 使用Instruments检测定位并解决iOS内存泄漏问题

缘由

最近公司项目更新了几个版本,主要是客户端配合H5上一些活动和优化解决一些遗留下来的问题。review代码的过程中,发现项目在模拟器里跑时内存使用很大,达到了130多兆,趁着刚发完新版有点空隙,于是花了点时间研究了下。

虽然苹果出了ARC(自动内存管理机制),我们不用花太多的时间在内存泄漏的问题上,但在我们开发的过程中,还是会因为各种原因而产生内存泄漏,例如Block的循环引用,delegate 写成了 strong,定时器没有关闭,弱指针使用不当等等
所以我们下面就简单介绍下怎么使用Xcode8自带的Instruments中的Leaks检测我们的程序有没有内存泄露和定位内存泄露的代码,让我们可以更准确的定位和解决问题
(分析内存泄露不能把所有的内存泄露查出来,有的内存泄露是在运行时,用户操作时才产生的)

Leaks具体使用

leaks如何使用?写的比较详细,步骤也很简单,感谢网友分享方便浏览,下面也简单的写下步骤

1、打开Leaks(两种方式)

方式一:


打开Instruments,选择Leaks

方式二:


点击之后等待几分钟,会出现选择如下图,选择choose即可

2、使用Leaks

完成步骤1之后,就能看到我们应用的体检结果了(这里仅仅指内存泄漏;点击那个红叉标识显示具体的leaks,如下图)


哇,运行应用之后,还没操作页面呢,就这么多内存泄漏,也难怪模拟器跑的时候内存占用那么多。问题是找出来,但是这样的信息真的看不懂啊,怎么办呢?不急,其实很简单,设置一个地方就好。

3、设置Leaks,查找定位具体leak是什么

现在我们就能看出个大概究竟了,我这个项目里一看就知道是自己封装的AFNeteworking有问题。当然此时你还可以选中某一条双击,就能定位到具体代码处,如下图.

4、解决leak

后来仔细看了下该文件的这个方法,不难发现确实有问题。(注意注释if语句,若不加if语句,每次请求接口都创建一个session对象,又没释放,那自然就造成了内存泄漏。还有session的一些设置里面,道理也是一样。)

//数据请求,post和get
- (void)requestWithMethod:(RequestMethod)requestMethod
             andUrlString:(NSString *)urlString
            andParameters:(id) parameters
                  success:(CompletePost)success
                  failure:(CompleteFailure)failure
{
    //session存在的话,不需要重复创建该对象,解决内存leak问题
//    if (!session) {
        session = [AFHTTPSessionManager manager];
        //设置自定义代理参数
        [session.requestSerializer setValue:[StaticTools setUserAgentWithParam:@"afn"] forHTTPHeaderField:@"User-Agent"];
        session.responseSerializer.acceptableContentTypes = [NSSet setWithObjects:@"application/json", @"text/json", @"text/javascript",@"multipart/form-data",@"text/plain", nil];
        //配置https
        session.securityPolicy = [self customSecurityPolicy];
        session.securityPolicy.allowInvalidCertificates = YES;
//    }
    
    if (requestMethod == get) {
        //[self addParaWithOriginDic:parameters] ,判断参数是否带token,若有的话 添加随机数和签名参数
        [session GET:urlString parameters:[self addParaWithOriginDic:parameters] progress:^(NSProgress * _Nonnull downloadProgress) {
            
        } success:^(NSURLSessionDataTask * _Nonnull task, id  _Nullable responseObject) {
            success(responseObject);
        } failure:^(NSURLSessionDataTask * _Nullable task, NSError * _Nonnull error) {
            failure(error);
        }];
    } else {
        [session POST:urlString parameters:[self addParaWithOriginDic:parameters] progress:^(NSProgress * _Nonnull uploadProgress) {
            
        } success:^(NSURLSessionDataTask * _Nonnull task, id  _Nullable responseObject) {
            success(responseObject);
        } failure:^(NSURLSessionDataTask * _Nullable task, NSError * _Nonnull error) {
            failure(error);
            if (error.code == -1001) {
                //做超时之后的一些操作
            }
        }];
    }
}

放开if之后,再次检测,发现之前那么多leaks都不见了,果真是这个问题导致。(下图虽然还有leak,但是一看就知道是集成的第三方微客服那边的问题,已反馈)


结果

再次在模拟器上跑的时候,发现内存确实也小了很多,70的样子,比之前的130多确实少多了(真机上运行内存在40的样子)

结语:存在leaks虽然貌似不会影响App的审核,平时用的时候也没出现奔溃,但是干掉leaks,能健壮咋们的app,减少应用奔溃闪退的概率,挺好!

其它参考链接:http://www.cnblogs.com/BigFeng/p/6178301.html

推荐阅读更多精彩内容