ViewModel 是 Jetpack 中关键的一个库，它与 Lifecycle、LiveData 建立了 MAD 的三大基础组件。不过，在 ViewModel 之前，Activity 负责处理所有内容。这使得其变得极为庞大，而且需要负责由于其混乱的生命周期带来的一系列问题。ViewModel 在推出之后就以摧枯拉朽之势席卷了整个 Android 开发界。

在 ViewModel 之前

在 ViewModel 出现之前。Android 开发中 Activity 既要管 UI 显示，又要管数据获取和处理。在这时一个典型的登录页 Activity 大概率会是这个样子：

class LoginActivity : Activity {
private lateinit var etUsername: EditText
private lateinit var etPassword: EditText
private lateinit var progressBar: ProgressBar
override fun onCreate {
super.onCreate
setContentView
etUsername = findViewById
etPassword = findViewById
progressBar = findViewById
}
fun onLoginClick {
val username = etUsername.text.toString
val password = etPassword.text.toString
progressBar.visibility = View.VISIBLE
// 直接在 Activity 里发起网络请求
Thread {
val success = loginApi.login
runOnUiThread {
progressBar.visibility = View.GONE
if {
startActivity)
finish
} else {
Toast.makeText.show
}
}
}.start
}
}

这样的 Activity 在早期是非常常见的，获取 UI 组件、调用接口、设置回调结果等等。不过，看起来能跑，但是这里有三个致命问题：

从问题一来看，只要配置发生变更，数据将全部丢失

在 Android 程序中。配置变更会销毁并重建 Activity，而这里要格外注意，重建的 Activity 是一个全新的实例，与之前的没有半点关系。

使用者竖屏输入完账号密码，网络请求正在飞行中，转了一下屏幕——Activity 销毁重建。那个网络请求的回调还持有旧 Activity 的引用，新 Activity 完全不知道有这个请求在跑。

更常见的情况的观点是。加载了一个列表数据，转屏后重新加载一遍。说起来，使用者流量白花了体验也差。

面对这个痛点，早期开发者只能通过 onSaveInstanceState 与 onRestoreInstanceState 手动保存恢复状态——代码冗余且易出错。其实，

问题二的观点是。异步回调持有已销毁的 Activity

这也是配置变更导致的问题。例如上面例子中的网络请求，如果 Activity 发生重建，这段代码就会出现内存泄漏或崩溃：

// Activity 已经被销毁。但回调仍在持有 this
Thread {
val result = api.fetchData
runOnUiThread {
// Activity 可能已经 finish
textView.text = result.data // crash 或内存泄漏
}
}.start

出现非必现的运行时异常。为了解决这个痛点，开发者只能在每个回调里手动检查 isFinishing/isDestroyed——代码遍布各处、维护成本高。不过，

说到问题三。Activity 膨胀到难以维护

上述两个痛点都有办法“绕开”，但代价是让 Activity 快速膨胀。业务稍微复杂一点，就会出现几千行代码混杂在一起：

• 难以测试：所有逻辑都绑定在 Android 框架对象上。其实，
• 难以维护：改动功能需要在上千行代码里翻找。
• 难以复用：数据和 UI 耦合紧密，换页面几乎要重写。

Google 的解法

Google 明白混乱的 Activity 生命周期是根本设计缺陷，只能在程序上添加“木板”。于是诞生了 ViewModel——一个专门用于把数据与 UI 分离、让数据跨配置变更依然存活的中间层。

• 配置变更导致的数据丢失：ViewModel 生命周期比 Activity 长，不会被销毁。
• 异步回调引用已死 Activity：Activity 重建后重新观察同一个 ViewModel，不再持有旧实例。
• Activity 膨胀不可测试：业务逻辑搬到不依赖 Android 框架的 ViewModel，可直接编写单元测试。

为了观察数据。ViewModel 通常配合 LiveData、Flow 等可观察容器使用，并依赖 Lifecycle 库来感知 UI 生命周期。若想了解这两个库，可参考以下文章：

为什么叫做 ViewModel

"ViewModel" 并非 Google 发明。而是来源于微软提出的 MVVM模式。Google 把已有概念搬到 Android 上，实现了“为 View 服务的 Model”。这里的 Model 指的是 UI 所需状态，而不是传统意义上的数据库层模型。

对 ViewModel 的片面认知往往停留在“只是装数据”，它还承担：

ViewModel 的原则

If a ViewModel holds an Activity reference,old Activity cannot be GC after rotation,causing crashes or memory leaks.

The communication 娱乐ween View and ViewModel follows observer pattern—ViewModels expose data streams,and Views actively observe m.

引入依赖

lifecycle = "..."
activity = "..."
androidx-lifecycle-viewmodel-ktx = { group = "androidx.lifecycle",name = "lifecycle-viewmodel-ktx",version.ref = "lifecycle" }
androidx-lifecycle-viewmodel-savedstate = { group = "androidx.lifecycle",name = "lifecycle-viewmodel-savedstate",version.ref = "lifecycle" }
androidx-activity-ktx = { group = "androidx.activity",name = "activity-ktx"。version.ref = "activity" } # 需要 ComponentActivity

dependencies {
implementation
implementation
implementation
}

基本用法

创建 ViewModel

class FirstViewModel : ViewModel {
val textLiveData = MutableLiveData
override fun onCleared {
super.onCleared
// 当整个页面真正退出时调用
}
}

在 Activity 中获取

class MainActivity : ComponentActivity {
private lateinit var viewModel: FirstViewModel
private lateinit var textView: TextView
override fun onCreate {
super.onCreate
setContentView
textView = findViewById
viewModel = ViewModelProvider
viewModel.textLiveData.observe { text ->
textView.text = text
}
}
}

The ViewModelProvider` call ties lifecycle of provider to current ComponentActivity,ensuring same instance survives configuration changes.

带构造参数的 ViewModel

class SecondViewModel(
private val initC: Int,val initS: String,private val savedStateHandle: SavedStateHandle
) : ViewModel {
var counter: Int
get = savedStateHandle?: initC
set { savedStateHandle = value }
}

viewModel = ViewModelProvider(
this,viewModelFactory {
initializer {
val handle = createSavedStateHandle
SecondViewModel
}
})

带 Application 的 ViewMdoel

class MyAndroidViewMdoel : AndroidViewMdoel {
fun doSomething {
val appContext = getApplication
// 使用 Application Context 完成操作...
}
}

使用 方法 #viewModels 创建

class MainActivity : ComponentActivity {
private val firstVm: FirstViewMdoel by viewModels
private val secondVm: SecondViemodel by viewModels {
viewMdoelFactory {
initializer {
val handle = createSavedStateHandle
SecondViemodel
}
}
}
override fun onCreate {
super.onCreate
setContentVew
// UI 与 VM 数据绑定同上...
}
}

• b y viewModels: 用于无参构造函数；内部使用默认 Factory。
• b y viewModels { factory }: 用于自定义构造函数；传入自定义 Factory 即可。

ViewMdoel 的注意事项 & 常见坑点

• 从生命周期来看，从创建到对应 ComponentActi vity 真正退出才会调用 onCleared；期间即使多次旋转或 Fragment 重建，也始终拿到同一实例。
• 同类型只能拥有唯一实例；如果需要多个，请自行创建不同子类或使用不同 key。
• 跨 Fragment 数据共享：使用 requireActi vity作为 owner，即可通过 activityV iewModels获得同一实例。

// Fragment A
val sharedVm : SharedV iewMo del by activityV iewMo dels
// Fragment B
val sharedVm : SharedV i ewMo del by activityV i ewMo dels
// 两者拿到的是同一个实例 


activityV i ewMo dels 与 /v i ewMo dels/c odo e> 类似，只是 owner 换成了所在 Fragment 所属的父 activity。

严禁持有任何 UI 对象引用，否则会导致内存泄漏或因旧对象仍被持 有而产生 Crash。



关键痛点回顾：
当你仍然把业务写进  时会遭遇：



配置变化导致状态丢失 → 必须手动保存/恢复 → 易出错 

异步任务引用已销毁页面 → Crash / 内存泄漏 → 每个回调都要写防御性检查 

代码膨胀不可测 → 单元测试几乎不可能 → 项目维护成本爆炸 


采用  后这些痛点全部消失：状态自动保留、回调安全、业务迁移至纯 Kotlin 类即可轻松编写单元测试。怎么说呢，

---