在 Android 开发的漫长岁月里依赖注入框架一直是个让人又爱又恨的话题。从早期的 Dagger 那令人头秃的编译期魔法，到现在轻量级 Koin 的流行，我们一直在寻找那个“刚刚好”的平衡点。特别是当 Jetpack Compose 彻底改变了 UI 的写法后ViewModel 的获取方式也变得扑朔迷离起来。你有没有遇到过这种情况？明明注入了 ViewModel，结果一旋转屏幕数据丢了或者跳转个页面原本应该共享的状态变成了两个孤岛。

今天这篇实战手册，我不打算给你讲那些枯燥的理论定义，我们直接来聊聊在 Jetpack Compose + Koin 的环境下到底该怎么优雅、正确地写出 ViewModel。这里面的坑，我一个个dou替你踩过了现在把那些血泪经验成文，希望Neng帮你省下几个熬夜调试的夜晚。

一、前置准备：别让依赖拖了后腿

在开始写代码之前，得先把地基打好。Koin 虽然轻量，但在 Compose 环境下它需要一些特定的 库才Neng发挥Zui大威力。hen多时候报错找不到 `koinViewModel` 这个函数，往往不是因为逻辑写错了而是 Gradle 依赖没配全。

这里有一份我常用的依赖配置清单，建议直接复制到你的 `build.gradle` 里：

// Koin 核心库，这是基础
implementation "io.insert-koin:koin-android:3.4.0"
// 针对 Android ViewModel 的支持
implementation "io.insert-koin:koin-androidx-viewmodel:3.4.0"
// 重点来了：Compose 专用
，没有这个玩不转
implementation "io.insert-koin:koin-androidx-compose:3.4.0"
// Compose 生命周期相关
implementation "androidx.lifecycle:lifecycle-runtime-ktx:2.6.1"
implementation "androidx.lifecycle:lifecycle-viewmodel-compose:2.6.1"
// 导航组件，后面讲共享 VM 会用到
implementation "androidx.navigation:navigation-compose:2.6.0"

配好这些，接下来就是初始化 Koin。通常在 `Application` 里Zuo这件事Zui稳妥：

class MyApp : Application {
    override fun onCreate {
        super.onCreate
        startKoin {
            androidContext
            modules // 加载你的模块定义
        }
    }
}

二、基础注入：从简单的开始

我们先从Zui简单的场景入手：一个页面一个独立的 ViewModel。这种情况下我们不涉及复杂的共享逻辑，只要Neng拿到实例就行。

在 Koin 模块中定义 ViewModel 是第一步。注意kan这里的写法，我们使用 `viewModel` 关键字，而不是 `single` 或 `factory`，这保证了它Neng和 ViewModel 的生命周期机制正确绑定。

// 仓库层，通常设为单例
class SpeechRepository
// 简单的 ViewModel
class SpeechRecognitionViewModel(
    val repo: SpeechRepository
) : ViewModel {
    // 这里放你的业务逻辑...
}
val appModule = module {
    single { SpeechRepository }
    viewModel { SpeechRecognitionViewModel) }
}

到了 Compose 页面里怎么拿呢？千万别再用以前的 `by viewModel` 那种委托写法了在 Compose 里我们推荐直接调用函数：

@Composable
fun SpeechPage {
    // 这一行代码就Neng搞定，Koin 会自动处理生命周期
    val vm: SpeechRecognitionViewModel = koinViewModel
    // 接下来就Ke以愉快地使用 vm 了
    Text
}

这种写法非常直观，`koinViewModel` 会自动感知当前 Composable 的生命周期，确保 ViewModel 实例的正确创建和回收。

三、进阶玩法：带参数的 ViewModel

实际项目中，无参的 ViewModel 毕竟少数。比如我们跳转到详情页，需要传一个 `id` 过去，这时候 ViewModel 的构造函数里就得带上这个参数。这可是个高频考点，写不对直接崩溃。

修改 Koin 模块，支持动态参数传入。这里用到了 lambda 表达式解构：

class DetailViewModel(
    val id: Int,
    val repo: SpeechRepository,
    val savedStateHandle: SavedStateHandle // 这个后面细说
) : ViewModel {
    init {
        println
    }
}
val appModule = module {
    // ... 其他配置
    viewModel {  ->
        DetailViewModel(
            id = id,
            repo = get,
            savedStateHandle = get // Koin 甚至Neng自动注入 SavedStateHandle
        )
    }
}

在 Compose 调用处，我们需要通过 `parametersOf` 来传递参数：

@Composable
fun DetailPage {
    val vm: DetailViewModel = koinViewModel(
        parameters = { parametersOf }
    )
    Text
}

这里有个小细节，`SavedStateHandle` 也Ke以像上面那样直接在构造函数里声明 `get`，Koin hen聪明，它会自动把当前导航图里的 SavedStateHandle 塞给你，省去了手动创建的麻烦。

四、共享 ViewModel：那些让人抓狂的坑

这才是重头戏。hen多新手在 Compose 里Zui容易晕的地方就是：我想让两个页面共享同一个 ViewModel，结果发现它们各玩各的。或者geng惨，想共享结果变成了全局单例，Activity 销毁了还在。

在 Compose 导航中，共享 ViewModel 的核心在于 ViewModelStoreOwner 的选择。选对了 Owner，生命周期就对；选错了全是 Bug。

1. 全局共享

Ru果你希望整个 Activity 下所有页面dou共用同一个实例，Zui稳的方案其实是利用 CompositionLocal。虽然 Koin 也NengZuo，但直接在 Activity 层创建并通过 Local 传递，兼容性Zui好，不容易出空指针异常。

先定义一个 Local：

val LocalSpeechVM = compositionLocalOf {
    error
}

然后在 Activity 里提供它：

class MainActivity : ComponentActivity {
    // 这里用标准的 Jetpack ViewModel 获取方式，或者 Koin 的 activityViewModel
    private val sharedVm: SpeechRecognitionViewModel by viewModels
    override fun onCreate {
        super.onCreate
        setContent {
            // 通过 Provider 把 VM 注入到环境树中
            CompositionLocalProvider {
                AppNavHost // 整个导航图douNeng访问到
            }
        }
    }
}

Zui后在任意子页面取用：

@Composable
fun PageA {
    val vm = LocalSpeechVM.current // 拿到的是同一个实例
    Text
}
@Composable
fun PageB {
    val vm = LocalSpeechVM.current // 还是同一个实例
    Text
}

2. 导航图内共享

geng多的时候，我们不需要全局共享，只需要在某个导航流程内共享。比如“用户中心”模块，包含“个人资料”和“设置”两个页面它们需要共享 `UserViewModel`，但退出用户中心后这个 ViewModel 就该销毁。

这时候就要利用 NavBackStackEntry 作为 Owner。

先kan路由定义：

object Route {
    const val HOME = "home"
    const val SEARCH = "search"
    const val DETAIL = "detail/{id}"
    // 嵌套导航
    const val USER_GRAPH = "user_graph"
    const val USER_PROFILE = "user_profile"
    const val USER_SETTING = "user_setting"
}

在导航配置中，关键点在于 `navigation` 闭包里的 `backStackEntry`：

@Composable
fun AppNavHost) {
    NavHost(
        navController = navController,
        startDestination = Route.HOME
    ) {
        // 首页
        composable { HomePage }
        // 搜索页
        composable { SearchPage }
        // 详情页
        composable { backStack ->
            val id = backStack.arguments?.getInt ?: 0
            val vm: DetailViewModel = koinViewModel })
            DetailPage
        }
        // =============== 嵌套导航：用户模块 ===============
        navigation(
            startDestination = Route.USER_PROFILE,
            route = Route.USER_GRAPH
        ) {
            // 个人资料页
            composable { backStackEntry ->
                // 关键：把 backStackEntry 作为 Owner 传进去
                val userVm: UserViewModel = koinViewModel
                UserProfilePage
            }
            // 设置页
            composable { backStackEntry ->
                // 同样使用 backStackEntry，这样两个页面拿到的就是同一个 VM 实例
                val userVm: UserViewModel = koinViewModel
                UserSettingPage
            }
        }
    }
}

为了让你geng直观地理解，这里写两个简单的页面示例：

@Composable
fun HomePage {
    Column {
        Text
        Button }) {
            Text
        }
    }
}
@Composable
fun UserProfilePage {
    // 模拟修改数据
    Column {
        Text
        Button {
            Text
        }
    }
}
@Composable
fun UserSettingPage {
    Text
}

五、验证：如何确定真的共享了？

代码写完了心里总是不踏实？这hen正常。毕竟有时候你以为共享了其实 Koin 悄悄给你创建了两个新实例。

这里有个Zui笨但Zui有效的办法：打印 hashCode。Ru果两个页面的 hashCode 一致，那说明它们指向的是同一个内存对象，共享成功。

import android.util.Log
@Composable
fun UserProfilePage {
    Log.d}")
    // ... UI 代码
}
@Composable
fun UserSettingPage {
    Log.d}")
    // ... UI 代码
}

当你kan到 Logcat 里输出类似这样的日志时就Ke以放心了：

VM_DEBUG: Profile VM hash = 12345678
VM_DEBUG: Setting VM hash = 12345678

六、避坑指南：那些年我们踩过的雷

Zui后我想专门留个章节聊聊那些让人崩溃的错误。hen多时候，代码逻辑没错，只是 API 用错了一个参数，或者版本没对上。

1. 参数名写错导致崩溃

Ru果你在 Koin 3.x 版本里还用 2.x 的写法，比如这样：

// 报错：No parameter with name 'owner'
koinViewModel

这绝对会崩。Koin 3.x 的参数名改了必须写成 viewModelStoreOwner。这种低级错误我见过不止一次升级 SDK 的时候一定要仔细kan Changelog。

2. 强转类型导致的异常

有些教程可Neng会教你这样写“骚操作”：

// 崩溃代码
koinViewModel

千万别这么干！Qualifier 是 Koin 用来命名区分不同 Bean 的标识符，跟 ViewModelStoreOwner 完全是两码事。这种强转在运行时肯定会抛出类型转换异常，除了让你kan到 Crash 界面外没有任何用处。

3. 参数透传地狱

在 Compose 早期，hen多人习惯把 ViewModel 当成普通参数一样，从父页面一层层传给子页面。千万别这么Zuo！这叫“Prop Drilling”，会让代码耦合度极高，维护起来想死。一旦中间加了一层 UI，你就得把所有经过的组件dou改一遍。

正确的姿势永远是：谁用谁取。页面内部直接调用 koinViewModel，或者通过 CompositionLocal 获取，保持组件的纯净。

4. LocalViewModelStoreOwner 为 null

比如在 Dialog 或者某些脱离了 Navigation 树的 Composable 里LocalViewModelStoreOwner.current 可Neng会是 null。直接使用会报空指针。geng安全的写法是加上判空，或者确保你的 Composable 是在 NavHost 的作用域内被调用的。

Koin 和 Compose 的结合，其实是一种非常清爽的开发体验。没有了繁琐的注解处理器，代码读起来也geng直观。虽然 ViewModel 的作用域管理在初期容易让人晕头转向，但只要搞懂了 ViewModelStoreOwner 这个核心概念，一切dou会变得豁然开朗。

希望这篇实战手册Neng帮你理清思路。记住遇到问题别慌，打几个 Log kankan hashCode，或者检查一下依赖注入的 Owner 到底是谁。代码这东西，只要逻辑通了怎么写dou顺。祝大家在 Compose 的世界里写得开心，崩得少！

---