RxAndroid，事件总线和Activity生命周期

Question

我发现一些文章谈论RxJava / RxAndroid如何取代事件总线（如otto ）

• https://lorentzos.com/rxjava-as-event-bus-the-right-way-10a36bdd49ba#.7a4619qva
• https://medium.com/mobiwise-blog/use-rxjava-instead-of-event-bus-libraries-aa78b5023097#.ew28h2urf

第一篇文章的引用：

来自Square的Otto在前几天被正式弃用。 在Android世界中，我们现在可以为“EventBusses死了很长的RxJava”而欢呼。

但我有一件事是：

事件总线的一个好处是它们对Activity生命周期有很大的帮助，因为你不需要手动管理注册/取消注册回调（从而避免内存泄漏）

示例流程：

• 活动订阅获取歌曲的事件（比如SongsAvailableEvent）
• 我们要求歌曲（我们提出网络请求）
• 我们在请求中更改设备的方向
• Activity死了，构建了一个新的，也订阅了SongsAvailableEvent
• 新活动获取事件并更新UI，旧活动（现在已经死了）没有得到事件（耶！）

上面的文章看起来这个流程是由RxAndroid / RxJava“解决”的，但是使用Rx时，你仍然需要在更改设备的方向时手动订阅/取消订阅Observable。 此外，如果我想“重用”Observable中的请求，我需要以某种方式持久化它，以便我将在新Activity中订阅相同的Observable（我不太确定如何做到这一点，但它是不是重点:)）。

我的问题是：这个问题是否可以用纯RxAndroid / RxJava轻松解决，或者我是否仍然需要使用事件总线/扩展Rx使用RxLifecycle之类的东西 （由于我不在表示层管理我的Observables使事情变得复杂） ？

Answer 1

您的活动的onDestroy总是可以调用取消订阅。

至于使工作重用请求 - 查看Loaders和LoaderManager。 EventBus和RxJava解决这个问题从来都不需要。

Answer 2

我冒昧地说，没有任何方法可以在链中的某个点上将Observable绑定到某些Android平台对象的生命周期，例如Activity。 此外，因为您没有将其作为部分解决方案提及，我假设您正在避免使用保留的碎片。 如果您仅在活动中创建并保持对Observable的引用，则在运行中请求的结果不可能在销毁活动后继续存在并自动订阅新活动。 此外，在某些时候，无论是在方向更改期间，还是在网络请求中间的活动结束时，如果未在活动中取消订阅，您的Observable将泄漏对活动的引用（通过其subscribe()回调）。 onDestroy() 。

我发现RxLifecycle易于使用。 我的基类Activity类有一个方法：

public <T> Observable.Transformer<T,T> bindLifecycleOnMainThread() {
    return o -> o.compose(lifecycleProvider.bindToLifecycle())
        .observeOn(AndroidSchedulers.mainThread());
}

lifecycleProvider是根据RxLifecycle的说明创建的，具体取决于您创建提供程序的方式。 此特定实现使用bindToLifecycle()而不是指定显式生命周期事件，因此它的使用是上下文。 在onResume期间调用它将导致它在onPause上结束。 在onStart期间onStart它将使其在onStop上onStop 。 其他时间调用它会导致它在onDestroy上结束。 由于此订阅将更新UI，因此只能在UI线程上观察。

然后可以在Activity中使用，如下所示：

yourObservable.compose(bindLifecycleOnMainThread())
    .subscribe(event -> handleEvent(event));

现在，这个观察源从何而来？ 好吧，仍然没有魔法，如果你想让一个Observable比Activity更长寿命，那就意味着Observable必须由一个比Activity活动更久的组件持有。 有许多方法可以做到这一点，但您的特定用例很好地映射到Android架构框架中包含的新ViewModel库。 如果你要使用ViewModel，你的ViewModel会有一个开始网络请求的方法，并且会有一个PublishSubject SongsAvailableEvent对象的PublishSubject或PublishRelay （虽然我建议将它作为一个Observable<SongsAvailableEvent>暴露给你的Activity，而不是主题，为了良好的封装！）。 您的ViewModel将进行网络呼叫并将结果转发给您的主题。

最后，您的Activity在创建时将立即从ViewModel注册表获取其ViewModel，并订阅ViewModel Observable<SongsAvailableEvent>的Observable<SongsAvailableEvent> （这是一个主题/中继），然后将其绑定到Activity的生命周期，如上面的例子。 ViewModel将在Activity的任何方向更改后继续存在，因此observable也将如此。 然后，Observable将永远不会尝试将事件传递给已销毁的Activity，新的Activity将立即开始侦听事件。

我相信这种策略可以促进良好的封装，因为Activity不关心网络请求是如何产生的，并且不关心如何创建源Observable。 Activity操作Observable的唯一方法是选择接收事件时发生的事情，并将订阅绑定到Activity的生命周期。

这可以通过组合你的Observable来无休止地调整和改进，但这应该让你顺利。