iOS—APP内存检测方案
内存泄漏是很常见的问题，虽然在ARC后苹果为我们解决了大量的烦恼，但是一个不小心还是会陷进去。这段时间在公司做了一些内存泄漏排查与修改的工作，介绍一下常见的场景和用到的一些检测方式，以供有需求的童鞋做一个参考。
在ARC环境中，我们涉及到的内存泄漏一般不会跳出这几个场景
场景一：OC中直接运用C语言
比如CF（CGColorCreate、ABRecordCopyValue）开头的内存泄漏，我们一般运用 其配对的方法来释放（CGColorCreate－CGColorRelease、ABRecordCopyValue－CFRelease）；检测这种内存泄漏，我们用XCODE的analyze(shift+command+B)直接检测出来。
场景二：NSTimer
NSTimer会造成循环引用：timer会强引用target即self，在加入runloop的操作中，又引用了timer，所以在timer被invalidate之前，self也就不会被释放。所以我们要注意，不仅仅是把timer当作实例变量的时候会造成循环引用，只要申请了timer，加入了runloop，并且target是self，虽然不是循环引用，但是self却没有释放的时机。如下方式申请的定时器，self已经无法释放了。这个的解决方案在我的另一文章中有比较详细的方案。http://www.jianshu.com/p/8a940a612e20
图一
场景三：NSNotification、KVO监听
通知涉及到的内存问题，一般回出现这两种情况：
图二
A、上图中采用block的方式书写通知的监听回调（这种也属于block的循环引用造成的内存泄漏）；当然可以用__weakself解决。
B、没有移除监听；一定记得移除监听
场景四：block的循环引用
图三
block的循环引用都可以用weak self来解决，但是不是所有的block都有循环引用，如果不想写那种臃肿的代码（遇见block就加weakself）就需要你去甄别。不过在运用weakself的时候涉及到一个在block中提前释放的问题，这需要在block中给一个weakself一个强引用（__strong __typeof(&*self) strongSelf = weakSelf）。当然这不是重点，重点是如何有效的检测。
如何有效地检测出这些内存问题呢？
一、Xcode的静态分析（analyze---shift+command+B）
静态分析,的作用并不是很大。它只能做一些比如“场景一”产生的内存问题。对于“场景二、三”没有效果。
图四
二、Xcode的instruments（ shift + commond + i）
首先得先让APP跑起来，然后再做以下操作
打开方法：
图四
或者用快捷键：shift + commond + i 进入页面：
图五
点击进入leaks就可以内存的监听了。需要注意的是，Leaks是动态监测，所以我们需要手动操作APP,一边操作，一边观察Leaks的变化，当出现红色叉时，就监测到了内存泄露，点击右上角的第二个，进行暂停检测(也可继续检测，当多个时暂停，一次处理了多个).如图所示:
图六
具体的操作可以查看：instruments的操作http://www.cnblogs.com/iOSv587country/p/4862989.html
三、Xcode的捕获内存图（capturing memory graph）
图七
这种方法需要先，把APP调为debug模式，运行APP，操作app进入各个页面（想要测试的页面），然后再回到首页（可以重复操作几次）。然后再看Xcode的左边栏的内存占用图，只要是不是根目录的对象，而还显示在边栏里面的、个数也不正常的都是没有释放的内存，这页面就一定发生了内存泄漏的问题，具体问题就想要你到该控制器里面寻找（一般是从该页面的控制器开始着手查找）。这个方法看似比较笨，但是是一个很可靠的方法，特别是针对一些控制器没有被释放的内存泄漏很有效果。针对一些对象的泄漏可以用这样的方法找出：点击左下角的！号的图标就出现可能有内存问题的地方。
图八
图九
四、运用MLeaksFinder－精准 iOS 内存泄露检测工具（当然还有很多类似的第三方，本人推荐这个－不用说，一个词“好用”）
使用介绍：先集成到工程中，然后就运行，在APP中操作，如果有内存问题，APP就会弹出提示框，log也会打印出出问题的控制器或者对象。注意，上线一定要关掉。
这个工具主要是有以下好处：
1、集成简单，只需要集成到APP中里面，不需要初始化什么的。
2、使用简单，不侵入业务逻辑代码，不用打开 Instrument
3、不需要额外的操作，你只需开发你的业务逻辑，在你运行调试时就能帮你检测
4、内存泄露发现及时，更改完代码后一运行即能发现（这点很重要，你马上就能意识到哪里写错了）
5、精准，能准确地告诉你哪个对象没被释放
具体的关于MLeaksFinder，可以查看：http://wereadteam.github.io/2016/02/22/MLeaksFinder/
总结：在MRC 时代 Leaked memory 很常见，因为很容易忘了调用 release，但在 ARC 时代更常见的内存泄露是循环引用导致的， Abandoned memory，Leaks 工具查不出这类内存泄露，应用有限。所以，方法一、二就运用十分有限，方法三的特点是适合我们开发者自己去监听查找内存问题，但是对于测试的人员就没有法查看。方法四这个比较通用，开发人员和测试都可以查看到异常，从而节约了大量时间和精力去特意查找内存问题；不过这方法四也存在一个不足，不能调配debug 、release模式。希望这个第三方能改进。
以上有什么不适，还望指出，谢谢了！
参考文章：
http://wereadteam.github.io/2016/02/22/MLeaksFinder/
http://www.jianshu.com/p/781d5c7cb477
