咨询UIApp.instance获取实例的可行性及生命周期调用风险

核心结论 #

按Code B的写法，在UIApp的onCreate()执行前调用UIApp.instance必然会抛出UninitializedPropertyAccessException，无法正常获取实例。

原因分析 #

1. Application生命周期顺序：Android应用启动时，Application的回调顺序是attachBaseContext() → onCreate()，而Code B中instance是在onCreate()里才完成赋值的。
2. Hilt初始化时机：@HiltAndroidApp注解会让Hilt在Application的attachBaseContext()阶段就开始创建SingletonComponent中的单例对象。此时你定义的provideUIApp()方法会被Hilt调用，尝试获取UIApp.instance，但这时候onCreate()还未执行，instance作为lateinit变量还未初始化，直接访问会触发未初始化异常。

可行的修复方案 #

方案1：提前instance赋值时机

把instance的赋值移到attachBaseContext()中，确保Hilt初始化前实例已就绪：

@HiltAndroidApp
class UIApp : Application() {
    companion object{
       @JvmStatic
       lateinit var instance: UIApp
    }

    override fun attachBaseContext(base: Context) {
        super.attachBaseContext(base)
        instance = this
    }

    override fun onCreate(){
        super.onCreate()
        // 其他初始化逻辑
    }
}

方案2：利用Hilt默认绑定，无需自定义单例

Hilt默认已经为Application和ApplicationContext提供了绑定，完全不需要自己维护UIApp.instance和provideUIApp()方法。在需要使用UIApp的地方直接注入即可：

// 示例：在ViewModel中注入
@HiltViewModel
class MyViewModel @Inject constructor(
    private val uiApp: UIApp
) : ViewModel() {
    // 使用uiApp
}

方案3：改用延迟初始化的安全方式

如果一定要保留单例写法，可以用lazy结合ApplicationProvider避免初始化顺序问题：

@HiltAndroidApp
class UIApp : Application() {
    companion object{
       @JvmStatic
       val instance: UIApp by lazy {
           ApplicationProvider.getApplicationContext()
       }
    }
}

这种方式下，instance第一次被调用时会自动获取全局ApplicationContext，ApplicationProvider在Application创建完成后就能正常返回实例，不会出现未初始化问题。

对比Code A的单例写法 #

Code A的双重校验锁单例是线程安全的，但初始化依赖外部传入参数；而Application单例属于全局上下文单例，更适合用Android系统生命周期回调或依赖注入框架管理，避免手动维护带来的初始化顺序问题。

内容的提问来源于stack exchange，提问作者HelloCW