这一系列文章本来我发表在简书。最近开始转移到掘金。以后也会在掘金发表（慢慢抛弃简书了应该，掘金的技术环境确实比简书好些）。
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().
总结：
前几天我在Reddit上看到一个人的回复：
I think EventBus on android is popular because people don't know how to share a java object reference between android components like a Fragment and an Activity, or 2 Activities and so on. So basically I think people don't know how 2 Activites can observe the same object for data changes which I think comes from the fact that we still don't know how to architect our apps properly.
我认为 EventBus在Android上火爆的原因是人们不知道怎么去在Android组件，例如Activity/Fragment之间共享一个Java对象的引用。
这个回复可以说应该是触到了很多人的痛点。很多情况我们用EventBus仅仅是不知道如何在多个Fragment/Activity之间共享一个对象。EventBus的做法是在Bus里登记所有的接受者。这点在RxJava里类似，Subject/ConnectableObservable 都有类似的功能。但问题是EventBus作为一个全局Bus，各种不同类型的事件管理会很麻烦（虽然EventBus把这些事给你做好了，RxBus要自己弄）。我们有了RxJava完全可以避免不同事件的管理。相同事件封装成对应Observable，根据需求选择订阅。这样保持了类型安全，提高了性能，逻辑更清晰。
想一想，自己使用EventBus是不是也是这个原因呢？
