Работали ли вы с RxJava и потоками

Что проверяют

Понимаете ли вы разницу между «переключить поток» и реактивной моделью, умеете ли управлять подписками и их жизненным циклом, и знаете ли, какое место Rx занимает сегодня, когда новые экраны пишут на корутинах.

Как отвечать

Разложите по слоям:

• типы источников: Observable и Flowable с поддержкой backpressure, Single для одного значения, Maybe, Completable для операций без результата;
• потоки: subscribeOn задаёт поток подписки и работает только самый верхний в цепочке, observeOn переключает всё, что ниже, и может встречаться несколько раз;
• шедулеры: io() растущий пул под сеть и диск, computation() ограничен числом ядер и не терпит блокирующих вызовов, AndroidSchedulers.mainThread() для обновления интерфейса;
• подписки: складывать в CompositeDisposable и очищать в onCleared у ViewModel или при уничтожении вьюхи;
• ошибки: onError терминален, после него поток мёртв, поэтому retryWhen и onErrorReturn, а не молчаливое проглатывание.

disposables.add(api.loadFeed()
    .subscribeOn(Schedulers.io())
    .observeOn(AndroidSchedulers.mainThread())
    .subscribe(this::render, this::showError));

Уместно добавить, где вы использовали Flow и корутины и почему на конкретном проекте остался Rx.

Где спотыкаются

Ставят subscribeOn дважды и ждут, что сработает последний. Влияет только первый сверху, остальные бесполезны, а сеть при этом продолжает уходить не туда, куда ожидал автор.

Второе: утечки. Подписка держит ссылку на экран, Disposable никто не очистил, результат приходит после поворота устройства и падает на отсоединённой вьюхе. Это самая частая причина неожиданных крашей в таком коде.

Третье: называют AsyncTask актуальным способом уйти в фон. Он давно объявлен устаревшим и в новом коде не пишется, так что упоминание его как рабочего инструмента показывает, что практика остановилась. Сегодня ждут корутины и Flow, а Rx как наследие, которое надо уметь читать и поддерживать.