Почему в этом случае важно избавиться от DisposableObserver

Я работаю над проектом Android с чистой архитектурой.

У меня есть класс ниже:

public abstract class RxBaseInteractor<T, Params> {

  private final CompositeDisposable disposables;

  public RxBaseInteractor() {
    this.disposables = new CompositeDisposable();
  }

  abstract public Observable<T> buildUseCaseObservable(Params params);

  public void execute(DisposableObserver<T> observer, Params params) {
    Preconditions.checkNotNull(observer);
    final Observable<T> observable = this.buildUseCaseObservable(params)
        .subscribeOn(Schedulers.io())
        .observeOn(AndroidSchedulers.mainThread());
    addDisposable(observable.subscribeWith(observer));
  }

  public void dispose() {
    if (!disposables.isDisposed()) {
      disposables.dispose();
    }
  }

  protected void addDisposable(Disposable disposable) {
    Preconditions.checkNotNull(disposable);
    Preconditions.checkNotNull(disposables);
    disposables.add(disposable);
  }
}

Итак, execute(..) возьмите DisposableObserver, а затем есть dispose() метод, который вызывается для удаления этого наблюдаемого.

В моем случае наблюдаемое может поступать из WebApi с использованием модернизации или кеширования с использованием Realm.

Теперь в презентаторе onDestroy () я вызвал interactor.dispose(), например:

 @Override public void destroy() {
        super.destroy();
        myInteractor.dispose();
    }

который вызывается после этого из представления:

    @Override public void onDestroy() {
    super.onDestroy();
    if (getPresenter() != null) {
      getPresenter().destroy();
    }
  }

Я полностью понимаю архитектуру, а также понимаю удаление неуправляемых ресурсов сети или базы данных, но мне нужно полностью понимать, действительно ли в этом случае удаление наблюдаемых имеет значение, поскольку я думал, что Retrofit или Realm автоматически управляют закрытием соединений и удалением их ресурсов.

Я думаю, что это не связано с удалением области или модернизацией ресурсов, но это может быть связано с отказом от подписки на наблюдаемое само, когда я проверил документацию и обнаружил:

Класс DisposableObserver: абстрактный наблюдатель, который позволяет асинхронную отмену путем реализации Disposable. Все предварительно реализованные методы final являются потокобезопасными.

Используйте метод public dispose (), чтобы удалить последовательность из реализации onNext.

Но я все еще не понимаю преимуществ его использования. Это для отказа от подписки на наблюдаемое при уничтожении представления, чтобы оно перешло с onNext() на onComplete() и закрыло подписку на эмиттере?


android clean-architecture observable dispose rx-java
person Marzouk    schedule 03.11.2017    source источник

Ответы (2)


arrow_upward
15
arrow_downward

Причина использования метода удаления заключается в том, что после того, как система инициирует представление (activity или fragment), подписка запускается, а затем вы решили вернуться или инициировать другое представление, в то время как старая подписка все еще выполняется и не завершила ее работа. Это означает, что он все еще находится в памяти, что вызовет memory leak. Поэтому вам нужно вызвать метод dispose для отказа от подписки.

person abozaid    schedule 04.11.2017

arrow_upward
2
arrow_downward

Добавляя больше к ответу @abozaid, когда старая подписка все еще On, а тем временем наш пользователь переключается на другой вид (activity или fragment) или закрывает более старый вид (или сам application), он определенно будет leak памяти.

Но если бы мы наблюдали наблюдаемую для обновления пользовательского интерфейса с AndroidSchedulers.mainThread() планировщиком, тогда наш код вылетел бы, потому что во время обновления пользовательского интерфейса view и context ушли бы (или уничтожили).

myObservable.observeOn(AndroidSchedulers.mainThread()) // like this

Я могу добавить еще один момент: даже если мы обработаем сбой, добавив меры предосторожности в код, subscription не используется hamper performance на каком-то этапе.

person Kushal    schedule 02.01.2020