0

我在活动、适配器、应用程序等中使用了很多静态数据，比如

companion object{
    const val SEND_MY_DATA = "sendta"
    const val SEND_MY_DATA_1 = "sendta1"
    const val SEND_MY_DATA_2 = "sendta2"
}

为 Intent Extras 使用通用名称，以匹配两个活动之间的相同名称。因此，这些静态数据用于活动和另一个活动，甚至一些适配器。

我也在应用程序类中使用了这个，比如

// this is used somewhere.
fun updateContext(){
    appContext = applicationContext
}

companion object{
    var appContext: Context? = null

    fun myFunction(context: Context){
        // use context param here.
    }
}

这是一个不好的方法吗？有没有更好的方法来改善这一点？

4

2 回答 2

0

只是一个关于在Application课堂上保存数据的说明，我在处理Room中的本地资源时遇到了这个问题。
通常，与链接问题的情况一样，这可能是一个很好的解决方案（Android Studio 显示内存泄漏警告）。
根据您的需要，您必须小心以这种方式保存数据，因为 Android 操作系统实际上可以杀死进程，包括您的Application实例。

为了确定在内存不足时应该终止哪些进程，Android 会根据其中运行的组件和这些组件的状态将每个进程置于“重要性层次结构”中。

检查进程和应用程序生命周期以获取更多信息。
可以在这篇文章中找到关于此的完整讨论。

于 2021-10-05T10:00:32.697 回答
0

如果您要制作静态应用程序上下文引用，我认为这更清洁：

companion object {
    lateinit var context: Context
        private set
}

override fun onCreate() {
    super.onCreate()
    context = applicationContext
}

但是如果你使用依赖注入，你就不应该需要它。单例上下文模式使单元测试变得困难。

至于存储常量，伴生对象很好。它们确实会产生一个额外的编译类，但这应该是微不足道的，因为你不应该有很多活动。

于 2021-10-05T14:42:45.930 回答