С какими технологиями многопоточности работали и что бы выбрали сейчас

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

Не столько список названий, сколько понимание, чем вы платите за фоновую работу: где она живёт, кто её отменяет и что в это время происходит с главным потоком. Вторая часть вопроса проверяет, следите ли вы за тем, что в платформе объявлено устаревшим.

Как отвечать

Разложите по поколениям и объясните, почему каждое сменилось следующим.

• AsyncTask и загрузчики: объявлены устаревшими, легко утекают вместе с контекстом и плохо переживают пересоздание экрана;
• Handler, Looper, HandlerThread: работают до сих пор, но всё делается руками;
• Executors и пулы потоков: разумный контроль числа потоков, но отмена и доставка результата на главный поток остаются на вас;
• RxJava: удобная композиция потоков событий ценой высокого порога входа и дисциплины с подписками;
• корутины и Flow: приостанавливаемые задачи, структурная конкурентность, отмена вместе с областью видимости.

Сейчас разумный выбор это корутины: работа запускается в области экрана или модели, состояние отдаётся через StateFlow, вычисления идут на Dispatchers.Default, ввод-вывод на Dispatchers.IO. То, что обязано пережить закрытие приложения, уходит в WorkManager.

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

Называют корутину лёгким потоком. Это приостанавливаемая задача поверх пула: блокирующий вызов внутри неё занимает поток целиком, а на главном диспетчере просто вешает интерфейс, никакой магии тут нет.

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

Третье: считают отмену мгновенной и бесплатной. Она кооперативная: цикл, который не проверяет активность и не зовёт приостанавливающих функций, доработает до конца. А задача, запущенная в глобальной области, не отменится вообще.