1. 计时器NSTimer
一方面timer作为VC的属性，被VC强引用，创建timer对象时VC作为target被timer强引用，即循环引用。事实上这个说法是错的。
及时timer不做为A的属性，或者timer 的target 传入__ weak, A也不会释放。
网上的80%帖子都说 vc->time->target(vc) 实际是错的 。
主要问题runloop对timer的引用，timer对持有对象的“强制性”强引用，
timer内部会强引用target，即使传进来的是weak类型，造成这个问题其实是：runLoop=>timer=>target才会造成内存泄漏。
不准时
1.第一种不准时：有可能跳过去
线程处理比耗时的事情时会发生
还有就是timer添加到的runloop模式不是runloop当前运行的模式，这种情况经常发生。
2.并不会在准确的时间触发，而是会延迟个很小的时间，原因也可以归结为2点：
RunLoop为了节省资源，并不会在非常准确的时间点触发
线程有耗时操作，或者其它线程有耗时操作也会影响
iOS7以后，Timer 有个属性叫做【 Tolerance】 (时间宽容度,默认是0)，标示了当时间点到后，容许有多少最大误差。
它只会在准确的触发时间到加上Tolerance时间内触发，而不会提前触发（是不是有点像我们的火车，只会晚点。。。）。另外可重复定时器的触发时间点不受Tolerance影响
解决Timer导致的循环引用
(1)运用 didMoveToParentViewController 方法 //当前VC出栈调用
if paren == nil self.time invalidate selg.time = nil;
(2) 中间者模式 self.time ->_target
引用逻辑:self强引用timer强引用target
解决方法：
新建一个 target NSObject
运用 runtime class_addMethod [ _target class]
然后再 delloc 把定时器 失效
借助runtime给对象添加消息处理的能力
self强引用timer强引用target
_target = [[NSObject alloc] init];
class_addMethod([_target class], @selector(fire), class_getMethodImplementation([self class], @selector(fire)), "v@:");
self.timer = [NSTimer scheduledTimerWithTimeInterval:1.0 target:_target selector:@selector(fire) userInfo:nil repeats:YES];
(3)第三种方案 NSProxy
引用逻辑:self强引用timer强引用proxy弱引用self
解决方法:
新建一个 NSProxy 中申明一个 weak 的target
然后用消息转发机制
(4)NSTimer提供的API
引用逻辑:self强引用timer弱引用target
解决方法：
__weak typeof(self) weakSelf = self;
self.timer = [NSTimer scheduledTimerWithTimeInterval:1 repeats:YES block:^(NSTimer * _Nonnull timer) {
[weakSelf fire];
}];
2.block导致的循环引用
block在copy时都会对block内部用到的对象进行强引用(ARC)或者retainCount增1(非ARC)。在ARC与非ARC环境下对block使用不当都会引起循环引用问题，一般表现为，某个类将block作为自己的属性变量，然后该类在block的方法体里面又使用了该类本身，简单说就是
self.someBlock = ^(Type var){
[self dosomething];
}
这种循环引用会被编译器捕捉到并及时提醒。
self.block = ^(NSString *name){
NSLog(@"arr:%@", self.arr);
};
网上大部分帖子都表述为"block里面引用了self导致循环引用"，但事实真的是如此吗？我表示怀疑，其实这种说法是不严谨的，不一定要显式地出现"self"字眼才会引起循环引用。我们改一下代码，不通过属性self.arr去访问arr变量，而是通过实例变量_arr去访问，如下：
由此我们知道了，即使在你的block代码中没有显式地出现"self"，也会出现循环引用！只要你在block里用到了 self所拥有的东西！
但对于这种情况，我们无法通过加__weak声明或者__block声明去禁止block对self进行强引用或者强制增加引用计数。但我们可以通过其他指针来避免循环引用具体是这么做的：
__weak typeof(self) weakSelf = self;
self.blkA = ^{
__strong typeof(weakSelf) strongSelf = weakSelf;//加一下强引用，避免weakSelf被释放掉
NSLog(@"%@", strongSelf->_xxView); //不会导致循环引用.
};
3. 代理 weak引用
4.wkWebView中 WKWebView在与js交互约定方法时
addScriptMessageHandler 导致循环引用
[configuration.userContentController addScriptMessageHandler:self name:name]；
这里userContentController持有了self ，然后 userContentController 又被configuration持有，最终被wkwebview持有，然后wkwebview是self的一个成员变量，所以self也持有self，所以就造成了循环引用，导致界面不会被释放
解决方案：
viewWillAppear里面调用addScriptMessageHandler
viewWillDisappear 调用removeScriptMessageHandlerForName
5.performSelector内存泄露
performSelector延时调用的问题，
performSelector关于内存管理的执行原理是这样的：执行 [self performSelector:@selector(method1:) withObject:self afterDelay:3]; 的时候，系统会将self的引用计数加1，执行完这个方法时，还会将self的引用计数减1，当方法还没有执行的时候，要返回父视图释放当前视图的时候，self的计数没有减少到0，而导致无法调用dealloc方法，出现了内存泄露。
所以最后我的解决办法就是取消那些还没有来得及执行的延时函数，代码很简单：
[NSObject cancelPreviousPerformRequestsWithTarget:self]
当然你也可以一个一个得这样用：
[NSObject cancelPreviousPerformRequestsWithTarget:self selector:@selector(method1:) object:nil]
加上了这个以后，dealloc方法就会被调用，问题解决！
6.CF类型内存
注意以creat,copy作为关键字的函数都是需要释放内存的，注意配对使用。比如：CGColorCreate<-->CGColorRelease
class_copyPropertyList 【 free】 释放
7.AFNetWorking 3.0
原因是manager类每一次网络请求都是初始化一个实例对象，但是该对象在工程中得不到释放，造成了内存泄漏。我也不知道AFNetWorking的作者是怎么想的。解决方法是创建一个继承与AFHTTPSessionManager 的单例对象，每次网络请求都调用这个单例方法。
8.NSNotification
使用block的方式增加notification，引用了self，在删除notification之前，self不会被释放，与timer的场景类似，其实这段代码已经声明了weakself，但是调用_eventManger方法还是引起了循环引用。
也就是说，即使我们没有调用self方法，_xxx也会造成循环引用。
