如今，拥有上下文的正确方法是使用依赖注入。 例如，可以使用Hilt在任何需要的地方注入上下文。假设一个人需要某个数据库管理器中的上下文，那么这可以通过以下方式解决:

在Gradle中添加刀柄:

implementation "com.google.dagger:hilt-android:2.35"
kapt "com.google.dagger:hilt-android-compiler:2.35"

用@HiltAndroidApp注解定义Application类(例如，让它注入数据库管理器):

@HiltAndroidApp
class MyApplication : Application() {

    @Inject
    lateinit var dbManager: DBManager

    override fun onCreate() {
        super.onCreate()
        dbManager.initDB()
    }
}

定义数据库管理器(以@Singleton为例):

@Singleton
class DBManager @Inject constructor(
    @ApplicationContext private val context: Context
) {

    fun initDB() {
        // context is avaiable
        databaseInit(context)
    }
}

就是这样。DBManager可以以正确的方式访问上下文，没有内存泄漏。

这取决于您使用上下文的目的。我认为这种方法至少有一个缺点:

如果您正在尝试使用AlertDialog创建AlertDialog。Builder，应用程序上下文将无法工作。我相信你需要了解当前活动的背景……

不，我想没有。不幸的是，您只能从Activity或Context的其他子类调用getApplicationContext()。而且，这个问题有点相关。

如果你出于某种原因想在任何类中都有Application上下文，而不仅仅是那些扩展应用程序/活动，也许是一些工厂类或帮助类。你可以将以下单例添加到你的应用程序中。

public class GlobalAppContextSingleton {
    private static GlobalAppContextSingleton mInstance;
    private Context context;

    public static GlobalAppContextSingleton getInstance() {
        if (mInstance == null) mInstance = getSync();
        return mInstance;
    }

    private static synchronized GlobalAppContextSingleton getSync() {
        if (mInstance == null) mInstance = 
                new GlobalAppContextSingleton();
        return mInstance;
    }

    public void initialize(Context context) {
        this.context = context;
    }

    public Context getApplicationContext() {
        return context;
    }
}

然后在应用程序类的onCreate with中初始化它

GlobalAppContextSingleton.getInstance().initialize(this);

在任何地方通过调用使用它

GlobalAppContextSingleton.getInstance().getApplicationContext()

但是，除了应用程序上下文之外，我不推荐使用这种方法。因为它会导致内存泄漏。

Assuming we're talking about getting the Application Context, I implemented it as suggested by @Rohit Ghatol extending Application. What happened then, it's that there's no guarantee that the context retrieved in such a way will always be non-null. At the time you need it, it's usually because you want to initialize an helper, or get a resource, that you cannot delay in time; handling the null case will not help you. So I understood I was basically fighting against the Android architecture, as stated in the docs

注意:通常不需要子类化Application。在大多数情况下，静态单例可以以更模块化的方式提供相同的功能。如果你的单例需要一个全局上下文(例如注册广播接收器)，在调用你的单例的getInstance()方法时，包括context . getapplicationcontext()作为context参数。

并由黛安·哈克伯恩解释

Application作为派生对象存在的唯一原因是，在1.0之前的开发过程中，我们的一个应用程序开发人员不断地纠缠我，说需要一个顶级的应用程序对象来派生，这样他们就可以有一个更“正常”的应用程序模型，我最终屈服了。 我将永远后悔在这一点上做出了让步。：）

她还提出了这个问题的解决方案:

如果你想要的是一些全局状态，可以在应用程序的不同部分之间共享，请使用单例。[…这就更自然地引出了你应该如何管理这些东西——按需初始化它们。

所以我所做的是摆脱扩展Application，并将上下文直接传递给单例helper的getInstance()，同时在私有构造函数中保存对应用程序上下文的引用:

private static MyHelper instance;
private final Context mContext;    

private MyHelper(@NonNull Context context) {
    mContext = context.getApplicationContext();
}

public static MyHelper getInstance(@NonNull Context context) {
    synchronized(MyHelper.class) {
        if (instance == null) {
            instance = new MyHelper(context);
        }
        return instance;
    }
}

调用者将传递一个本地上下文给helper:

Helper.getInstance(myCtx).doSomething();

因此，要正确地回答这个问题:有很多方法可以静态地访问应用程序上下文，但都不建议使用，您应该更喜欢将本地上下文传递给单例的getInstance()。

感兴趣的人可以在fwd博客上阅读更详细的版本

如果你不想修改清单文件，你可以手动将上下文存储在初始活动的静态变量中:

public class App {
    private static Context context;

    public static void setContext(Context cntxt) {
        context = cntxt;
    }

    public static Context getContext() {
        return context;
    }
}

当你的activity(或多个activity)开始时，只需设置上下文:

// MainActivity

@Override
public void onCreate(Bundle savedInstanceState) {
    super.onCreate(savedInstanceState);
    setContentView(R.layout.activity_main);

    // Set Context
    App.setContext(getApplicationContext());

    // Other stuff
}

注意:与所有其他答案一样，这是一个潜在的内存泄漏。