[头目]随便聊聊关于timerstart、周期性事件、Timer到期事件。

alexries

因为在疑难区看到所以随便提一下。
TimerStart - timerstart的function只能获得触发timer，无法获得触发器ID和事件类型ID，因为它并非一个传统意义上的触发器，不具备触发器一些的特征（甚至你也可以说它不是一个触发器，说它是触发器，是因为它能获得触发timer，符合事件响应机制；说它不是触发器，是因为它和普通触发器的运行方式都不一样）。
周期性事件 - 周期性事件只能获得触发器ID和事件类型ID，无法获得触发timer。
Timer到期事件 - Timer到期事件能获得触发器ID、事件类型ID、触发timer。
而实际上周期性事件的事件ID和Timer到期事件的事件ID是相同的，都是4，EVENT_GAME_TIMER_EXPIRED。所以周期性事件和Timer到期事件本质上是相同的，只是周期性事件使用的是游戏自建Timer，而且没有对jass开放而已。
因此，若要问周期性事件和Timer到期事件哪个效率高占用资源少？毫无疑问的是周期性事件，记住一点，对jass开放handle的对象总是比不对jass开放handle的同类对象占用更多的资源。然而Timer到期事件也有其优势，因为触发器ID事件ID触发Timer都占全了，而且可以随意改变事件的触发间隔，这点比周期性事件当然是方便。
然后timerstart的占用资源自然最少，但它不具备触发器的一些特征，比如无法获得事件类型ID，这样，一个函数要如何得知自己是被timerstart调用的还是被其他什么事件调用的呢？聪明人也许可以从另一个角度解决问题，既然无法获得事件类型ID，那么eventID和触发器ID自然都是0咯。符合这种状况的话，该函数自然就是被timerstart调用的。但是无法获得触发器ID这一特征使得它无法将任何需要触发器id作为参数的函数应用于自身。
另外要注意一个重点，timerstart所执行的function会忽略wait(即TriggerSleepAction())以后的部分。因此如果timerstart所执行的函数中有等待语句，那么等待后面的部分都不会被执行。（这点跟触发器里的条件部分很像）
此外，Timer到期事件和周期性事件由于可以获得触发器ID，就可以得到自身被执行的次数。这点用在一些周期性系统上很方便。而TimerStart的话就必须绑定什么变量来帮它记录了。

又，本帖原来注明的EFF大人所说的周期性事件内存泄露不存在