Почему нельзя выполнять фоновую работу в Application

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

Почему так делать — пиздец как не рекомендуется? Давай по пунктам, а то ты, чувак, не поймёшь.

Во-первых, блокировка UI-потока. Представь: ты в onCreate() своего Application запилил какую-нибудь синхронную хуйню — типа синхронного сетевого запроса или парсинга огромного JSON'а с диска. Пока эта операция не завершится, твоё приложение нихуя не запустится. Система посмотрит на это, подождёт пару секунд, и БАЦ — выкинет тебе ANR (Application Not Responding). И пользователь сразу увидит диалог "Приложение не отвечает". Стартовая заставка даже не успеет показаться. Красота? Нихуя не красота. Это как заводить машину, а она полчаса думает, прежде чем завестись. Волнение ебать, а терпения ноль.

Во-вторых, неопределённый контекст. Класс Application живёт долго, дольше любой активити. Но это не значит, что когда у тебя срабатывает его onCreate(), всё остальное в приложении уже готово и проинициализировано. Может, твоя фоновая задача захочет обратиться к какому-нибудь менеджеру, который ещё не создан, или к базе данных, которая ещё не открыта. Получится обращение в никуда, и приложение накроется медным тазом с крашем. Сам от себя охуеешь, когда будешь дебажить.

В-третьих, жрёт ресурсы. Ты стартуешь какую-то тяжелую операцию при запуске приложения. Даже если ты её запустил в отдельном потоке (что уже лучше, чем синхронно), она всё равно будет кушать CPU, память, может, сеть. А пользователь в это время ждёт, когда откроется его главный экран. Всё это тормозит старт, делает его вялым. Пользователь думает: "Что за говно-приложение такое долго грузится?" И удаляет его. И будет прав, пидарас шерстяной.

Вот смотри, как выглядит эта пиздопроебибна:

// Плохо, не делай так, а то я тебе впендюрю:
class MyApp : Application() {
    override fun onCreate() {
        super.onCreate()
        Thread { /* Тяжелая работа: качаю 500 картинок, парсю весь интернет */ }.start() // Риск утечки памяти, ANR и просто позор
    }
}

Видишь? Запустил поток и забыл. А он там может утечь, может работать, когда приложение уже не нужно. Хуй с горы, а не архитектура.

Так что же делать, спросишь ты? А делать надо по-взрослому.

• WorkManager — это твой бро для отложенных, но гарантированно выполняемых задач. Нужно синхронизировать данные раз в день? Закинь в WorkManager. Он сам разберётся, когда лучше это сделать, даже если пользователь перезагрузит телефон. Удобно, надёжно. Доверия к нему — не ноль ебать.
• Корутины (Coroutine) или RxJava — для фоновых операций, которые нужны прямо сейчас, но не должны блокировать интерфейс. Но и тут не надо быть манда с ушами! Запускай их в правильной области видимости — используй LifecycleScope в активити или фрагменте, или viewModelScope во ViewModel. Тогда, если пользователь закроет экран, твоя фоновая задача тоже аккуратно отменится, а не будет впустую жрать батарею. Это называется "ответственная разработка", а не "запустил и похуй".

Короче, суть в чём: класс Application — это не мусорка, куда можно скидывать любую асинхронную хуйню. Это фундамент. И фундамент должен закладываться быстро и надёжно. Всю остальную работу — строй на уже готовом фундаменте, используя правильные инструменты. Понял да? Э, бошка, думай!