是否允许将ActivityContext/ApplicationContext放入变量?
请告诉我,是否允许将 ActivityContext/applicationContext 放入以下代码中所示的变量?
class MainActivity : Activity() {
private val context = applicationContext
override fun onCreate(savedInstanceState: Bundle?) {
super.onCreate(savedInstanceState)
setContentView(R.layout.activity_main)
}
}
如您在Android中所知,垃圾收集器的根是:静态变量和活动线程。
案例1。我们将 applicationContext 放在上下文
中多变的。
private val context = applicationContext
会有内存泄漏吗?我不这么认为,因为ApplicationContext是运行应用程序的过程中的单身人士。
情况2。我们将活动或此放在上下文
变量中。
private val context = this
会有内存泄漏吗?我的直觉告诉我不要这样做。因为活动可以被破坏(例如,当屏幕旋转时)。如果我对的话,请解释为什么会有内存泄漏,因为没有使用垃圾收集器根。也许我错了,允许这种行为。
ps 如果我们将变量上下文
放在companion object
中,情况会相似吗?
class MainActivity : Activity() {
companion object {
private val context = applicationContext // or this
}
override fun onCreate(savedInstanceState: Bundle?) {
super.onCreate(savedInstanceState)
setContentView(R.layout.activity_main)
}
}
Please tell me is it allowed to put ActivityContext/ApplicationContext in a variable as shown in the code below?
class MainActivity : Activity() {
private val context = applicationContext
override fun onCreate(savedInstanceState: Bundle?) {
super.onCreate(savedInstanceState)
setContentView(R.layout.activity_main)
}
}
As you know in Android, the roots of the garbage collector are: static variables and active threads.
Case 1. We put applicationContext in the context
variable.
private val context = applicationContext
Will there be memory leak? I don't think so, because applicationContext is a singleton in the process of running the application.
Case 2. We put activity or this in the context
variable.
private val context = this
Will there be memory leak? My intuition tells me not to do this. Because Activity can be destroyed (for example, when the screen is rotated). If I'm right, please explain why there will be a memory leak, because no garbage collector root is used. Maybe I'm wrong and this behavior is allowed.
P.S. Will the situation be similar if we put variable context
in companion object
?
class MainActivity : Activity() {
companion object {
private val context = applicationContext // or this
}
override fun onCreate(savedInstanceState: Bundle?) {
super.onCreate(savedInstanceState)
setContentView(R.layout.activity_main)
}
}
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(1)
这些是属性,而不是变量。重要的是要了解区别,尽管不是这个特定的问题。
您的第一个代码块很好,因为在发布活动实例时将清除应用程序上下文参考,并且活动的寿命比应用程序短。
由于您说的原因,在任何情况下,代码示例案例1(静态参考或实例参考)都是完全可以的。应用程序上下文是一个单身人士,它在您的应用程序的一生中生活,因此无法泄漏。
对于情况2:如果您在伴侣对象中使用
此
,则 是指伴随对象,而不是活动实例。 (伴侣对象无法静态地获取活动实例,因为在任何给定时刻都没有单个活动实例。)但是,如果您这样做,您确实会泄露活动实例:不应将活动上下文存储在静态属性中。
对象
属性或顶级属性(类外部)所引用的任何内容都无法收集垃圾,因为对其有静态引用。不确定没有使用垃圾收集器根的意思。对象
和顶级属性是静态引用,您说自己是垃圾收集器的根源。Those are properties, not variables. It's important to understand the distinction, although not for this particular question.
Your very first code block is fine because the application context reference will be cleared when the Activity instance is released, and Activities have shorter lifetimes than the Application.
The code example Case 1 is perfectly fine in any situation (static reference or instance reference) for the reason you said. The Application context is a singleton that lives for the lifetime of your app so it cannot be leaked.
For case 2: if you use
this
in a companion object,this
refers to the companion object, not the Activity instance. (There would be no way for the companion object to statically get an Activity instance on its own because there is no single Activity instance for it to find at any given moment.) However, if you do this, you will indeed leak the Activity instance:An Activity context should never be stored in a static property.
Anything referenced by an
object
property or top-level property (outside a class) cannot be garbage collected because there is a static reference to it. Not sure what you mean by no garbage collector root being used.object
and top-level properties are static references, which you said yourself are roots for the garbage collector.