本文列举的不是查找 iOS 应用内存问题的必要流程，只是讲述笔者在干这档子事儿的时候，可能会用到的手段而已。😊
Clang Static Analyzer
在应用运行起来之前，我们就能通过 Xcode 集成的静态分析工具 Clang Static Analyzer，分析下面几种类型的代码问题：
- Logic flaws: 读取未初始化的变量、解引用空指针等等；
- Memory management flaws:内存泄露等；
- Dead store:没被使用的变量；
- API usage flaws:返回值等不符合 API 的要求；
静态分析的结果通常是基于某种假设逻辑而推断产生的，所以是否要修改代码这一决定不能完全交给 analyzer。诸如“如何忽略特定的 dead store”、“如何告诉 analyzer 循坏块一定会进入”等常见问题，在这个 FAQ 中都列了出来。
更方便的是，使用 scan-build 能在命令行中分析，还能导出 html 方便查看分析结果：
scan-build -o DIR_TO_STORE_RESULTS xcodebuild -configuration Debug -workspace PATH_TO_YOUR_WORKSPACE -scheme YOUR_SCHEME_NAME
如果你的是 project 而不是 workspace 就写 -project PATH_TO_YOUR_PROJECT……好吧这就是 xcodebuild 的参数而已跟 scan-build 无关。
上图仅仅是 Bug Summary，下面才是 Report，比较私密就不截了，内容和用 Xcode 分析一样，给出具体逻辑的判定流程，指出错误。笔者觉得这一步可以添加到持续集成中，这样每天早上都能看到前一天可能新增的代码问题。
Leaks
Leaked Memory 指的是丢失引用的内存。打开 Leaks，尽管操作你的业务逻辑就好，Leaks Check 那一栏出现红色交叉就是检测到泄露的地方，选中 Leaks Object，点击右边的 E 按钮（Extended Detail）可以看到调用栈，帮助定位问题。
不过要注意的是，任何一个大型软件都不可能是完美的，所以 Cocoa Touch 本身也是可能发生泄漏的，所以对于那些调用栈没有用户代码而且你绞尽脑汁都想不明白的泄漏，说不定可以无视它。
但对于 Abandoned Memory 来说，Leaks 就无能为力了。Abandoned Memory 是那些引用没有丢失，但不再被使用的内存，在 ARC 下常见于由循环引用导致的内存不能释放。譬如说 Push 进入某个 ViewController 之后，再 Pop 回去，假设这个 ViewController 与其实例变量有循环引用，那么它们将不会被释放，Leaks 没办法检测到这种内存泄露，于是乎需要 Allocations 这个工具（通常会新建个模板把这两个工具放在一起用，嗯还有 VM Tracker）。
Allocations
在 Push 之前，使用 Allocations 对当前内存中的 Heap 和 VM Region 进行 Mark Generation，记录内存的使用状态，接着 Push 进一个 ViewController 后 Pop 回去，再 Mark 一遍，这样重复业务逻辑好几次，就能发现每次内存的增长情况。前一两次的快照可能有一些 lib 的缓存，所以要特别留意之后的内存增长情况。
每次 Mark Generation 之后，Growth 还是会不断变化的，这里笔者不清楚是系统延迟释放内存，还是工具还来不及作对比。我尝试了下，多点 Mark Generation 几次或者手动触发 Memory Warning 可以让前面的 Growth 快一点稳定下来。
将 Track Display 改为 Allocation Density 可以留意到内存分配的动态，突然出现的尖峰就是在那段时间拼命地在分配内存，稍微注意下是什么操作引起，说不定能优化是吧？毕竟堆上的内存分配可不是个轻松活。
我们还能再下面看到 Allocation Type 这个选项，Heap 和 VM Regions上的内存都是我们要关注的点。我们实例化的对象、malloc 分配的内存都在 Heap 上，而 VM Regions 上是我们不能直接接触的内存，但这不代表我们不用理会 VM Regions 任由其增长。比如 UIImage 对象在 Heap 上可能只有几十字节，但它代表的图片在解压缩后在 Image Region 上可能会占用几十kb，甚至更大。再比如，UIView 对象本身也不大，但是 CALayer backing stores 就不一定不起眼了。
还有，回到 Record Settings，我们常常需要在 Recorded Types 上设置忽略或追踪特定类型的对象以便于我们分析（这里凸显了给自己项目的类添加前缀的好处），特别是当你已经将目标锁定在某些类上时，这么做可以让我们事半功倍。
Debug Memory Graph
这是 Xcode 8 的新功能，就是点了 Debug Memory Graph 之后能看到当前在内存中的各种对象间引用关系。如果出现紫色框框的感叹号，那么可能是有内存问题，具体看上面的提示。有一点要提及的是，如果想看与某个对象的 backtrace，要去 Edit-Scheme-Diagnostics 中把 Malloc Stack 的复选框给勾上，否则你可能找不这玩意儿是在哪里创建的……
第三方的检测工具
除了官方的提供的工具之外，笔者还会使用一些的第三个工具，最早使用过 HeapInspector-for-iOS 代替 Allocations，直接就在应用内分析 Heap 的增长情况。还有 FBRetainCycleDetector，通过 DFS 寻找以对象为节点、强引用关系为边的有向图中的环路，从而达到找到循环引用的目的。上面的两个库都有些缺点，比如前者也是要不断重复业务逻辑并推断，后者要修改代码才能查找环路。而 WeRead 团队出品的 MLLeaksFinder 解决了这两个问题，具体可以看他们博客的介绍《MLeaksFinder：精准 iOS 内存泄露检测工具》以及《MLeaksFinder 新特性》，这个工具在实践中还是比较好用的。
最后
还是那句话，上面的所罗列不是查找 iOS 应用内存问题的必要流程，仅仅是常用的手段。另外，还有一点是调试的心态，当笔者要去查一个应用的内存问题时，笔者会像个XX一样，总是想找到内存问题，不找到不甘心🙄，然后会怀疑自己对项目代码不够了解、自己调试经验不足以及工具使用的姿势不正确等等。这显然是一种心理疾病，望各位以此为鉴，将更多的精力投入到新需求的开发中，而不是深陷调试旋涡无法自拔。
话说刚来公司一个月就给项目写了两个 bug，也是个挺悲伤的故事🙃。
