Вернуться в видеотекуAndroid Interview Preparation #4 - Async work interview
Запись четвёртого воркшопа Android Academy Global по подготовке к техническому интервью об асинхронной работе в Android. Два mock-интервью охватывают RxJava, Kotlin Coroutines, Flow, сетевые кейсы и разбор хода рассуждений кандидатов.
- Направление
- Mobile
- Формат
- Мок-собеседование
- Компания
- LLuminary
- Длительность
- 1 ч 59 мин
Коротко о видео
Это образовательный mock-интервью для Android-разработчиков о асинхронной работе. В первой технической секции Олег отвечает на вопросы по RxJava: типы Retrofit-ответов, polling, обработка ошибок, клики, операторы merge и switchMap, кэш и сетевые запросы. Во второй секции Александра разбирает Kotlin Coroutines и Flow: диспетчеры, CPU- и IO-bound задачи, structured concurrency, отмену, SupervisorJob, жизненный цикл Fragment и выбор между RxJava и Coroutines.
Затронутые темы
Что взять на заметку
- На интервью полезно разделять асинхронность и параллелизм: асинхронная операция не обязана выполняться одновременно с другой и может работать в одном потоке.
- Для периодического polling нужно заранее оценить пиковую нагрузку, допустимый RPS и стоимость запросов; push-уведомление может быть сигналом выполнить обновление вместо постоянного опроса.
- Если приложению важен результат POST-запроса или ошибка сервера, контракт сетевого слоя должен это явно возвращать; в обсуждённом кейсе участники предпочитают получить ответ через Single, а не скрывать его за Completable.
- Задержку для защиты от двойных нажатий не следует выбирать «потому что всегда так делали»: её стоит обосновать UX-сценарием и при необходимости подобрать эмпирически.
- Для цепочки «клик → преобразование данных → сетевой запрос» switchMap применяют, когда новый ввод должен отменять предыдущий незавершённый запрос.
- Coroutines не ускоряют CPU-bound вычисление на одноядерном устройстве сами по себе; для него есть предел по числу ядер, тогда как IO-bound задачи выигрывают от неблокирующего ожидания.
- Переход с RxJava на Coroutines и Flow участники советуют выполнять постепенно, прежде всего в новых модулях или новой функциональности, а не переписывать большой legacy-проект целиком.