为什么事件通常在调度时创建？
如果事件永远不会改变，那么将事件存储在调度程序上似乎更有效。创建它们不是很昂贵吗？如果我发送已存储的事件，是否会丢失某种信息？
It seems more efficient to store events on the dispatcher if they're never going to change. Isn't creating them costly? Is there some kind of information I'm losing if I dispatch an already-stored event?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
本质上，您要求的是对象池的特定用例，以及对象池与对象创建的性能。像 Java 这样的语言并不能从对象池中获得太多好处，因为 Java 已经为您做到了这一点。而且比你自己做更好。事实上，Java 工程师已经明确表示您不应该这样做，因为 Java 比您能更好地分配、扩展和处理数千个对象。这就是 GC 的全部意义。 Java 中的对象分配已经为您进行了池化，但在较低级别上，这就是 Java 和其他语言中的内存分配比 C 快得多的原因。Java 中分配的每个对象都来自 JVM 准备好的内存池。
http://www.ibm.com/developerworks /java/library/j-jtp09275.html?ca=dgr-jw22JavaUrbanLegends
事件在调度时创建而不是缓存它们的另一个原因是它们携带在每次调度之间更改的参数。例如，输入了什么字符、单击了鼠标的位置等。回收事件可能听起来是个好主意，直到您这样做为止，然后突然间您将使用错误的事件发送旧信息。最好每次都新建该事件并让它使用正确的数据正确初始化自身。对于作者来说更简单并且更不容易出错。
如果重用事件，您还可能会遇到技术问题。事件取消方案通常将该信息存储在由某个侦听器分派后修改的事件中。在动作脚本中，您可以使用 event.preventDefault() 来影响事件侦听器的链接。如果在调用 PreventDefault 后开始重用该事件，会发生什么情况？什么时候可以安全地说该事件没有被尚未触发的侦听器使用（callLater/invokeLater 使其变得困难）。 Java/Actionscript 中都没有回调表明该事件可以重用（没有回收语义将对象返回到池中）。
这并不是说您可以找到保留事件并重用它的效果更好的情况。但是，仅仅因为它对于那些高性能情况来说更快并不意味着它每次都是一个好主意。请记住，在知道存在问题之前不要进行优化。
Essentially what your asking is a specific use case of object pooling, and the performance of object pooling vs. object creation. Languages like Java don't get much benefit from object pooling because Java does this for you. And does it better than if you were to do it on your own. In fact Java engineers have made it very clear you shouldn't do this because Java allocates, scales, and handles thousands of objects better than you can. That's the whole point of GC. Object allocation in Java is already doing pooling for you, but at a lower level that's why memory allocation in Java and other languages is way faster than C. Every object allocated in Java comes from a ready made memory pool by the JVM.
http://www.ibm.com/developerworks/java/library/j-jtp09275.html?ca=dgr-jw22JavaUrbanLegends
Another reason events are created at dispatch time, instead of caching them, is they carry parameters in them that change between each dispatch. For example, what character was typed, where the mouse was clicked, etc. Recycling events might sound like a good idea until you do it, and all of a sudden you're sending old information with the wrong event. Better to just new that event up each time and have it properly initialize itself with the right data. It's simpler for the author and less error prone.
There are also technical problems you might encounter if you reused events. Event cancellation schemes usually store that information in the event that is modified after dispatch by some listener. In actionscript you can say event.preventDefault() to affect the chaining of event listeners. What happens if you start reusing that event after preventDefault has been called? And at what time is it safe to say this event isn't being used by a listener that has yet to fire (callLater/invokeLater makes it hard). There's no callback in either Java/Actionscript that says this event is ok to reuse (no reclamation semantics to return the object to the pool).
That's not to say you could find a case where holding onto the event and reusing it performs better. But, just because it's faster for those high performance cases doesn't mean it's a good idea for everything every time. Remember don't optimize until you know there's a problem.