文献综述（或调研报告）：
1. 内存监控
内存是所有程序使用的一项重要的系统资源。程序在运行之前必须要被加载到内存中，并且在运行的时候，程序会分配附加的内存来存储和操作程序级别的数据。由于为程序的代码和数据分配内存空间需要时间和资源，所以会影响系统整体的性能。对iOS开发者来说，高效的内存管理是写高性能代码的一个重要方面。最小化内存使用，不仅仅减少了应用程序的内存占用，同时也减少了它消耗的CPU时间。
1.1 跟踪内存使用
Xcode内置了Instruments应用程序来辅助开发者监控应用程序的性能。Instruments是一个集成的，数据收集环境，使用特殊模块来收集有关进程的各种信息。Instruments可以在应用程序的运输二进制文件上操作-不需要为了使用它将特殊的模块编译到应用程序中。Instruments的ObjectAlloc仪器记录和显示了自从应用程序启动后的所有内存分配的历史记录。
FBAllocationTracker是Facebook开源的内存分析工具[2]，它的原理是用 Method Swizzling替换原本的alloc方法，这样可以在App运行时记录所有OC实例的分配信息，帮助App在运行阶段发现一些OC对象的异常增长问题。相比Instrument的Allocation，FBAllocationTracker对App性能影响较低，可以在App中独立运行。但是这个工具也有比较明显的缺陷：监控范围不够全面，只能监控OC对象，并且不能监控C 对象和malloc内存块以及VM内存。关键是没有内存对象分配的堆栈信息，这对于开发者来说很难只通过对象的类型和数量定位到内存增长的原因。因此，FBAllocationTracker虽然能独立在App中运行，但是监控的内存范围太小，同时记录的对象信息也过于简单，对于分析内存问题帮助十分有限。
1.2 内存泄漏检测
内存泄漏是程序不再引用的已分配内存块。泄露通过用不可访问的数据填充内存页来浪费空间，并且由于额外的分页活动浪费时间。泄漏的内存最终会迫使系统为应用程序分配额外的虚拟内存页面。进入ARC时代后，编译器会自动回收对象，并且通常可以避免内存泄漏的问题。然而在ARC时代最常见的导致内存泄漏的是循环引用，当两个不同的对象各有一个强引用指向对方，导致双方的内存都无法释放。
