Xcode8 使用Instruments检测定位并解决iOS内存

缘由

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

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

Leaks具体使用

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

1、打开Leaks（两种方式）

方式一：

方式二：

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