Following this question, and more specifically, this comment:
because retain (aka strong reference) cycles in the common case where the timer's target is also its owner
I am wondering why dealloc isn't a good place to invalidate an NSTimer.
I remember profiling my app without auto-repeating NSTimer invalidation and then with invalidation in dealloc, and the memory correctly freed.
Is dealloc working differently in the latest iOS?
Isn't in fact your overridden dealloc called prior to any NSObject deallocation? What is dealloc even used for, then? If not manually deallocating the respective object's properties?
ARC will only release ( and call dealloc ) objects, when there are no strong references pointing to this object ( no one is retaining ).
NSTimer creates strong reference and it will retain target.
This means, dealloc will not be called, because NSTimer still has strong reference to the object. If there is no dealloc, this means NSTimer will never be invalidated ... leads to memory leak or even crashes.
There is a way to invalidate timer in dealloc or when target becomes nil. Have a look at the answer here.
来源：https://stackoverflow.com/questions/40358646/invalidating-an-nstimer-in-dealloc