持有应用程序Context实例是不好的做法?

Bol*_*oso 10 android design-patterns android-context

根据我的理解,Android中的应用程序是一个单例(如果我错了,请纠正我),我们总是只有一个应用程序上下文实例.

那么,从这个角度来看,在我的Application类中保存应用程序Context是不好的做法吗?它会导致大量内存泄漏吗?

这是一个例子:

public class MyApp extends Application {
    private static Context appContext = null; // <-- here is the thing!

    @Override
    public void onCreate() {
        appContext = this;
    }

    public static Context getApplicationContextSingleton () {
        return MyApp.appContext;
    }
}
Run Code Online (Sandbox Code Playgroud)

这样做的原因是全局访问的类,如PreferencesManager,大多数静态方法总是需要上下文.因此,我不是每次都传递它(甚至将它存储在一个可能很糟糕的实例中),而是考虑存储应用程序上下文.有什么缺点我没看到?

Com*_*are 11

将应用程序Context保存在Application类中是不好的做法?

这是一种代码味道.

它会导致大量内存泄漏吗?

拥有静态数据成员不会导致大量内存泄漏.过度使用Application对象是否会导致大量内存泄漏取决于您使用它的位置和方式.

有什么缺点我没看到?

并非所有Contexts都是平等的.一般来说,只有Application在你明确Application知道为什么需要上下文时才使用,而不是用于所有事情.

DoubleEncore的戴夫史密斯有一篇很棒的博客文章,内容涉及不同类型Context和何时使用彼此之间的差异.

  • 你是什​​么意思"Code Smell"?它闻起来像是不好的做法? (2认同)
  • @Bolhoso:http://en.wikipedia.org/wiki/Code_smell"在计算机编程中,代码气味是程序源代码中可能表示更深层问题的任何症状.代码气味通常不是错误 - 它们不是技术上不正确,目前不能阻止程序运行.相反,它们表明设计中的弱点可能会减缓开发速度或增加未来的漏洞或故障风险." (2认同)
  • @Geralt我理解你的观点.虽然文章指出"现在我们的Context来自哪里并不重要,因为我们持有的引用是安全的.应用程序上下文本身就是一个单例,所以我们不会通过创建另一个静态引用来泄漏它."在我的情况下,创建一个Singleton PreferencesManager会更安全,我在getInstance中收到一个上下文,在那里我可以保持对应用程序上下文的引用.对? (2认同)
  • @IgorGanapolsky:你绝对没有"需要将视图作为全局静态变量传递". (2认同)