Расскажи о самой критической ошибке, с которой столкнулся

Одна из самых критических ошибок: утечка контекста в статическом поле

Одной из самых серьезных и трудноотслеживаемых ошибок в моей практике была утечка контекста (Context leak) через статическое поле в Android приложении. Это приводило к постепенному росту потребления памяти, частым вылетам на устройствах с ограниченными ресурсами и, в конечном итоге, к OutOfMemoryError (OOM) в ключевых функциях приложения.

Контекст проблемы

В ранних версиях приложения, для упрощения доступа к глобальным данным и сервисам из различных частей кода, был создан класс-менеджер с статическими полями. В одном из таких полей хранился ApplicationContext.

// Пример проблемного кода (ранняя версия)
class AppManager {
    // Статическое поле, хранящее контекст - ПРОБЛЕМА!
    companion object {
        var appContext: Context? = null
    }

    fun initialize(context: Context) {
        appContext = context // Контекст присваивается статическому полю
    }

    // Другие методы, использующие appContext...
}

Инициализация происходила в Application.onCreate():

class MyApplication : Application() {
    override fun onCreate() {
        super.onCreate()
        AppManager.initialize(this) // Передаем контекст Application
    }
}

Почему это стало критической ошибкой?

1. Статическое поле живет в памяти постоянно: Статические поля принадлежат классу и существуют в памяти до тех пор, пока загружен сам класс (обычно до остановки процесса). Контекст, присвоенный этому полю, никогда не освобождался.
2. Неправильное использование контекста в других местах: Разные компоненты (Activity, Fragment, View) получали этот статический контекст и использовали его для создания объектов, которые сами должны были быть связаны с жизненным циклом этих компонентов. Например, в Fragment:

   class MyFragment : Fragment() {
       private val someService = SomeService(AppManager.appContext) // Сервис получает статический контекст
   
       override fun onViewCreated(view: View, savedInstanceState: Bundle?) {
           // Использование someService...
       }
   }
   

    Здесь `SomeService` мог держать внутренние ссылки на полученный контекст, и даже после уничтожения `Fragment` и его `View`, сервис и контекст продолжали жить в памяти.

1. Сборщик мусора не мог освободить память: Статическая ссылка на ApplicationContext создавала "корень" (root) в графе объектов, из-за которого все объекты, связанные с этим контекстом (например, SomeService, его внутренние View, Drawable и т.д.), не могли быть собраны GC, даже когда их родительские Activity/Fragment были уничтожены.

Симптомы и диагностика

• Профайлер памяти (Android Studio Profiler) показывал постоянный линейный рост heap памяти после каждого открытия/закрытия определенных экранов (Activity).
• После нескольких таких циклов приложение падало с java.lang.OutOfMemoryError.
• Анализ Heap Dump показал множество объектов View, Drawable, Bitmap, которые были созданы через статический контекст и принадлежали уничтоженным Activity.

Решение и исправление

1. Убрали статическое поле с контекстом: Полностью отказались от хранения Context в статике.
2. Перешли на dependency injection (DI) внедрение зависимостей: Ввели библиотеку Dagger Hilt (или можно использовать Koin) для правильного управления жизненным циклом зависимостей.

   // Внедрение контекста Application через Hilt
   @Module
   @InstallIn(SingletonComponent::class)
   object AppModule {
       @Provides
       fun provideApplicationContext(@ApplicationContext context: Context): Context {
           return context // Hilt сам управляет жизненным циклом этого контекста
       }
   }
   
   // Использование в сервисе
   class SomeService @Inject constructor(private val appContext: Context) {
       // ...
   }
   
   // Использование в Fragment
   class MyFragment : Fragment() {
       @Inject
       lateinit var someService: SomeService // Сервис инжектируется с правильным контекстом
   
       override fun onAttach(context: Context) {
           super.onAttach(context)
           // Внедрение зависимостей для Fragment
       }
   }
   

3. Для случаев, где нужен контекст текущей Activity, мы явно передавали context из Activity/Fragment (который всегда был актуальным и уничтожался вместе с компонентом), либо использовали view.context для операций, связанных с View.
4. Ввели строгие правила в код-ревью: Запрет на статические поля, хранящие любые объекты, связанные с Context или View.

Выводы и уроки

• Статические поля и контекст в Android — опасное сочетание. Контекст должен жить только столько, сколько живет компонент (Activity, Fragment), которому он принадлежит.
• ApplicationContext можно использовать "глобально", но его передача должна быть строго контролируемой, обычно через DI, где его жизненный циклом управляет система.
• Профилирование памяти — обязательная практика для сложных приложений. Регулярный запуск Memory Profiler и анализ Heap Dump помогают находить такие утечки на ранних стадиях.
• Архитектурные решения (DI, чистые MVVM/MVI) не только улучшают структуру кода, но и предотвращают целые классы ошибок, связанных с жизненным циклом и памятью.

Эта ошибка стала мощным уроком о том, что даже простые и казалось бы удобные решения (статический менеджер) могут иметь катастрофические последствия на мобильных устройствах с ограниченной памятью, и что управление жизненным циклом объектов — одна из самых важных задач Android разработчика.