iOS block循环引用，什么时候使用weakSelf，控制器
最近使用block发现在控制器pop后，看似控制器是从栈中移除，但是控制器没有执行deallo方法，block中的方法还可以继续执行，说明控制器被某个对象强引用，引用计数不为0，系统无法帮我们释放内存。
说到强引用，首先想到block中使用内部若直接使用self，造成循环引用
一.block内部什么时候使用weak_self
像系统UIView的动画和GCD这种block内部就不需要weak_self
[UIView animateWithDuration:1.0 animations:^{
}];
dispatch_after(dispatch_time(DISPATCH_TIME_NOW, (int64_t)(1.0 * NSEC_PER_SEC)), dispatch_get_main_queue(), ^{
//_Block_object_assingn(&self); self retain
[self doSomething];
//_Block_object_dispose(&self); self release
});
1.block是类的属性，如果没有使用weak_self会造成循环引用的问题
例：
定义block两种方式
第一种：
typedefvoid(^cellBtnLongPressBLOCK)(NSString*msgText);
@property(nonatomic,copy)cellBtnLongPressBLOCKcellBtnLongPressBlock;
第二种：
@property(copy,nonatomic) void(^XMPPSingleVCNotifiBlock)(XMPPMessage*message_notifi);
宏定义
#define WEAK_REF(obj) \
__weak typeof(obj) weak_##obj = obj; \
调用block属性
WEAK_REF(self)
[XMPPTool sharedXMPPTool].XMPPSingleVCNotifiBlock = ^(XMPPMessage *message_notifi) {
weak_self.navigationItem.title = @"对方正在输入";
};
2.当block作为方法的属性时
- （void）block:(void(^) (NSIntegerindex))block; // 实例方法
UserTool *tool = [[UserTool alloc]init];
[tool block:^(NSIntegerindex) {
}];
+（void）block:(void(^) (NSIntegerindex))block; // 类方法（用类名直接调用，方法中不能使用self.）
// alloc就是一种类方法；init就是一种实例方法，被alloc方法返回的对象实例调用。
[UserTool block:^(NSIntegerindex) {
}];
注：只有当block直接或间接的被self持有时，才需要weak_self。如果在 Block 内需要多次 访问 self，则需要使用 strongSelf。
奇了个大怪了，检测当控制器执行了dealloc方法后，再次执行block方法
if ([XMPPTool sharedXMPPTool].XMPPSingleVCNotifiBlock) {
[XMPPTool sharedXMPPTool].XMPPSingleVCNotifiBlock(message) ；
}
block还会执行，其他方法可能不会走，但是我写了个Toast提示 还是会显示在dealloc中将block置NULL就好了，不知道什么原因，知道的小伙伴可以在评论区告诉我
[XMPPTool sharedXMPPTool].XMPPSingleVCNotifiBlock = NULL;
二.控制器中的NSTimer没有被销毁
self.timer = [NSTimer timerWithTimeInterval:5.0 target:self selector:@selector(timerMethod1) userInfo:nil repeats:NO];
[[NSRunLoop currentRunLoop] addTimer:self.timer forMode:NSRunLoopCommonModes];
使用定时器记得在viewWillDisappear之前需要把控制器用到的NSTimer销毁。
[self.timer invalidate];
self.timer=nil;
另外添加NSTimer时最好将定时器添加到runloop中
NSDefaultRunLoopMode：App 的默认 Mode，通常主线程是在这个 Mode 下运行(默认情况下运行)
UITrackingRunLoopMode：界面跟踪 Mode，用于 ScrollView 追踪触摸滑动，保证界面滑动时不受其他 Mode 影响(操作 UI 界面的情况下运行)
UIInitializationRunLoopMode：在刚启动 App 时进入的第一个 Mode，启动完成后就不再使用
GSEventReceiveRunLoopMode：接受系统事件的内部 Mode，通常用不到(绘图服务)
NSRunLoopCommonModes：这是一个占位用的 Mode，不是一种真正的 Mode (RunLoop无法启动该模式，设置这种模式下，默认和操作 UI 界面时线程都可以运行，但无法改变 RunLoop 同时只能在一种模式下运行的本质)
UITrackingRunLoopMode 例如在cell中使用定时器时使用该mode，可以保证在tableview上下滑动时，不会影响定时器，不然滑动tableview定时器会停止
三.viewController中的代理不是weak属性
例如@property (nonatomic, weak) id delegate;代理要使用弱引用，因为自定义控件是加载在视图控制器中的，视图控制器view对自定义控件是强引用，如果代理属性设置为strong，则意味着delegate对视图控制器也进行了强引用，会造成循环引用。导致控制器无法被释放，最终导致内存泄漏。
修饰代理需要使用weak，当delegate指向的对象销毁后，delegate会置nil；
如果用assign修饰代理的话，当delegate指向的对象被销毁后，delegate依然会保存之前对象的地址，所以delegate就变成了野指针
总结：1、block防止循环引用（系统的block GCD 不用考虑）
2、定时器用完要销毁
3、delegate要用weak修饰
做了这些排查之后，再检测控制器pop后控制器是否执行dealloc方法，只有当ViewController执行了dealloc，控制器才算被销毁。
如果有什么不对的地方或还有其他情况影响控制器pop后不执行dealloc方法，欢迎在下方补充交流。
