Какие знаешь локальные контексты?

Локальные контексты в Android

В Android под "локальными контекстами" (local contexts) обычно подразумевают объекты Context, обладающие ограниченной по сравнению с Application Context областью видимости и жизненным циклом. Понимание их различий критически важно для предотвращения утечек памяти, корректной работы с ресурсами и архитектурой приложения.

Основные типы Context в Android

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

• Доступа к ресурсам приложения (строки, цвета, размеры).
• Регистрации широковещательных приёмников (BroadcastReceiver) для системных событий.
• Запуска долгоживущих фоновых задач или работы с Singleton, где не требуется UI.

Activity Context — локальный контекст, привязанный к жизненному циклу Activity. Он наследует от Application Context, но содержит дополнительную информацию о текущем UI (тема, окно). Его следует использовать для:

• Запуска новой Activity (startActivity()).
• Создания View (например, через LayoutInflater).
• Отображения диалогов (Dialog, AlertDialog, BottomSheetDialog).
• Работы с FragmentManager (getSupportFragmentManager()).

Service Context, BroadcastReceiver Context — также являются локальными контекстами, привязанными к жизненному циклу соответствующего компонента.

Ключевые различия и практическое применение

Главное правило: используйте контекст, жизненный цикл которого соответствует требуемой операции. Неправильный выбор приводит к утечкам памяти или крашам.

• Утечка памяти: Если вы держите ссылку на Activity Context в объекте, который переживает Activity (например, в Singleton или в долгоживущем фоновом потоке), это предотвратит сборку мусора для всей Activity и её представлений. Вместо этого передавайте Application Context.

• Тема и стили: Activity Context знает о текущей теме, установленной для этого окна. Application Context использует тему по умолчанию. Создание View через Application Context может игнорировать ваши кастомные темы.

// ❌ ПЛОХО: Использование Activity Context в Singleton (потенциальная утечка)
class ImageLoader private constructor(context: Context) {
    companion object {
        private var instance: ImageLoader? = null
        fun getInstance(context: Context): ImageLoader {
            return instance ?: synchronized(this) {
                instance ?: ImageLoader(context.applicationContext).also { // ✅ Используем Application Context!
                    instance = it
                }
            }
        }
    }
    private val appContext = context.applicationContext
    // ... загрузка изображения с использованием appContext
}

// ✅ ХОРОШО: Создание View требует Activity Context (или ContextThemeWrapper)
class MyActivity : AppCompatActivity() {
    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        // Это корректно, т.к. View привязана к жизненному циклу Activity
        val customView = MyCustomView(this)

        // ❌ Если бы мы здесь использовали applicationContext, View могла бы не получить нужную тему
        // val wrongView = MyCustomView(applicationContext)
    }
}

// ✅ ХОРОШО: Запуск Activity требует Activity Context (или Context, обернутого в Activity)
fun navigateToDetails(activityContext: Context) {
    val intent = Intent(activityContext, DetailsActivity::class.java)
    activityContext.startActivity(intent) // Требуется Context с возможностью startActivity()
}

Специальные случаи и современные подходы (Android Jetpack)

1. ContextThemeWrapper: Позволяет создать новый контекст на основе существующего, но с применением другой темы. Полезен при кастомном создании View вне Activity.

2. ViewModel и LiveData: Архитектурные компоненты специально разработаны для хранения данных, связанных с UI, но не зависящих от Context. ViewModel переживает изменения конфигурации Activity, что устраняет многие проблемы с контекстом.

3. Dependency Injection (Dagger/Hilt): Современные практики рекомендуют внедрять Application Context через граф зависимостей, а Activity Context — только в скоупе, связанном с жизненным циклом Activity. Hilt предоставляет аннотации @ApplicationContext и @ActivityContext для этого.

// Пример с Hilt
@Module
@InstallIn(ActivityComponent::class)
object ActivityModule {
    @Provides
    fun provideActivityContext(@ActivityContext context: Context): Context = context
}

class MyAdapter @Inject constructor(
    @ActivityContext private val context: Context // Будет внедрен правильный контекст
) : RecyclerView.Adapter<MyAdapter.ViewHolder>()

Итог

Понимание локальных контекстов сводится к осознанию их области жизни (scope). Всегда задавайтесь вопросом: "Будет ли объект, которому я передаю этот Context, существовать дольше, чем компонент (Activity, Service), с которым этот Context связан?". Если ответ "да" — почти всегда нужен Application Context. Для операций, напрямую связанных с UI и его отображением, необходим Activity Context. Следование этому принципу в сочетании с использованием современных архитектурных компонентов — залог стабильного и эффективного Android-приложения.