Какие знаешь причины, по которым сборщик мусора может не очистить контекст, если он сохранен в Application?

Причины утечки контекста при хранении в Application-классе

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

1. Статические ссылки на контекст

Самая распространенная проблема — хранение контекста в статических полях. Хотя Application-класс существует весь жизненный цикл приложения, статические ссылки на его контекст могут передаваться другим объектам, создавая циклические зависимости.

// Проблемный код
class AppSingleton {
    companion object {
        lateinit var appContext: Context // Статическая ссылка
    }
}

// Где-то в другом месте
class LeakyManager {
    private val context = AppSingleton.appContext // Теперь есть ссылка
    
    fun registerListener() {
        SomeSystemService.addListener(this) // Система теперь держит ссылку на context
    }
}

2. Регистрация системных колбэков без отписки

Если компоненты регистрируют слушатели системных событий, передавая контекст, и не отписываются вовремя, система продолжает держать ссылку.

public class SensorManager {
    public void registerListener(SensorListener listener, Sensor sensor, int rate) {
        // Система сохраняет ссылку на listener
        // который может содержать ссылку на context
    }
}

3. Ссылки через View и Resources

Контекст может удерживаться через иерархию View или Resources, особенно если есть утечки в активностях или фрагментах, которые хранят ссылки на Application Context.

4. ThreadLocal переменные

Если потоки используют ThreadLocal для хранения контекста и эти потоки не завершаются, контекст остается в памяти.

class ThreadLocalLeak {
    companion object {
        private val threadLocalContext = ThreadLocal<Context>()
        
        fun setContext(context: Context) {
            threadLocalContext.set(context) // Контекст привязан к потоку
        }
    }
}

5. Использование неявных ссылок

Внутренние механизмы Android могут создавать неявные ссылки:

• Handler с сообщениями, содержащими ссылки на контекст
• Анонимные классы, захватывающие контекст
• Внутренние классы с сильными ссылками на внешний класс

6. Пуллы и кэши

Некоторые библиотеки и системные компоненты используют пуллы объектов или кэши, которые могут хранить ссылки на контекст:

object ImageLoader {
    private val cache = LruCache<String, Bitmap>(MAX_SIZE)
    
    fun load(context: Context, url: String) {
        // context может быть захвачен в колбэках
        loadTask = LoadTask(context).execute(url)
    }
}

7. Системные сервисы и менеджеры

Когда вы получаете системные сервисы через context.getSystemService(), некоторые реализации могут сохранять ссылку на переданный контекст для своих нужд.

8. LiveData и Lifecycle компоненты

Неправильное использование Architecture Components:

class ProblematicViewModel(appContext: Context) : ViewModel() {
    private val context = appContext // Утечка!
    
    val liveData = MutableLiveData<String>().apply {
        // LiveData может пережить ViewModel при наличии активных observers
    }
}

9. Dagger/Hilt и DI-фреймворки

Неправильная область видимости (scope) в dependency injection:

@Module
@InstallIn(SingletonComponent::class)
object AppModule {
    @Provides
    @Singleton
    fun provideContext(application: Application): Context = application // Может создавать проблемы в многомодульном применении **Application Context** — его следует использовать только для долгоживущих операций, не привязанных к UI. Для работы с UI всегда нужен **Activity Context**.

## Рекомендации по предотвращению утечек:

- **Используйте WeakReference** для хранения контекста в синглтонах
- **Всегда отписывайтесь** от слушателей и ресиверов
- **Избегайте нестатических внутренних классов**
- **Используйте ViewModel** для хранения данных, связанных с UI
- **Проверяйте код с помощью LeakCanary**
- **Анализируйте память** через Android Profiler
- **Используйте Application Context** только когда действительно нужно

```kotlin

// Безопасное хранение контекста class SafeContextHolder { companion object { private var weakAppContext: WeakReference<Context>? = null

    fun initialize(context: Context) {
        weakAppContext = WeakReference(context.applicationContext)
    }
    
    fun getContext(): Context? = weakAppContext?.get()
}

}

Помните: даже Application-класс может быть пересоздан в некоторых сценариях (изменение языка, ночной режим), поэтому слепое хранение контекста без учета жизненного цикла чревато не только утечками памяти, но и некорректным поведением приложения.