事件的优先级有没有

[IDOKN]

[LeoMobileDeveloper]

目前没有优先级，由于事件并不是在一个队列(线程)上发布的，所以优先级不太好定义，有什么好的建议么？

[YinDongWu]

可以考虑一下优先级+事件依赖。 感觉单纯优先级对外使用太宽泛。需要建立多个不同优先级的分区，同优先级有事件依赖的话可以调整串行顺序。

[hellogaojun]

支持粘性事件么,就是支持订阅已经发生的事件?

[LeoMobileDeveloper]

@hellogaojun 不支持，和RAC/RxSwfit不是一个类型的

[hellogaojun]

按照你的思路,确实能在Appdelegate里面实现解耦操作,分割出多个相对独立的模块出来,比增加Appdelegate分类分多个子入口强大一些.但是我的困惑是,这其实就是把原先堆积在Appdelegate里面的代码挪了出来?因为在实际上,无论使用第三方的SDK,还是使用自己的SDK,有一些操作(初始化,回调相关)都是被推荐放在了application: didFinishLaunchingWithOptions:这个方法里.

[LeoMobileDeveloper]

@hellogaojun

初始化的代码是删不掉的。解耦的目的不是减少代码，甚至解耦之后代码总量反而增多了，但是获得的好处是模块相互独立，更容易扩展和修改，并且哪些模块加载了，执行了多久都是可控的。

解耦的前提是有这个需求，如果一个App就3个人维护，并且AppDelegate也没什么代码，那么完全没必要做这件事。当业务/项目发展到一定规模后需要解耦，如果不做，会发现几乎所有的开发都要去修改一个AppDelegate.m文件，这个文件强耦合了十几个甚至几十个类，迭代起来非常困难。

至于SDK初始化的问题：解耦只是做了一层转发和抽象，SDK初始化本质上还是在didFinishLaunchingWithOptions，并没有什么变化。

[dengchenglin]

AppDelegate里的事件分发不太适合异步操作
个人建议是：直接让QTAppModule多遵守一个UIApplicationDelegate协议 ，遍历遵守了QTAppModule的service直接同步调用相应的方法；对比当前的搞法有三个好处：
1、QTAppModule不用自己去一个个敲对应方法，并且方法名参数什么都是原汁原味的；
2、我们拦截系统即时响应的方法，框架不应该强制它是异步的，是否是异步应该由每个service自己去决定, 同步分发这些事件才是合理的;
3、如果同步分发，事件优先级、有返回值的UIApplicationDelegate方法迎刃而解；

[LeoMobileDeveloper]

@dengchenglin AppDelegate的事件是同步分发的

[dengchenglin]

不好意思，我理解错上下文了；囧。。。

[zhousj888]

我模范这个架构做了一个appDelegate的重构
加上了事件的接收优先级和拦截机制
事件按照订阅的顺序进行传递，并且每个订阅者可以拦截这个事件，如果拦截那么之后的订阅者就接收不到这个事件

[YinDongWu]

Appdelegate事件最好不要做拦截操作。 出现问题比较难定位。 发自我的iPhone

…

------------------ 原始邮件 ------------------ 发件人: zhousj888 <notifications@github.com> 发送时间: 2019年7月29日 17:38 收件人: LeoMobileDeveloper/QTEventBus <QTEventBus@noreply.github.com> 抄送: YinDongWu <993169682@qq.com>, Comment <comment@noreply.github.com> 主题: 回复：[LeoMobileDeveloper/QTEventBus] 事件的优先级有没有 (#2) 我模范这个架构做了一个appDelegate的重构 加上了事件的接收优先级和拦截机制 事件按照订阅的顺序进行传递，并且每个订阅者可以拦截这个事件，如果拦截那么之后的订阅者就接收不到这个事件 — You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.

[zhousj888]

我这里把消息订阅者称为plugin，
个人认为如果各个plugin基本没有关联的，类似于notificationCenter的那种事件，可以没有明显优先级和拦截。
要是各个plugin有关联的eventbus，有明显的优先级和拦截机制会更加实用，不然一些情况下的代码会变得繁琐。举个例子：
场景1：openUrl的回调等需要返回值的事件
有拦截机制可以做成这样：加一个OpenUrlPlugin在事件总线上，接收openUrlEvent，并且把返回值放入evnt.retValue中，然后直接拦截事件，那在appDelegate那里就可以直接return event.reValue。
如果没有拦截机制，那可能需要将返回值放入某一个共享变量中，但是这个变量有可能被后续的plugin修改

场景2：
event->error判断->业务1plugin->业务2,3,4,5......
有这样一个场景，如果有error，后面的业务都不需要执行
如果有拦截机制，只要把errorPlugin放在所有业务之前，如果出现了error，就直接拦截事件，非常简单
如果没有拦截机制的话，可能要把error信息放在一个共享变量里面，之后所有的业务plugin都要判断一下这个error变量