et的事件监听需要写AEvent,而AEvent不关联真正对事件感兴趣的实体
比如角色金币改变，抛出事件，如果我有10个界面对金币改变事件是监听的，由于事件抛出并不知道哪个界面是打开的，那AEvent里就要尝试获取这10个界面，即便这10个界面一个都没打开，然后调用获取到的界面的OnGoldUpdate()方法
以前一直用的是回调方式，界面打开的时候把界面的OnGoldUpdate方法注册给金币改变事件，事件触发时就会直接调到界面实例的OnGoldUpdate方法
cheric https://github.com/XuToWei/ET-DynamicEvent 可以看看这个满足你的要求
有啥问题呢？
egametang 没什么问题哦,我是照着ET的模板在写的，功能逻辑也都是实现了的，我就是在写AEvent的时候在想如果是类似ATimer,实例主动注册事件(但不是说就是ATimer这样的实现)，就可以少一些无谓的逻辑，毕竟事件触发知道要走什么逻辑，但是并不知道这段逻辑对应的实体是不是存在实例，比如一个非常具体化的任务关心角色金币消耗，金币消耗事件去找是不是有这个任务和这个具体任务注册给金币消耗事件的区别吧，达成的效果肯定没差别
就是单纯的表达一些想法，向大佬学习一些思路😁
et这样做，代码可读性更好，而且能够热重载
兄弟你表达有问题哦，看了几遍才看懂你的意思。AEvent 里不是去遍历所有的界面的，这样实现是不对的，你不知道哪些界面是要监听的。 正确的是要一个AEvent 对应一个界面 ，加一个监听就加一个AEvent
Long 嗯，我只是描述的简单了一点，但是表达的意思是一样的，10个界面10个AEvent,每个AEvent里获取自己对应的界面，获取到了就调用方法，没获取到就不调用，跟一个AEvent里直接处理这10个界面，都是事件抛出时判断了这10个界面是否存在，我主要表达的是，这10个调用即便没有界面存在也会被调用，而不是像那种 控制反转，界面存在才会被走逻辑，界面不在，压根都没逻辑。
就像ATimer，实例不在，是不会有逻辑的，只有实例注册过，才会有ATimer逻辑。多了注册跟反注册
Long 我不是说一个AEvent里去遍历所有的界面，我是说他至少要走一遍对这个Event感兴趣的界面，但是这些界面不一定存在。游戏里有100个界面，有5个界面对EventA要做界面刷新，EventA抛出时，在EventHandle里要找一下这5个界面的实例然后调刷新方法吧，至于是5个EventHandle还是一个EventHandle不是重点吧
而且也不是单指界面，指的是对事件感兴趣的类型实例，可能是界面实例，任务实例，人物实例，成就实例
cheric 你这个还是oop的思想了。 存不存在判断一下不久完了吗。比如界面，打开的界面存在字典里。一个AEvent 持有一个key，判断一下在不在字典，在就拿出来刷新不就好了。 oop的注册跟反注册 不就对应 添加和移除字典了
cheric 只用一个AEvent 放10 个key也可以，随便搞
去找一下，有啥问题呢？这样代码非常清晰呀
XuToWei 感谢分享，非常有用，提供了一种思路
你指的是应该是动态Event吧,好多人提这个问题了,如果想自己搞的话参考下https://github.com/XuToWei/ET-DynamicEvent