常见的内存泄漏及检测方法

iOS内存泄漏的常见情况
1、声明delegate为strong类型，简而言之，如果父VC持有子VC，并设置子VC的delegate为self（也就是父VC），这样的结果就是子VC也间接持有了父VC，造成循环引用，在Pop子VC的时候不会调用delloc。

一个例子：
一个UITableViewController 对象a通过retain获取了UITableView对象b的所有权，这个UITableView对象b的delegate又是a， 如果这个delegate是retain方式的，那基本上就没有机会释放这两个对象了。 循环引用而产生的内存泄露也是Instrument无法发现的

所以delegate必须设置为weak类型

2、timer是否持有self，我们一般要执行一个timer的时候会用－(NSTimer *)scheduledTimerWithTimeInterval:(NSTimeInterval)ti target:(id)aTarget selector:(SEL)aSelector userInfo:(id)userInfo repeats:(BOOL)yesOrNo
这里的aTarget一般是self，这时候就需要注意了，如果在你退出的时候这个timer还在执行的话由于这个timer会持有self，所以delloc也不会调用，这里可以用weakSelf代替self也是没有问题的。

解决：
使用NSTimer可能会碰到循环引用的问题。特别是当类具有NSTimer类型的成员变量，并且需要反复执行计时任务时。例如

_timer = [NSTimer scheduledTimerWithTimeInterval:5.0
                        target:self                           selector:@selector(startCounting)      userInfo:nil                                      repeats:YES];

类有一个成员变量_timer，给_timer设置的target为这个类本身。这样类保留_timer，_timer又保留了这个类，就会出现循环引用的问题，最后导致类无法正确释放。
解决这个问题的方式也很简单，当类的使用者能够确定不需要使用这个计时器时，就调用
[_timer invalidate];
_timer = nil;

这样就打破了保留环，类也可以正确释放。但是，这种依赖于开发者手动调用方法，才能让内存正确释放的方式不是一个非常好的处理方式。所以需要另外一种解决方案。如下所示：

@interface NSTimer (JQUsingBlock)
+ (NSTimer *)jq_scheduledTimerWithTimeInterval:(NSTimeInterval)ti
                                     block:(void(^)())block
                                   repeats:(BOOL)repeats;
@end

@implementation NSTimer (JQUsingBlock)

+ (NSTimer *)jq_scheduledTimerWithTimeInterval:(NSTimeInterval)ti
                                     block:(void(^)())block
                                   repeats:(BOOL)repeats{

    return [self scheduledTimerWithTimeInterval:ti
                                     target:self
                                   selector:@selector(jq_blockInvoke:)
                                   userInfo:[block copy]
                                    repeats:repeats];
}

+ (void)jq_blockInvoke:(NSTimer *)timer{

    void(^block)() = timer.userInfo;
    if (block) {
        block();
    }
}

@end

定义一个NSTimer的类别，在类别中定义一个类方法。类方法有一个类型为块的参数（定义的块位于栈上，为了防止块被释放，需要调用copy方法，将块移到堆上）。使用这个类别的方式如下：
__weak ViewController *weakSelf = self;
_timer = [NSTimer jq_scheduledTimerWithTimeInterval:5.0
block:^{
__strong ViewController *strongSelf = weakSelf;
[strongSelf startCounting];
}
repeats:YES];
使用这种方案就可以防止NSTimer对类的保留，从而打破了循环引用的产生。__strong
ViewController *strongSelf = weakSelf主要是为了防止执行块的代码时，类被释放了。在类的dealloc方法中，记得调用[_timer
invalidate]。

3、最常见的就是block导致的循环引用，由于在重构APP中用到了MVVM架构，使用了大量的信号机制，导致block到处飞（哈哈），解决的最多的就是这种了，解决方法也很简单，就是在block外声明__weak type(self) weakSelf = self，在block中用weakSelf就可以了，还有就是在block中如果使用了成员变量的下划线形式也要改成weakSelf.PropertyName的形式。MVVM中定义了宏对@weakify(self)和@strongify(self)可以理解为__weak type(self) weakSelf = self的简化形式，可以拿来直接使用。
4、图片没释放，instrument调试后，发现没被释放的全是imageIO，差不多就知道了，把读图的方式，从[UIImage imageNamed:@”“],改成imageWithContentsOfFile，就可以了。
5、使用GPUImage处理拍照的时候，内存稳定不明增长。是Xcode7.1的问题。。只在debug的时候导致内存崩溃，release的时候并不会造成内存溢出，所以可以不必管它。
6、CoreFoundation对象(C对象) : 只要函数中包含了create\new\copy\retain等关键字, 那么这些方法产生的对象, 就必须在不再使用的时候调用1次CFRelease或者其他release函数
7，使用数据库，执行完毕后要使用sqlite3_finishi(statement)关闭SQL执行语句。否则造成内存泄漏

这是一个 “EXC_BAD_ACCESS”错误或者signal SIGABRT
1、设置NSZombieEnabled
这是一个 “EXC_BAD_ACCESS”错误。我们打开XCode的选项：“NSZombieEnabled” 。在crash时可能会给你更多的一些提示信息。

选择 Scheme下的edit scheme，然后在Diagnostic下选择Zombie Objects，然后在运行程序
再次crash，这次在output窗口会看到多了一项错误信息：

2012-11-28 13:22:08.911 PropMemFun[2132:11303] * -[CFString respondsToSelector:]: message sent to deallocated instance 0x713ebc0
大概意思是：向已释放的内存发送消息。也就是说使用了已释放的内存，在C语言相当于使用了“野指针”，分析代码，修改后，再次运行。

2、分析内存泄漏
（1）使用Analyze
打开product下的Analyze选项，分析哪里存在内存泄漏。

（2）使用instrument的leaks选项
检查用户操作时才产生内存泄露，leaks横行产生的红色就是产生的内存泄漏

Details下选择Call Tree.然后在右下角的复选框中选中Invert Call Tree 和Hide System Libraries，就可以显示的就是内存泄露代码部分