Question

在Android中，我们经常使用 Context 类。当某个类或方法需要上下文时，我们通常会使用 Activites 或服务来获取此类参数。以下代码来自我找到的网站，但我不知道这是不是很好的做法，如果可以使用这个解决方案：

public class MyApplication extends Application {
    private static MyApplication singleton;

    @Override
    public void onCreate() {
        super.onCreate();
        singleton = this;
    }

    public static MyApplication getInstance() {
        return singleton;
    }
}

首先，我可以在这里使用单例模式。我的意思是每当我的一些应用程序代码在Android中执行时，系统就会创建一个进程，因此也存在一个应用程序上下文，我可以在其他类中使用它。

另一方面，使用它是错误的。使用这种模式，每个类（也就是我们应该避免使用上下文对象的pojo和单例）都能够简单地获得对实际上下文的有效引用，其中（我认为）是不是上下文对象背后的想法。

那你怎么看待这个解决方案呢？是否可以使用它或是否有某些原因（例如应用程序的生命周期等）来避免这种情况？或者我这里的一些假设是错的？

Answer 1

是的，你是对的。可以以这样的方式设计应用程序，即我们不需要此Application类实例。

我在项目中使用依赖注入模式。比如说，我的Presenter类需要一个DataRepository类实例来获取数据。 DataRepository类需要Context才能访问Database或SharedPreferences。

可以使用Application实例在Presenter类中创建DataRepository类。但是使用依赖注入模式，我在Presenter之外创建DataRepository（可能是Fragment / Activity），并通过其构造函数将DataRepository实例传递给Presenter。

Answer 2

非常好@CommonsWare的答案......只是补充......

我认为这是一个糟糕的解决方案，因为它可能导致内存泄漏 ...即使很难发生它...使用静态引用Context实例非常糟糕，因为当 ActivityManagerService 因为静态引用而导致它被销毁时，不会清除此Application实例... - 如下所示，在这种情况下，它不会导致任何内存泄漏。

我不喜欢这种解决方案...直接使用Context会更安全（例如getApplicationContext()）。

obs。：它也违反 Singleton Pattern ，因为它不限制类的实例化，并且不能确保只有一个实例...但它不是有关...

使用应用程序类作为单例

2 个答案: