为什么避免使用EventBus/RxBus

发布网友 发布时间：2022-04-20 08:05

我来回答

共1个回答

热心网友 时间：2022-04-20 07:42

EventBus和Otto在之前作为Android组件间通信工具，简单方便十分受欢迎，但是也非常容易Abuse。大概有如下几个缺点：

由于是Event,在发布Event的时候就要做好准备可能并没有人接受这个Event, Subscribe的时候也要做好准备可能永远不会收到Event。Event无论顺序还是时间上都某种程度上不太可控。如果你将数据寄托在Event上然后就直接在Android其他生命周期方法中直接使用这个数据或成员变量。那么很有可能你会得到NPE。

EventBus看似将你的程序解耦，但是又有些过了。我们常常使用EventBus传数据，这已经是Dependency级别的数据而不是一个可以被解耦出来的模块。这样就造成了过多EventBus的代码会造成代码结构混乱，难以测试和追踪，违背了解耦的初衷。这时如果有意或无意的造成了Nested Event。那情况会更糟。

由于EventBus的种种缺点，以及后面RxJava的出现。很多人都开始使用RxJava来取代EventBus。甚至Otto的官方介绍里都写到：

Deprecated!

This project is deprecated in favor of RxJava and
RxAndroid. These projects permit the same event-driven
programming model as Otto, but they’re more capable and offer better control of threading.

If you’re looking for guidance on migrating from Otto to Rx, this post
is a good start.

链接是一个教你怎么使用RxJava来自己手动写一个RxBus来代替EventBus的文章。虽然看起来是在用RxJava。但是实际上却仍然在用EventBus。甚至这个封装其实也并没有GreenRobot或者Otto来的好。
我们看看Jake Wharton对RxBus的评价：



我想"RxBus"唯一的好处就是他是一个Rx的入门*。否则的话，你要么就不是在用Rx，要么你需要更加惯用的Rx资源 (渣翻译见谅)

再来一个GitHub的：


subscribeActual部分我们先不考虑。然而Jake指出最好不要使用Relay来“重新发明”Event Bus.

这里看图说话：
Jake Wharton在GOTO 2016 上的讲座中提到，我们正常的Android编程是这样的：



我们像一个中间人一样。
而使用RxJava。 我们的结构，更像这样



我们使用RxJava来直接把组件相连，对所接受到的数据作出反应，所谓的 "Reactive"。
而使用Eventbus? Jake 没说， 我自己画一个：


我们作为一个中间人，传递消息。EventBus作为另一个中间人。帮我们传递消息。（这也就是所谓的“看似解耦”）

再打个比方，虽然我们将EventBus翻译成时间总线，但是其实总线就是Bus也就是公交车。而RxJava更像一个专车，Uber或者滴滴。他直接链接你的两个或多个需要通信的类。传输数据，当然你可以做一个很大的专车，穿梭在所有类之间，也就是所谓的RxBus。所以在这里为什么放弃RxBus也就不言而喻了不是？

那么，问题来了？

怎样才是正确（正常？）的RxJava使用方式？

其实Jake 也在GitHub的讨论上给出了一个答案：


所以应该是，每当你想发布一个Event在EventBus时，直接暴露一个Observable出来。每当你想接受一个Event时，找到这个Observable并且Subscribe他。

这样做的好处是什么？

目标和地点都很明确。你的Subscriber明确的知道他Subscribe的是谁，而且明确的知道我需要作出什么反应。这也正是RxJava的核心“响应式编程”。

由于使用了Observable,对于异常处理将会非常方便。而且还有功能强大全面的Operator来辅助你。

虽然看起来耦合性有所增加。但是这是必要的，上面也说过，EventBus虽然在代码上看似解耦。其实他们还是联系在一起的。而我们这样直接暴露Observable给需要的其他类，这完成了1 -> 1/N的链接，而不需要EventBus这个中间人来传递消息/事件，而且保证我们需要的事件一定会直接到达。

我们来举个例子

上下两个Fragment，上面的一个EditText，下面的一个TextView。上面的EditText变化的时候下面的TextView也跟着变化。

先把EditText的TextChangedListener封装在Observable里：

       stringObservable = Observable.create(e -> editText.addTextChangedListener(new TextWatcher() {
           @Override
           public void beforeTextChanged(CharSequence s, int start, int count, int after) {

           }

           @Override
           public void onTextChanged(CharSequence s, int start, int before, int count) {
               e.onNext(s.toString());
           }

           @Override
           public void afterTextChanged(Editable s) {

           }
       }));

/**
***
*/
   //Expose Observable
   public Observable<String> getEditTextObservable() {
       return stringObservable;
   }


不习惯自己封装可以使用RxBinding :

       stringObservable = RxTextView.textChangeEvents(editText)
                                    .map(event -> event.text().toString());


再从我们的TextViewFragment中 取到这个封装好的Observable:

   @Override
   public void onStart() {
       super.onStart();
       FragmentEditText fragment = (FragmentEditText) getFragmentManager().findFragmentByTag(FragmentEditText.TAG);
       if(fragment != null){
           fragment.getStringObservable().subscribe(s -> textView.setText(s));
       }
   }


来看看效果：

当然，这里还有个问题

由于我们将editText封装在Observable里，无论是create()方法还是使用RxBinding，都会持有这个View的强引用。造成内存泄漏。所以我们一定要在最后加入dispose()方法来释放。所以我推荐使用RxBinding，他已经帮我们在dispose()方法里写好了解除Listener的方法。

因为并没有使用publish操作符，导致多个Subscriber的时候还是有些许问题。可以考虑直接加入.share().