在 iOS 的 NSTimer 中使用 invalidate？
Using invalidate in NSTimer in iOS?
假设我用代码创建了一个 NSTimer。该代码调用一个函数，该函数在 90 秒后关闭视图控制器
- A) 是否每次在该视图时都需要 InValidate NSTimer
控制器解雇？
- B) invalidate有什么用？什么时候
使用无效？
- C) 如果我不使用 invalidate 会导致任何一方
内存泄漏之类的效果？ （已编辑）
请说明。
如果你还没有，我鼓励你复习一下 documentation for NSTimer，因为你的三个问题中的两个在那里得到了明确的回答（重点在我的下面）：
A) Is it necessary to InValidate NSTimer every time when that view controller dismisses?
Comparing Repeating and Nonrepeating Timers
You specify whether a timer is repeating or nonrepeating at creation time. A nonrepeating timer fires once and then invalidates itself automatically, thereby preventing the timer from firing again. By contrast, a repeating timer fires and then reschedules itself on the same run loop [...]
B) What is the use of invalidate? And when to use invalidate ?
Stopping a Timer
-
Stops the timer from ever firing again and requests its removal from its run loop.
C) If i don't use invalidate will it cause any side effects like Memory Leak? (edited)
上面链接的文档没有明确说明使用 NSTimer 的这一特定方面，但简单的搜索在下面产生了特别有用的 Stack Overflow question regarding NSTimer-related memory management. I've included the most relevant content from the accepted answer：
Yes, NSTimer will maintain a strong reference to the target, which can cause (especially in repeating timers) strong reference cycles (a.k.a. retain cycles). In your example, though, the timer does not repeat, and is delayed only 0.5, so worst case scenario, you will have a strong reference cycle that will automatically resolve itself in 0.5 seconds.
But a common example of an unresolved strong reference cycle would be
to have a UIViewController with a NSTimer property that repeats,
but because the NSTimer has a strong reference to the
UIViewController, the controller will end up being retained.
So, if you're keeping the NSTimer as an instance variable, then,
yes, you should invalidate it, to resolve the strong reference
cycle. If you're just calling the scheduledTimerWithTimeInterval,
but not saving it to an instance variable (as one might infer from
your example), then your strong reference cycle will be resolved when
the NSTimer is complete.
假设我用代码创建了一个 NSTimer。该代码调用一个函数，该函数在 90 秒后关闭视图控制器
- A) 是否每次在该视图时都需要 InValidate NSTimer 控制器解雇？
- B) invalidate有什么用？什么时候 使用无效？
- C) 如果我不使用 invalidate 会导致任何一方 内存泄漏之类的效果？ （已编辑）
请说明。
如果你还没有，我鼓励你复习一下 documentation for NSTimer，因为你的三个问题中的两个在那里得到了明确的回答（重点在我的下面）：
A) Is it necessary to InValidate NSTimer every time when that view controller dismisses?
Comparing Repeating and Nonrepeating Timers
You specify whether a timer is repeating or nonrepeating at creation time. A nonrepeating timer fires once and then invalidates itself automatically, thereby preventing the timer from firing again. By contrast, a repeating timer fires and then reschedules itself on the same run loop [...]
B) What is the use of invalidate? And when to use invalidate ?
Stopping a Timer
Stops the timer from ever firing again and requests its removal from its run loop.
C) If i don't use invalidate will it cause any side effects like Memory Leak? (edited)
上面链接的文档没有明确说明使用 NSTimer 的这一特定方面，但简单的搜索在下面产生了特别有用的 Stack Overflow question regarding NSTimer-related memory management. I've included the most relevant content from the accepted answer：
Yes,
NSTimerwill maintain a strong reference to thetarget, which can cause (especially in repeating timers) strong reference cycles (a.k.a. retain cycles). In your example, though, the timer does not repeat, and is delayed only 0.5, so worst case scenario, you will have a strong reference cycle that will automatically resolve itself in 0.5 seconds.But a common example of an unresolved strong reference cycle would be to have a
UIViewControllerwith aNSTimerproperty that repeats, but because theNSTimerhas a strong reference to theUIViewController, the controller will end up being retained.So, if you're keeping the
NSTimeras an instance variable, then, yes, you shouldinvalidateit, to resolve the strong reference cycle. If you're just calling thescheduledTimerWithTimeInterval, but not saving it to an instance variable (as one might infer from your example), then your strong reference cycle will be resolved when theNSTimeris complete.