You need to enable JavaScript to run this app.
优惠活动
大模型
产品
解决方案
定价
更多

静态访问Application类资源是否会引发内存泄漏?附代码示例

关于静态访问Application资源的内存泄漏问题

首先先纠正你代码里的小错误:你的companion object里的this.getResources()其实是调用伴生对象的方法,而不是Application实例的——伴生对象并没有getResources()方法,这段代码编译都通不过。正确的写法应该是先在Application里保存一个静态实例,再通过这个实例获取资源:

class App : Application() {
    companion object {
        private lateinit var instance: App
        
        fun getResources(): Resources {
            return instance.resources
        }
    }

    override fun onCreate() {
        super.onCreate()
        instance = this
    }
}

接下来回答你的核心问题:这种静态持有Application实例来获取资源的方式,不会导致内存泄漏。原因很简单:Application的生命周期和整个App完全一致,它本身就是系统维护的单例,静态持有它的实例并不会让它的生命周期变长——App运行时它存在,App销毁时它也会被回收,不存在“无法释放内存”的情况。

不过你提到的AndroidViewModel确实是更推荐的方案,完全没必要自己维护静态Application实例:

  • AndroidViewModel在创建时会自动持有Application的Context,你可以直接通过它获取资源,不需要手动传递Context
  • 它遵循Jetpack架构组件的设计规范,会自动处理配置变更(比如屏幕旋转)时的ViewModel生命周期,比手动维护静态实例更安全、更省心

最后补充两个关键注意点:

  • 千万不要用类似的方式持有Activity/Fragment的Context,它们的生命周期比Application短很多,静态持有会导致这些组件无法被回收,从而引发内存泄漏
  • 如果一定要自己维护Application静态实例,务必在onCreate()方法里初始化,不要在构造函数里——Application构造函数执行时,App的初始化还没完成,可能会出现空指针问题

内容的提问来源于stack exchange,提问作者Milad Alakaire

相关产品推荐
方舟 Agent Plan

超全模态模型 × Harness 升级,最新支持 Deepseek-V4.1-Flash、GLM-5.3 系列、Doubao-Seedream-5.0-pro、Kimi-K3 (部分), 限时 9.9 元起

最近更新时间:2026.05.21 06:38:45