缘由
最近公司项目更新了几个版本，主要是客户端配合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，减少应用奔溃闪退的概率，挺好！
