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上添加我。