Vecige

@yulingtianxia 直接替换有风险的。因为有做持久化，如果重启后，CACurrentMediaTime()会被重置，now = 0, now -rule.lastTimeRequest > rule.durationThreshold一直不成立。那可能这个事件永远触发不了。

@yulingtianxia 我考虑重启后用NSDate的原因：重启后第一次执行该方法，用户可以手动改时间触发，然后记录的machTime就是新的了，之后再改日期能正确触发，直到再重启。如果用户遇到这个问题，能提供个简单的解决方案。 如果要持久化的话，只有用服务器时间最安全，但是都用到接口了，后端肯定自己有验证了。我没遇到过对移动端节流时间要求这么高的场景，我遇到的一般是为了减小服务端压力，避免接口并行，或者是避免push两遍。如果按照一般场景，重启后直接放行方法执行就可以了。

@yulingtianxia 嗯。这样可以。 要不要提供一个重置lastTimeRequest的方法，重启后传时间偏移量或者直接重置lastTimeRequest。

@yulingtianxia 提供一个纠正时间偏移量的方法确可以解决安全问题，但是使用起来并不方便，很多应用都是没有跟后台同步时间的。这需要后台提供接口或者通过HTTP Header获取时间。HTTP Header还要考虑地区、多语言的问题。 需要较严格时间校验(需要本地化)，但在极端情况下(修改时间并重启)，不做校验避免方法永远不能触发。 我认为这个需求还是比较常见的，应该考虑提供一种更方便的重置方法或者干脆加一个校验模式的枚举。

@yulingtianxia 我还是觉得不行。点击按钮A执行logA方法，现在限制logA方法30秒内只能执行1次。用户点击按钮A触发了一次logA方法，这个时候用户再切到后台修改手机时间，然后点击按钮A又可以触发logA方法了。 除非每一次点击按钮A的时候都去跟服务器校正时间，这样真的不好。