EventBus 3.0 从入门到精通——EventBus的应用场景

时间:2021-11-25 18:20:01

文章索引:
EventBus 3.0 从入门到精通——初识EventBus
EventBus 3.0 从入门到精通——EventBus的应用场景
EventBus 3.0 从入门到精通——使用详解(一)

通过上一篇文章我们对EventBus有了一个简单的了解,这篇我们继续学习一下EventBus的应用场景。

什么时候可以使用EventBus?

首先因为EventBus是一个发布/订阅框架,所以它使用了观察者模式。

观察者模式定义了一种一对多的依赖关系,让多个观察者对象同时监听某一个主题对象。这个主题对象在状态发生变化时,会通知所有观察者对象,使它们能够自动更新自己。

看观察者模式的定义我们就能看到,EventBus是为了解决数据的同步或者事件的传递而产生的。
所以一般可以在以下几种情况中使用EventBus:

  • 一个事件可以同时触发多个对象的数据更新或者UI变化;
  • 多个没有直接关联的对象之间的同步操作;
  • 对象之间传递复杂事件的解耦

简单分析一下:比如微博的一个点赞事件,当用户在微博页面点赞时触发一个用户点赞事件。事件被触发后需要同时更新微博页面的点赞按钮的UI以及微博点赞列表的数据,并且还要更新用户基本信息中的曾经点赞过的微博的信息等等,它们的优先级基本差不多这个时候就可以使用EventBus来处理这个事件的发布和订阅。再比如我们的App主页面有4个Tab它们是互相独立的模块,但是我在tab1的一个操作会影响到Tab2或者Tab3的UI显示也可以考虑使用EventBus。

总结一下EventBus的优缺点:
优点:

  • 灵活性高,不依赖于 Context,无需引用Context更加灵活方便;
  • EventBus的事件处理可以继承,这样使得代码更加简洁更符合面向对象的设计;
  • EventBus有事件优先级,可以使得Subscriber(订阅者)处理最关注的事件;
  • 粘滞事件(sticky events)能够保证事件不会因 Subscriber 占时无法接收事件而丢失;
  • 使用简单。EventBus 的注册和反注册,以及事件的定义和接受者的声明都非常的简单和灵活;
  • 将事件的发布者和订阅者解耦;
  • 轻量级并且性能很好;

缺点:

  • 观察者模式可能会造成接口的膨胀,增加工程中类的数量;
  • 使用者要对事件有一定的认识,简单的事件或者接口调用最好不要使用EventBus,否者代码的可读性和逻辑上都会很复杂;

总结一下:
App内部的消息通信,在单纯依靠接口调用和回调的方式处理复杂或者不好处理,以及消息存在多个关注对象的情况下可以使用EventBus,而且相对BroadcastReceiver等广播组件而言,EventBus处理起来更加轻量级和解耦。