Timer创建
- 使用 scheduledTimerWithTimeInterval:invocation:repeats:或者scheduledTimerWithTimeInterval:target:selector:userInfo:repeats:
这两个类方法创建一个timer并把它指定到一个默认的runloop模式中
在主线程中直接执行, 子线程需要开启runloop,定时器才能生效
- 使用 timerWithTimeInterval:invocation:repeats: 或者 timerWithTimeInterval:target:selector:userInfo:repeats:
这两个类方法创建一个timer的对象，不把它知道那个到run loop. (当创建之后，你必须手动的调用NSRunLoop下对应的方法 addTimer:forMode: 去将它制定到一个runloop模式中.)
@property (nonatomic, weak) NSTimer *timer2;//注意这里写的是weak,会有问题
self.timer2=[NSTimer timerWithTimeInterval:1.0 target:self selector:@selector(logtimer2) userInfo:nil repeats:YES];
[[NSRunLoop currentRunLoop] addTimer:self.timer2 forMode:NSRunLoopCommonModes];
用weak修饰,创建完成直接释放掉了, 而第一种方式创建后直接添加到runloop中, 被runloop持有, 不会被释放, 这里修饰必须用strong来修饰, 创建之后不会执行timer, 可以在合适的时机添加到runloop中, 开始执行timer
- 使用 initWithFireDate:interval:target:selector:userInfo:repeats: 方法分配并创建一个NSTimer的实例 (当创建之后，你必须手动的调用NSRunLoop下对应的方法 addTimer:forMode: 去将它制定到一个runloop模式中.)
使用
@interface TimerViewController ()
@property (nonatomic, strong) NSTimer *timer;
@end
@implementation TimerViewController
- (void)viewDidLoad {
[super viewDidLoad];
self.timer = [NSTimer timerWithTimeInterval:1.0 target:self selector:@selector(timerRun) userInfo:nil repeats:YES];
//self.timer = [NSTimer scheduledTimerWithTimeInterval:2.5 target:self selector:@selector(move) userInfo:nil repeats:YES];
[[NSRunLoop currentRunLoop] addTimer:self.timer forMode:NSDefaultRunLoopMode];
}
- (void)timerRun {
NSLog(@"%s", __func__);
}
- (void)dealloc {
[self.timer invalidate];
NSLog(@"%s", __func__);
}
@end
这里的TimerViewController是从上一个控制器push过来的，当进入当前控制器的时候，timerRun正常执行。
但是当回退到上一个控制器的时候，发现并没有走当前控制器的dealloc方法，也就是说当前控制器并没有被释放，那么当前控制器强引用的timer对象也没有被释放，这就造成了内存泄漏，如下图所示。
这里的每一个箭头代表着一个强指针，当回退上一个界面时，NavigationController指向TimerViewController的强引用被销毁，但是TimerViewController和timer之间互相强引用，内存泄漏。
解决循环引用
方案一(不可行)
既然说TimerViewController和timer之间互相强引用，那么如果将之间的一个强指针改为弱指针也许能解决问题，于是有了下面的代码
@interface TimerViewController ()
// 这里变为了weak
@property (nonatomic, weak) NSTimer *timer;
@end
@implementation TimerViewController
- (void)viewDidLoad {
[super viewDidLoad];
NSTimer *timer = [NSTimer timerWithTimeInterval:1.0 target:self selector:@selector(timerRun) userInfo:nil repeats:YES];
[[NSRunLoop currentRunLoop] addTimer:timer forMode:NSDefaultRunLoopMode];
// 这里先添加到当前runloop再赋值给timer
self.timer = timer;
}
- (void)timerRun {
NSLog(@"%s", __func__);
}
- (void)dealloc {
[self.timer invalidate];
NSLog(@"%s", __func__);
}
经过上面的改造，现在TimerViewController和timer之间有一个为弱指针，但是运行代码发现，内存泄漏的问题仍然没有得到解决。
因为这里虽然没有循环引用，但是RunLoop引用着timer，而timer又引用着TimerViewController，虽然pop时指向TimerViewController的强指针销毁，但是仍然有timer的强指针指向TimerViewController，因此仍然还是内存泄漏，如下图所示。
方案二
在这里加入了一个中间代理对象LJProxy，TimerViewController不直接持有timer，而是持有LJProxy实例，让LJProxy实例来弱引用TimerViewController，timer强引用LJProxy实例，直接看代码
@interface LJProxy : NSObject
+ (instancetype) proxyWithTarget:(id)target;
@property (weak, nonatomic) id target;
@end
@implementation LJProxy
+ (instancetype) proxyWithTarget:(id)target
{
LJProxy *proxy = [[LJProxy alloc] init];
proxy.target = target;
return proxy;
}
- (id)forwardingTargetForSelector:(SEL)aSelector
{
return self.target;
}
@end
Controller里只修改了下面一句代码
- (void)viewDidLoad {
[super viewDidLoad];
// 这里的target发生了变化
self.timer = [NSTimer timerWithTimeInterval:1.0 target:[LJProxy proxyWithTarget:self] selector:@selector(timerRun) userInfo:nil repeats:YES];
[[NSRunLoop currentRunLoop] addTimer:self.timer forMode:NSDefaultRunLoopMode];
}
首先当执行pop的时候，1号指针被销毁，现在就没有强指针再指向TimerViewController了，TimerViewController可以被正常销毁。
TimerViewController销毁，会走dealloc方法，在dealloc里调用了[self.timer invalidate]，那么timer将从RunLoop中移除，3号指针会被销毁。
当TimerViewController销毁了，对应它强引用的指针也会被销毁，那么2号指针也会被销毁。
-
上面走完，timer已经没有被别的对象强引用，timer会销毁，LJProxy实例也就自动销毁了。
图片.png
这里需要注意的有两个地方：
用到了消息转发
-(id)forwardingTargetForSelector:(SEL)aSelector是什么？
了解iOS消息转发的朋友肯定知道这个东西，不了解的可以去这个博客看看
(https://www.jianshu.com/p/eac6ed137e06)。
简单来说就是如果当前对象没有实现这个方法，系统会到这个方法里来找实现对象。
本文中由于LJProxy没有实现timerRun方法(当然也不需要它实现)，让系统去找target实例的方法实现，也就是去找TimerViewController中的方法实现。timer的invalidate方法的具体作用参考苹果官方，这个方法会停止timer并将其从RunLoop中移除。
This method is the only way to remove a timer from an [NSRunLoop]object. The NSRunLoop object removes its strong reference to the timer, either just before the [invalidate] method returns or at some later point.
3. 方案三
经过上面的改造，似乎timer已经没有什么问题了，但是在浏览yykit源码的时候发现了一个以前一直没有注意过的类NSProxy，这是一个专门用于做消息转发的类，我们需要通过子类的方式来使用它。
参考YYTextWeakProxy的写法，写了如下的代码
@interface LJWeakProxy : NSProxy
+ (instancetype)proxyWithTarget:(id)target;
@property (weak, nonatomic) id target;
@end
@implementation LJWeakProxy
+ (instancetype)proxyWithTarget:(id)target {
LJWeakProxy *proxy = [LJWeakProxy alloc];
proxy.target = target;
return proxy;
}
- (NSMethodSignature *)methodSignatureForSelector:(SEL)sel {
return [self.target methodSignatureForSelector:sel];
}
- (void)forwardInvocation:(NSInvocation *)invocation {
[invocation invokeWithTarget:self.target];
}
@end
Controller里修改了如下代码
- (void)viewDidLoad {
[super viewDidLoad];
// 这里的target又发生了变化
self.timer = [NSTimer timerWithTimeInterval:1.0 target:[LJWeakProxy proxyWithTarget:self] selector:@selector(timerRun) userInfo:nil repeats:YES];
[[NSRunLoop currentRunLoop] addTimer:self.timer forMode:NSDefaultRunLoopMode];
}
看上去这次的LJWeakProxy和前面的LJProxy似乎没有什么区别，好像LJWeakProxy还更复杂一些，但是还是稍微整理一下
LJProxy的父类为NSObject，LJWeakProxy的父类为NSProxy。
LJProxy只实现了forwardingTargetForSelector:方法，但是LJWeakProxy没有实现forwardingTargetForSelector:方法，而是实现了methodSignatureForSelector:和forwardInvocation:。
下面是NSProxy的Apple文档说明，简单来说提供了几个信息
NSProxy是一个专门用来做消息转发的类
NSProxy是个抽象类，使用需自己写一个子类继承自NSProxy
NSProxy的子类需要实现两个方法，就是上面那两个
NSProxy implements the basic methods required of a root class, including those defined in the NSObject protocol. However, as an abstract class it doesn’t provide an initialization method, and it raises an exception upon receiving any message it doesn’t respond to. A concrete subclass must therefore provide an initialization or creation method and override the forwardInvocation: and methodSignatureForSelector: methods to handle messages that it doesn’t implement itself. A subclass’s implementation of forwardInvocation: should do whatever is needed to process the invocation, such as forwarding the invocation over the network or loading the real object and passing it the invocation. methodSignatureForSelector: is required to provide argument type information for a given message; a subclass’s implementation should be able to determine the argument types for the messages it needs to forward and should construct an NSMethodSignature object accordingly. See the NSDistantObject, NSInvocation, and NSMethodSignature class specifications for more information
说了那么多，到底NSProxy的好处在哪呢？
如果了解了OC中消息转发的机制，那么你肯定知道，当某个对象的方法找不到的时候，也就是最后抛出doesNotRecognizeSelector:的时候，它会经历几个步骤
- 消息发送，从方法缓存中找方法，找不到去方法列表中找，找到了将该方法加入方法缓存，还是找不到，去父类里重复前面的步骤，如果找到底都找不到那么进入2。
- 动态方法解析，看该类是否实现了resolveInstanceMethod:和resolveClassMethod:，如果实现了就解析动态添加的方法，并调用该方法，如果没有实现进入3。
- 消息转发，这里分二步
① 调用forwardingTargetForSelector:，看返回的对象是否为nil，如果不为nil，调用objc_msgSend传入对象和SEL。
②如果上面为nil，那么就调用methodSignatureForSelector:返回方法签名，如果方法签名不为nil，调用forwardInvocation:来执行该方法
从上面可以看出，当继承自NSObject的对象，方法没有找到实现的时候，是需要经过第1步，第2步，第3步的操作才能抛出错误，如果在这个过程中我们做了补救措施，比如LJProxy就是在第3步的第1小步做了补救，那么就不会抛出doesNotRecognizeSelector:，程序就可以正常执行。
但是如果是继承自NSProxy的LJWeakProxy，就会跳过前面的所有步骤，直接到第3步的第②小步，直接找到对象，执行方法，提高了性能。
有人可能觉得那为什么不在第3步的第1小步来做补救呢？
但是很不巧，NSProxy只有methodSignatureForSelector:和forwardInvocation:这两个方法，官方的文档里也是让实现这两个方法。
4. 方案四
上面说了那么多，其实还有一种更加简单的方式来解决这里内存泄漏的问题，代码如下
@interface TimerViewController ()
@property (nonatomic, strong) NSTimer *timer;
@end
@implementation TimerViewController
- (void)viewDidLoad {
[super viewDidLoad];
__weak typeof(self) weakSelf = self;
self.timer = [NSTimer scheduledTimerWithTimeInterval:1.0 repeats:YES block:^(NSTimer * _Nonnull timer) {
[weakSelf timerRun];
}];
}
- (void)timerRun {
NSLog(@"%s", __func__);
}
- (void)dealloc {
[self.timer invalidate];
NSLog(@"%s", __func__);
}
上面这种方式虽然TimerViewController强引用timer，但是timer并没有强引用TimerViewController(由于这里的weakSelf)，因此不会出现内存泄漏的问题。
如何在子线程使用NSTimer
有的时候需要在子线程使用NSTimer，下面是代码
@interface TimerViewController ()
@property (nonatomic, strong) NSTimer *timer;
@property (nonatomic, strong) LJThread *thread;
@property (assign, nonatomic) BOOL stopTimer;
@end
@implementation TimerViewController
- (void)viewDidLoad {
[super viewDidLoad];
self.timer = [NSTimer timerWithTimeInterval:1.0 target:[LJWeakProxy proxyWithTarget:self] selector:@selector(timerRun) userInfo:nil repeats:YES] ;
__weak typeof(self) weakSelf = self;
self.thread = [[LJThread alloc] initWithBlock:^{
[[NSRunLoop currentRunLoop] addTimer:weakSelf.timer forMode:NSDefaultRunLoopMode];
// 这里需要注意不要使用[[NSRunLoop currentRunLoop] run]
while (weakSelf && !weakSelf.stopTimer) {
[[NSRunLoop currentRunLoop] runMode:NSDefaultRunLoopMode beforeDate:[NSDate distantFuture]];
}
}];
[self.thread start];
}
- (void)timerRun {
NSLog(@"thread - %@ - %s", [NSThread currentThread], __func__);
}
- (void)dealloc {
[self stop];
}
- (void)stop {
[self performSelector:@selector(stopThread) onThread:self.thread withObject:nil waitUntilDone:YES];
}
// 用于停止子线程的RunLoop
- (void)stopThread {
// 设置标记为YES
self.stopTimer = YES;
// 停止RunLoop
CFRunLoopStop(CFRunLoopGetCurrent());
// 清空线程
self.thread = nil;
}
这里LJThread继承了NSThread，可以看到上面代码中在LJThread的Block中没有通过[[NSRunLoop currentRunLoop] run]来开启当前线程的RunLoop，而是使用了runMode: beforeDate:。
这是由于通过run方法开启的RunLoop是无法停止的，但在控制器pop的时候，需要将timer，子线程，子线程的RunLoop停止和销毁，因此需要通过while循环和runMode: beforeDate:来运行RunLoop。
通过上面的总结可以看到，虽然只是一个小小的Timer，也有这么多地方需要我们注意。
其他:
Timer到底准不准？
可以参考这篇文章:https://www.jianshu.com/p/d5845842b7d3
转载参考：https://www.jianshu.com/p/d4589134358a