Что произойдёт, если создать экземпляр ViewModel напрямую через конструктор

Краткий ответ

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

Подробное объяснение

Как ViewModel должна создаваться правильно

ViewModel предназначена для создания через ViewModelProvider или by viewModels() делегат в Kotlin:

// Правильный способ создания ViewModel
class MyActivity : AppCompatActivity() {
    // Использование делегата
    private val viewModel: MyViewModel by viewModels()
    
    // Или через ViewModelProvider
    private val viewModel2: MyViewModel by lazy {
        ViewModelProvider(this).get(MyViewModel::class.java)
    }
}

Что происходит при прямом создании ViewModel

// НЕПРАВИЛЬНЫЙ способ - прямое создание через конструктор
class MyActivity : AppCompatActivity() {
    private val viewModel = MyViewModel() // Прямое создание
    
    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        // ViewModel создана как обычный объект
    }
}

Конкретные проблемы прямого создания

1. Потеря состояния при изменениях конфигурации

Когда происходит поворот экрана, активити уничтожается и создается заново. При правильном использовании ViewModel сохраняет свои данные. При прямом создании:

• Новая ViewModel создается заново
• Все данные теряются
• Происходит повторная инициализация

2. Отсутствие связи с жизненным циклом

ViewModel, созданная через ViewModelProvider, автоматически очищается, когда связанный с ней жизненный цикл (активити или фрагмент) завершается окончательно. При прямом создании:

• ViewModel не знает о жизненном цикле
• Может произойти утечка памяти
• Не вызывается метод onCleared()

3. Проблемы с зависимостями

При использовании ViewModelFactory для внедрения зависимостей:

// С ViewModelFactory зависимости внедряются правильно
class MyViewModelFactory(private val repository: Repository) : ViewModelProvider.Factory {
    override fun <T : ViewModel> create(modelClass: Class<T>): T {
        return MyViewModel(repository) as T
    }
}

// При прямом создании нужно самостоятельно управлять зависимостями
val viewModel = MyViewModel(repository) // Но это все равно неправильно

4. Нарушение принципов MVVM/MVI

Прямое создание ViewModel нарушает архитектурные паттерны, где ViewModel должна:

• Быть независимой от View
• Управляться системой жизненных циклов
• Иметь четко определенную область видимости

Технические детали реализации

Под капотом ViewModelProvider использует ViewModelStore для хранения ViewModel:

// Упрощенная схема работы ViewModelProvider
class ViewModelProvider(
    private val store: ViewModelStore,
    private val factory: Factory
) {
    fun <T : ViewModel> get(modelClass: Class<T>): T {
        var viewModel = store.get(key) // Пытаемся получить существующую
        
        if (viewModel == null) {
            viewModel = factory.create(modelClass) // Создаем новую через фабрику
            store.put(key, viewModel) // Сохраняем в хранилище
        }
        
        return viewModel
    }
}

При прямом создании ViewModel не попадает в этот ViewModelStore, поэтому система не может ее правильно управлять.

Когда может потребоваться прямое создание

В исключительных случаях прямое создание ViewModel может использоваться, но только для:

• Тестирования (юнит-тесты без Android-зависимостей)
• Вспомогательных классов, не требующих сохранения состояния
• Миграции со старого кода (как временное решение)

Практический пример проблемы

class CounterViewModel : ViewModel() {
    var count = 0
    
    fun increment() {
        count++
    }
}

class MainActivity : AppCompatActivity() {
    // ПРАВИЛЬНО - сохраняет состояние
    private val correctViewModel: CounterViewModel by viewModels()
    
    // НЕПРАВИЛЬНО - теряет состояние
    private val incorrectViewModel = CounterViewModel()
    
    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        
        // При повороте экрана:
        // correctViewModel.count сохранит значение
        // incorrectViewModel.count сбросится на 0
    }
}

Вывод

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

• Сохранение состояния при изменениях конфигурации
• Автоматическое управление жизненным циклом
• Правильную очистку ресурсов
• Возможность использования ViewModelFactory для внедрения зависимостей

Всегда используйте ViewModelProvider или делегаты by viewModels()/by activityViewModels() для создания ViewModel. Это обеспечит корректную работу с жизненным циклом и сохранение состояния, что является основными причинами использования ViewModel в Android-разработке.