在活动和应用程序类中使用伴生对象是一种好方法吗？答案

【问题标题】：Is using companion object in activity and application class a good way?在活动和应用程序类中使用伴生对象是一种好方法吗？
【发布时间】：2021-10-05 08:35:06
【问题描述】：

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

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

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

我也在应用程序类中使用过这个

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

companion object{
    var appContext: Context? = null

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

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

【问题讨论】：

为什么还要这样做？有更好的发送数据的方法和更好的获取上下文的方法，为什么你的应用程序类中有它？
@a_local_nobody 我认为获取应用程序信息最好在 Application 类中实现。所以，我做了fun getAppVersion(context: Context) 和fun compareAppVersion(context: Context) 类似的东西。

标签： android kotlin companion-object kotlin-companion

【解决方案1】：

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

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

查看Processes and Application Lifecycle了解更多信息。
可以在this post 上找到有关此问题的完整讨论。

【讨论】：

【解决方案2】：

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

companion object {
    lateinit var context: Context
        private set
}

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

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

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

【讨论】：