ViewModel初始化链路追踪：ViewModelProvider、Factory、构造函数耗时

当屏幕切换出现明显“白屏”或“黑屏”时，问题往往不在布局渲染，而在于ViewModel创建链阻塞了主线程。本章将沿着 ViewModelProvider.get() → Factory.create() → ViewModel.构造函数 这条链路逐级排查，定位延迟的精确阶段。

现象识别

• 用户感知：导航至目标页面后，界面长时间显示空白或加载指示器（>200ms），随后才呈现完整 UI。
• 系统响应：系统连续发送多次 InputMissed 或 DroppedFrame 通知；严重时直接弹出 ANR 对话框。
• 堆栈特征：从 StrictMode 或 Trace 抓取的主线程堆栈中，频繁出现 ViewModelProvider.get()、ViewModelProvider.Factory.create() 或 YourViewModel.() 方法调用。

数据采集

我们需要通过 3 个埋点来精确测量链路中各阶段的耗时。以下代码展示了如何在 Factory 和 构造函数 中插入 Trace 分段标记：

// 自定义 Factory 中的埋点示例
class LoggingFactory(
    private val userRepository: UserRepository,
    private val ioDispatcher: CoroutineDispatcher = Dispatchers.IO
) : ViewModelProvider.Factory {

    @Suppress("UNCHECKED_CAST")
    override fun <T : ViewModel> create(modelClass: Class<T>): T {
        Trace.beginSection("Factory.create:${modelClass.simpleName}")
        val startTime = System.nanoTime()

        // 模拟真实创建逻辑
        val viewModel = when {
            modelClass.isAssignableFrom(UserViewModel::class.java) -> {
                UserViewModel(userRepository, ioDispatcher) as T
            }
            else -> throw IllegalArgumentException("Unknown class ${modelClass.name}")
        }

        val durationMs = (System.nanoTime() - startTime) / 1_000_000f
        Trace.endSection()

        // 通过 Logcat 输出耗时数据
        Log.d("ViewModelTrace", "[${modelClass.simpleName}] " +
                "Factory.create() took ${durationMs}ms")
        return viewModel
    }
}

// ViewModel 构造函数内的埋点示例
class UserViewModel(
    private val userRepository: UserRepository,
    private val ioDispatcher: CorollaryDispatcher
) : ViewModel() {

    init {
        Trace.beginSection("UserViewModel.init")
        val startTime = System.nanoTime()

        // 假设这里模拟了阻塞初始化
        // Thread.sleep(80) // 80ms 的阻塞调用

        val durationMs = (System.nanoTime() - startTime) / 1_000_000f
        Trace.endSection()
        Log.d("ViewModelTrace", "[UserViewModel] " +
                "Constructor/init block took ${durationMs}ms")
    }
}

采集指标清单：

原因定位

使用故障树分析法逐层下钻，快速定位阻塞根源。

判断规则：

1. 优先对比 Factory 与构造函数耗时： 若 Factory.create() 耗时显著高于构造函数（例如 Factory 耗时 200ms vs 构造函数 5ms），则问题主要集中在 Factory 内的业务逻辑。
2. 检查构造函数内的阻塞 API： 通过 StrictMode.getThreadPolicy() 或字节码查看是否存在 Thread.sleep()、CountDownLatch.await()、runBlocking 以及 BitmapFactory.decodeResource 等高频主线程调用。
3. 利用“排查表”快速定责： 结合下方流程表，对照采集到的 Trace 数据，直接锁定责任阶段。

修复动作

1. 针对 Factory.create() 阻塞：
   • 将 Factory 内的网络请求、数据库查询、文件读写等操作移至 Repository 层，并通过协程 async 启动，在 ViewModel 的 init 块中 await。
   • 若必须同步获取数据（如参数合并），使用 runBlocking 的替代方案：SavedStateHandle 或 AssistedInject 传递原始 ID，在 ViewModel 内异步加载。
2. 针对构造函数阻塞：
   • 移除所有 Thread.sleep()、LockSupport.park()、Object.wait() 等阻塞调用。
   • 将大型对象初始化（如 Bitmap、大型Array）延迟至 UI 显示之后，或使用 懒加载委托 lazy { } 包裹。
3. 针对 DI 异常：
   • 检查 Hilt/Dagger 模块作用域，避免将 @Singleton 作用域用于 ViewModel 独有的依赖；优先使用 @HiltViewModel 或 @ViewModelScoped。
   • 避免在 DI 工厂内进行复杂的对象图计算；遇到循环依赖错误时，使用 Provider<T> 或 Lazy<T> 进行惰性注入。

复测

完成修复后，重复“数据采集”步骤，对比以下指标：

确保使用 Macrobenchmark 或 手动冷启动测试 验证至少 5 次，取中位数作为最终结果。

预防