Какой опыт с реактивным программированием (Combine, RxSwift)
Что проверяют
На Android-позиции вопрос про Combine и RxSwift всплывает, когда в команде есть iOS-часть или KMP, либо интервьюер проверяет само реактивное мышление, а не библиотеку. Ему важно, понимаете ли вы потоки, подписки и отмену и сможете ли переложить опыт с RxJava или Kotlin Flow. Следом почти всегда спрашивают про горячие и холодные потоки и утечки подписок.
Как отвечать
Честно обозначьте свою базу и проведите соответствие:
- источник:
FlowиObservableв RxJava, в iOS этоPublisherв Combine иObservableв RxSwift; - холодные и горячие: обычный
Flowхолодный и запускается на каждыйcollect,StateFlowиSharedFlowгорячие. Аналоги:CurrentValueSubjectиPassthroughSubjectв Combine,BehaviorSubjectиPublishSubjectв RxSwift; - отмена: в корутинах её даёт скоуп (
viewModelScope,lifecycleScope), в RxJavaCompositeDisposable, в CombineAnyCancellable, в RxSwiftDisposeBag; - потоки выполнения:
flowOnпротивsubscribeOnиobserveOnв Rx иreceive(on:)в Combine; - обратное давление: у
Flowоно встроено через приостановку, в RxJava для него естьFlowable, в Combine спрос задаёт подписчик, а RxSwift его не поддерживает.
Пример из опыта стройте на реальной задаче: поиск с debounce, distinctUntilChanged и flatMapLatest, объединение источников через combine, состояние экрана в StateFlow и сбор в UI через repeatOnLifecycle или collectAsStateWithLifecycle в Compose. Если с Combine и RxSwift вы не работали, прямо скажите об этом: переносимые знания ценнее выдуманного опыта.
Где спотыкаются
Говорят, что операторы «ускоряют обработку данных». Реактивный подход про композицию асинхронных событий и управление их жизненным циклом, а не про скорость: цепочка операторов даже добавляет накладные расходы.
Забывают про отмену. Подписка в GlobalScope или без dispose держит ссылку на экран и продолжает работать после его закрытия.
Шлют одноразовые события навигации через SharedFlow или Subject, не понимая семантики replay, и теряют их, пока нет подписчика, или получают дважды после поворота экрана.