- NSTimer的生命周期问题
NSTimer * timer = [NSTimer scheduledTimerWithTimeInterval:1 target:self selector:@selector(printMessage) userInfo:nil repeats:YES];
Timer 添加到 Runloop 的时候，会被 Runloop 强引用。
Timer 又会有一个对 Target 的强引用。
所以说如果不对Timer进行释放，Timer的targer(self)也一直不会被释放。
有时候我们我们对某个Timer的targer设置了nil。但没设置[timer invalidate]。
其实这个对象还是没被释放的。timer对应的执行方法也一直会在线程中执行。容易造成内存泄露。
那么问题来了：如果我就是想让这个 NSTimer 一直输出，直到 DemoViewController 销毁了才停止，我该如何让它停止呢？
- NSTimer和Run loop Modes
在Cocoa中，每个线程(NSThread)对象中内部都有一个run loop（NSRunLoop）对象用来循环处理输入事件(子线程默认是没创建的只有去获取Runloop的时候才创建)。
处理的事件包括两类，一是来自Input sources的异步事件，一是来自Timer sources的同步事件;run Loop在处理输入事件时会产生通知，可以通过Core Foundation向线程中添加run-loop observers来监听特定事件,以在监听的事件发生时做附加的处理工作。
- Default mode（NSDefaultRunLoopMode）
默认模式中几乎包含了所有输入源(NSConnection除外),一般情况下应使用此模式。
-
Connection mode（NSConnectionReplyMode）
处理NSConnection对象相关事件，系统内部使用，用户基本不会使用。 -
Modal mode（NSModalPanelRunLoopMode）
处理modal panels事件。 -
Event tracking mode（UITrackingRunLoopMode）
在拖动loop或其他user interface tracking loops时处于此种模式下，在此模式下会限制输入事件的处理。例如，当手指按住UITableView拖动时就会处于此模式。 -
Common mode（NSRunLoopCommonModes）
这是一个伪模式，其为一组run loop mode的集合，将输入源加入此模式意味着在Common Modes中包含的所有模式下都可以处理。在Cocoa应用程序中，默认情况下Common Modes包含default modes,modal modes,event Tracking modes.可使用CFRunLoopAddCommonMode方法想Common Modes中添加自定义modes。
所以Timer默认是添加在default mode下的。当我们拖动UIScrollerView的时候当前的runloop是在UITrackingRunLoopMode。所以无法执行timer的对应方法。
解决方法：
一种方法是在另外的线程中处理定时器事件，可把Timer加入到NSOperation中在另一个线程中调度;
还有一种方法时修改Timer运行的run loop模式，将其加入到UITrackingRunLoopMode模式或NSRunLoopCommonModes模式中。
NSTimer * timer = [NSTimer scheduledTimerWithTimeInterval:1 target:self selector:@selector(printMessage) userInfo:nil repeats:YES];
[[NSRunLoop currentRunLoop] addTimer:timer forMode:NSRunLoopCommonModes];
