NSTimer代表NoSwiftyTimer
NSTimer是Apple提供的创建计时器的最简单机制之一。
您可能已经看到它适用于多种用途:在一定的延迟后显示或隐藏视图,定期更新的视图或周期性或延迟执行的任何其他任务。 毫无疑问,它们是非常通用且功能强大的工具。
NSTimer基本上只是在等待特定时间间隔之后,然后将特定消息触发到其目标。
如您所见,我在这里谈论消息和目标。 这是第一个问题出现的地方。 目标和消息听起来不是很迅速,对吗?
最近,我不得不使用NSTimers,我发现了一些令人讨厌的细节。
首先,正如我们所看到的,它具有基于Objective-C运行时的非常古老的时尚语法,使用目标和选择器而不是闭包,这使它们在我的Swift代码中看起来像一条鱼。
另一方面,更重要的是,如果您不关注ARC,则NSTimers是在应用程序中引入内存泄漏的最简单方法之一。 为什么? 好吧,请检查以下示例:
从NSTimer到SwiftyTimer
苹果在NSTimer的文档中留下了非常明确的信息:
子类化注释 :您不应尝试将NSTimer子类化。
由于这个原因,我决定使用组合来创建我的自定义Swifty版本的NSTimers。 基本上将它们包裹起来,将其讨厌的部分扫到地毯下。
但这将使我能够解决这两个问题,获得更快捷的语法并更容易避免内存泄漏。
使用这个简单的包装器,我们能够以非常简单且易读的方式避免来自计时器的强烈引用。
再一次,如果您将此代码复制到操场上,您将看到它现在生成另一个输出:
你好
再见
多亏了附加层,我们得以避免内存泄漏,因为NSTimer现在保留的不是使用计时器的代码,而是SwiftyTimer的实例。
当然,我们在SwiftyTimer和NSTimer之间仍然有一个保留周期,但是通过使用SwiftyTimer的invalidate
方法,我们可以轻松打破这一局面。
在这一点上,快速化定时器的使用,使用参数的默认值并利用闭包是一项非常容易的任务。
最后获得一个更具可读性和更少错误的解决方案。
结论
Apple可能(并希望)很快会给仍然需要它的那些API带来所有的爱和温柔,但是与此同时,它们是创造力的好借口,因此获得了更具可读性和安全性的代码……害羞!
如有任何疑问,请随时在github,twitter或dcordero.me上添加我。