NSTimer in iOS

[[139776]]

When I was organizing the company's project a while ago, I found that the old code had a memory leak when using NSTimer. Then I organized some NSTimer related content. It's relatively simple, please forgive me.

NSTimer

fire

Let's use NSTimer to make a simple timer, outputting Fire to the console every 5 seconds. The more obvious approach is this:

 @interface DetailViewController ()
 @property (nonatomic, weak) NSTimer *timer;
 @end  
 @implementation DetailViewController
 - (IBAction)fireButtonPressed:(id)sender {
 _timer = [NSTimer scheduledTimerWithTimeInterval: 3 .0f
 target:self
 selector: @selector (timerFire:)
 userInfo:nil
 repeats:YES];
 [_timer fire];
 }
 -( void )timerFire:(id)userinfo {
 NSLog(@ "Fire" );
 }
 @end  

After running, Fire is indeed output in the console every 3 seconds. However, when we jump from this interface to other interfaces, we find that the console is still outputting Fire continuously. It seems that the Timer has not stopped.

 invalidate 
 
 Since it is not stopped, let's add the invalidate method in the dealloc of DemoViewController: 
 
 -( void )dealloc {
 [_timer invalidate];
 NSLog(@ "%@ dealloc" , NSStringFromClass([self class ]));
 }

Run again, still does not stop. The reason is that when the Timer is added to the Runloop, it will be strongly referenced by the Runloop:

 Note in particular that run loops maintain strong references to their timers, so you don't have to maintain your own strong reference to a timer after you have added it to a run loop.

Then Timer will have a strong reference to Target (that is, self):

 Target is the object to which to send the message specified by aSelector when the timer fires. The timer maintains a strong reference to target until it (the timer) is invalidated.

That is to say, NSTimer strongly references self, causing self to never be released, so it cannot enter self's dealloc.

In this case, we can add an invalidate button:

 - (IBAction)invalidateButtonPressed:(id)sender {
 [_timer invalidate];
 }

Well, that's it. (Someone on SOF said that _timer = nil should be executed after invalidate, but I don't understand why. If you know the reason, please tell me:)

There is also this paragraph in the documentation of the invalidate method:

 You must send this message from the thread on which the timer was installed. If you send this message from another thread, the input source associated with the timer may not be removed from its run loop, which could prevent the thread from exiting properly.

NSTimer must be stopped on the thread where it was created, otherwise the resources will not be released correctly. It seems that there are many pitfalls.

dealloc

So the question is: If I just want this NSTimer to keep outputting until DemoViewController is destroyed, how can I stop it?

NSTimer is strongly referenced by Runloop. If you want to release it, you must call the invalidate method.

But I want to call the invalidate method in the dealloc of DemoViewController, but self is strongly referenced by NSTimer.

So I still have to release NSTimer first, but I can't release it without calling the invalidate method.

However, I cannot call the invalidate method if you don't enter the dealloc method.

Um…

HWWeakTimer

weakSelf

The key to the problem is that self is strongly referenced by NSTimer. If we can break this strong reference, the problem will be solved naturally. So a very simple idea is: weakSelf:

 __weak typeof(self) weakSelf = self;
 _timer = [NSTimer scheduledTimerWithTimeInterval: 3 .0f
 target:weakSelf
 selector: @selector (timerFire:)
 userInfo:nil
 repeats:YES];

However, this is useless. The difference between __weak and __strong here is that if self is released during the execution of these two lines of code, the target of NSTimer will become nil.

target

Since we can't extract self through __weak, we can create a fake target for NSTimer. This fake target is like an intermediary agent, and its main job is to step forward and take over the strong reference of NSTimer. The class declaration is as follows:

 @interface HWWeakTimerTarget : NSObject
 @property (nonatomic, weak) id target;
 @property (nonatomic, assign) SEL selector;
 @property (nonatomic, weak) NSTimer* timer;
 @end  
 @implementation HWWeakTimerTarget
 - ( void ) fire:(NSTimer *)timer {
 if (self.target) {
 [self.target performSelector:self.selector withObject:timer.userInfo];
 } else {
 [self.timer invalidate];
 }
 }
 @end  

Then we encapsulate a fake scheduledTimerWithTimeInterval method, but we have already replaced the original method when calling it:

 + (NSTimer *) scheduledTimerWithTimeInterval:(NSTimeInterval)interval
 target:(id)aTarget
 selector:(SEL)aSelector
 userInfo:(id)userInfo
 repeats:(BOOL)repeats {
 HWWeakTimerTarget* timerTarget = [[HWWeakTimerTarget alloc] init];
 timerTarget.target = aTarget;
 timerTarget.selector = aSelector;
 timerTarget.timer = [NSTimer scheduledTimerWithTimeInterval:interval
 target:timerTarget
 selector: @selector (fire:)
 userInfo:userInfo
 repeats:repeats];
 return timerTarget.timer;
 }

Run again and the problem is solved.

block

Wouldn't it be better if we could use a block to call NSTimer? We can do this like this:

 + (NSTimer *)scheduledTimerWithTimeInterval:(NSTimeInterval)interval
 block:(HWTimerHandler)block
 userInfo:(id)userInfo
 repeats:(BOOL)repeats {
 return [self scheduledTimerWithTimeInterval:interval
 target:self
 selector: @selector (_timerBlockInvoke:)
 userInfo:@[[block copy], userInfo]
 repeats:repeats];
 }
 + ( void )_timerBlockInvoke:(NSArray*)userInfo {
 HWTimerHandler block = userInfo[ 0 ];
 id info = userInfo[ 1 ];
 // or `!block ?: block();` @sunnyxx  
 if (block) {
 block(info);
 }
 }

In this way, we can write the relevant logic directly in the block:

 - (IBAction)fireButtonPressed:(id)sender {
 _timer = [HWWeakTimer scheduledTimerWithTimeInterval: 3 .0f block:^(id userInfo) {
 NSLog(@ "%@" , userInfo);
 } userInfo:@ "Fire" repeats:YES];
 [_timer fire];
 }

Yeah, that's it.

More

The above code is simply encapsulated into HWWeakTimer, welcome to try it.