Keywords ：内存泄露，循环引用
前言
最近做项目碰到两次内存泄露的问题，一个是UIViewController的内存泄露问题，一个是UIView的，也就是没调用dealloc方法。这种bug解决多了，自己总结了一套方法。避免以后再花费更多的时间在这类问题上。希望大家多多补充，共勉之。
快速解决问题
1.持有UIView的UIViewController被正常释放了吗
如果你不是在定位UIView的泄露问题。请跳过此步骤。
自定义了一个UITableViewCell，按理来说在UIViewController退出后，UITableView会被销毁，自然UITableViewCell也会被释放。但是，我发现我的并没有。找了很久，才发现不是自定义的cell问题。而是相关的UIViewController就没有被释放。解决完UIViewController 的泄露问题，一切都迎刃而解了。所以，建议大家先定位上层UIViewController有没有被释放。若有，则肯定就是该UIView的问题了。
2.block的循环引用问题
感觉90%的泄露都是block的循环引用引起的。self是retain类型，会使引用计数加一，如果self又强持有这个block，那泄露问题就产生了。看下面的错误示例代码：
[self.testView setTestBlock:^(BOOL finish) {
[self doSomething];
}];
这里应该使用self的弱引用。正确代码如下：
__weak __typeof(&*self)weakSelf = self;
[self.testView setTestBlock:^(BOOL finish) {
[weakSelf doSomething];
}];
这样就解决了循环引用，就不会存在内存泄露了。
ps：多说一句，并不是所有的block中有必须要使用weakSelf这种弱引用。如果self并不持有该block，就不会有循环引用的问题，放心大胆的用strong self就行了。
3.使用strong 修饰属性delegate
Class A:
@property (nonatomic, strong) id<SomeDelegate> delegate;
当设置A的代理为B时，A对B强引用。如果B对A也存在强引用，又产生了循环引用！！！所以当A没被释放时，不妨先把代理设置为weak属性。当然，并不是所有的delegate都会产生循环引用。当你不确定时，最好还是使用weak 修饰delegate。
4.NSTimer
self.timer = [NSTimer scheduledTimerWithTimeInterval:1.0f
target:self
selector:@selector(someMethod)
userInfo:nil
repeats:YES];
[self.timer setFireDate:[NSDate dateNow]];
当NSTimer开始正常工作之后，该UIViewController引用计数就被加一了。在页面消失的时候，应该先使NSTimer不工作，最好再置为nil,UIViewController才会调用dealloc方法。
if (self.timer && [self.timer isValid]) {
[self.timer invalidate];
self.timer = nil; // 不置为nil也行
};
综上，希望大家保持写代码的好习惯，避免大量的内存泄露。
