Android Kotlin 全局Context实现方案是否为推荐最佳实践

你当前的实现不属于安卓官方推荐的全局Context方案，存在多个稳定性隐患，不建议在正式上线版本使用。

现有方案的核心问题 #

• 空指针崩溃风险不可控：你用WeakReference持有Activity实例，还在getter里直接用!!强制非空。当App退到后台系统回收Activity、异步任务在Activity销毁后触发取Context逻辑、或者某个页面漏了赋值操作时，WeakReference.get()会直接返回null，触发强制空指针崩溃，这类崩溃很难在测试阶段全覆盖。
• 上下文错配导致内存泄漏：你存储的是Activity级别的Context，这类Context生命周期和页面绑定。如果不小心用这个Context初始化全局单例、数据库实例、全局弹窗这类和App进程同生命周期的对象，哪怕用了弱引用，只要取值时Activity未被销毁，长生命周期对象会直接强持有Activity实例，内存泄漏无法避免。
• 维护成本极高：你需要在每一个Activity（包括未继承BaseActivity的页面、后续新增的第三方页面、系统唤起的特殊页面）里手动给静态变量赋值，只要漏写一处，就可能拿到已经销毁的旧Activity实例，引发奇奇怪怪的UI异常或者崩溃。
• 违反MVVM设计原则：ViewModel的设计初衷就是和UI层（Activity/Fragment）解耦，你开放全局任意位置可取Activity Context的入口，相当于给ViewModel层违规持有UI引用开了后门，后续很容易写出屏幕旋转时引用旧Activity、后台任务持有已销毁页面这类问题代码。

推荐的最优实现方案 #

按Context的使用场景区分处理，不要搞一个全局Context通吃所有场景：

1. 全局通用场景用Application Context #

你已经实现了Application类，直接在这里暴露全局的Application Context就行，这个Context和App进程生命周期一致，永远不会内存泄漏，也不需要手动维护赋值，能覆盖90%以上的非UI场景需求（访问资源、操作数据库、获取缓存路径、启动带NEW_TASK标志的Activity、创建全局单例等）：

class AppSettings : MultiDexApplication() {

    override fun onCreate() {
        super.onCreate()
        instance = this
        // 直接用applicationContext赋值，不需要依赖任何Activity
        appContext = applicationContext
        resourses = appContext.resources
        outputPathCache = cacheDir.absolutePath
    }

    companion object {
        lateinit var instance: AppSettings
            private set
        // 全局可用的Application Context，进程存活期间永远非空，无泄漏风险
        lateinit var appContext: Context
            private set

        var database: SQLiteDatabase? = null
        var resourses: Resources? = null
            private set

        const val defLanguage = Enum.Language.ENGLISH
        const val defIdLanguage = Enum.LanguageId.ENGLISH
        const val screenshotFilename = "xxx"

        const val actionBarTitleColor = "#0D0D0D"
        const val footerColor = "#8a8a8a"
        const val activityBackground = "#ffffff"
    }
}

2. 需要Activity Context的场景不要静态存储 #

• 如果是ViewModel需要Context，优先使用AndroidViewModel，它自带Application Context，能满足绝大多数数据处理场景的需求；如果确实需要Activity Context（比如弹窗、页面跳转、操作Window），不要在ViewModel里直接拿Context，通过LiveData/Flow发UI事件，由Activity/Fragment收到事件后用自身的Context执行操作，保证生命周期匹配。
• 如果是工具类方法需要Context，直接把Context作为方法参数传入即可，调用方根据场景传入对应生命周期的Context（页面内操作传Activity自身，全局任务传AppSettings.appContext），从根源避免生命周期错配。
• 如果确实需要全局获取当前前台Activity，不要在每个页面手动赋值，通过Application注册全局Activity生命周期回调自动维护，同时去掉强制非空逻辑：

class AppSettings : MultiDexApplication() {
    companion object {
        lateinit var appContext: Context
            private set
        private var currentForegroundActivity: WeakReference<Activity>? = null

        // 仅在明确需要Activity Context的场景调用，必须判空
        fun getCurrentActivity(): Activity? = currentForegroundActivity?.get()
    }

    override fun onCreate() {
        super.onCreate()
        appContext = applicationContext
        // 注册全局生命周期监听，自动更新当前前台Activity，无需每个页面手动赋值
        registerActivityLifecycleCallbacks(object : ActivityLifecycleCallbacks {
            override fun onActivityResumed(activity: Activity) {
                currentForegroundActivity = WeakReference(activity)
            }

            override fun onActivityStopped(activity: Activity) {
                if (currentForegroundActivity?.get() == activity) {
                    currentForegroundActivity = null
                }
            }

            override fun onActivityCreated(activity: Activity, savedInstanceState: Bundle?) {}
            override fun onActivityStarted(activity: Activity) {}
            override fun onActivityPaused(activity: Activity) {}
            override fun onActivitySaveInstanceState(activity: Activity, outState: Bundle) {}
            override fun onActivityDestroyed(activity: Activity) {}
        })
    }
}

额外注意事项 #

• 永远不要对Activity类型的Context使用!!强制非空，这类Context生命周期短于进程，随时可能被系统回收。
• 初始化数据库、全局单例、全局弹窗这类长生命周期对象时，一律使用Application Context，禁止传入Activity Context。
• 不要为了少传几个参数就在ViewModel层持有Activity引用，否则后续排查内存泄漏和生命周期崩溃的成本会远高于传参数的成本。

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