在Android中获取“上下文”’Context’ 的静态方法？

Static way to get 'Context' in Android?

有没有办法在静态方法中获取当前的Context实例？

我正在寻找这种方法，因为我讨厌每次"上下文"实例更改时都保存它。

这样做：

在Android清单文件中，声明以下内容。

1	</application>

然后写下课程：

1
2
3
4
5
6
7
8
9
10
11
12
13

public class MyApplication extends Application {

private static Context context;

public void onCreate() {
super.onCreate();
MyApplication.context = getApplicationContext();
}

public static Context getAppContext() {
return MyApplication.context;
}
}

现在，所有地方都调用MyApplication.getAppContext()静态获取应用程序上下文。

相关讨论

这种方法有什么缺点吗？这看起来像作弊。(黑客？)
缺点是，不能保证在某些静态初始化代码尝试获取上下文对象之前调用了非静态onCreate()。这意味着您的调用代码需要准备好处理空值，这会破坏这个问题的全部要点。
也可能…我们应该把这个static context变量声明为volatile变量吗？
@Vladimirsorokin:不需要volatile关键字，因为上下文总是引用同一个对象。指针的值可以设为最终值，因为一旦赋值，指针就不会更改。
@你不能让它成为最终版本，因为它不是在c-tor中初始化的。仍然可以通过多个线程访问context变量。并根据实践中的"Java并发"-3.5.3。安全发布习语：要安全地发布引用，应该使用以下方法之一：静态初始值设定项、volatile字段、atomicreference、final字段、lock。否则，您可能会遇到并发性问题。但我不能百分之百肯定我们的具体情况，有不同的细微差别，所以我决定使用volatile，以防万一，它无论如何都不会影响性能。
这在图书馆项目中似乎不起作用。
有人知道在onCreate()中而不是在构造函数中设置上下文变量的原因吗？
@基拉尼可能是因为它以前不存在？你可能会得到空的。
@梅林同意，我不同意。如果您有用静态初始化的静态属性，那么您已经知道您正在做一些依赖于初始化顺序的事情，需要小心。大多数情况下，你不会用这种方式。
@Nerith在公共库代码中创建一个"Surrogate"类，然后从app.onCreate()中设置Surrogate.Context。我还为buildconfig.debug标志执行此操作，因为它无法从库代码访问。
@Tom这不是静态数据成员最初是静态的情况。在给定的代码中，静态成员正在onCreate()中进行非静态初始化。在这种情况下，即使静态初始化的数据也不够好，因为没有任何东西可以确保给定类的静态初始化将在其他某个类的静态初始化过程中访问它之前发生。
@梅林同意你刚才的说法。出于您所说的原因，我只是不引用静态初始值设定项中的getApplicationContext。OP想要一种通过静态方法访问上下文的方法，但我并没有将其解释为他希望能够在静态初始值设定项中使用该静态方法。
@同样，这不是关于静态初始化，而是一般的初始化顺序。所提出的解决方案只建立了一个竞争条件。如果它一般看起来是有效的，那就好像是好运(即坏运气)。这就是我在第一条评论中描述的缺点，为了安全起见，调用者需要准备好获取空值。不幸的是，这似乎是运营商试图解决的问题。根据具体情况，可能操作人员没有意识到活动和服务是上下文，可能从一开始就没有问题。
@基拉尼：是的-见：stackoverflow.com/a/16391156/281545
@根据应用程序的文档，在创建任何活动、服务或接收器(不包括内容提供程序)之前调用onCreate()。所以，只要您不尝试从内容提供程序访问getAppContext()，这个解决方案就不会是安全的吗？
@Badcash我认为在某种程度上，它是"安全的"，因为框架保证OnCreate将为每个活动调用，到那时，应用程序上下文也将被创建。但是，从维护的角度来看，您必须注意一些警告，也就是说，您必须准备好获取空值，这取决于您从何处调用此函数。(例如，如果从构造函数调用它，则上下文静态变量可能尚未初始化。)因此，应该始终检查是否为空，以确保正确。就我个人而言，我不会这样做的。
@Badcash，谢谢你指出文件。前面说，一般不需要从应用程序中进行子类划分，因为单例可能更好。然后它说，要实现这样一个singleton，获取实例的函数应该在其上下文中传递，在该上下文中，singleton初始化调用getApplicationContext()。这样，第一个调用将导致设置单例，调用方不必担心获取空值。不幸的是，这意味着他们必须有一个背景，这是最初的问题。下面的回答是正确的。
当使用android.intent.action.boot_completed broadcast调用应用程序时，会调用onCreate方法吗？这似乎是我问题的根源。我本来以为OnCreate会被调用，但出于某种原因，情况似乎并非如此。在使用您的解决方案时，在某些情况下应该小心。
@在这种情况下，不会有泄漏，因为只要应用程序本身是活动的，应用程序对象就处于活动状态，即在应用程序的生命周期内不会被垃圾收集。
当应用程序有一个内容提供程序，其中内容提供程序在应用程序对象之前被初始化，因此在这种情况下，您不能指望要初始化的静态字段。
只要您不初始化静态地尝试引用静态存储上下文的类，那么在应用程序的子类(在androidmanifest.xml中定义为应用程序)中这样做是安全的，因为Android系统保证您的应用程序实例。OnCreate将是在任何否则。因此，虽然在普通Java中不是一种"安全"的方式，但这就像在一个普通的Java主程序中设置静态字段一样。安全的，只要您没有对其他静态初始化字段进行糟糕的静态处理。
这个解决方案会触发一个android lint性能警告，因为放置在静态字段中的android上下文构成内存泄漏…你可以自己在android studio:analyze>inspect code中查看它…
看到这个答案有多少赞成票，真让人难过。您不应该将静态实例保存到上下文中——为了证明这一点，请尝试使用泄漏金丝雀(github.com/square/leackcanary)，并查找由此导致的内存泄漏。@拥有Enough代表和Android知识的人，请重新审查此答案并采取相应行动。这肯定会被初学者使用，这是一个简单的错误。
@Cyrilchampier I制作了一个与图书馆合作的图书馆：github.com/louiscad/splities/blob/master/appctx/readme.md它使用一个虚拟的ContentProvider来获得一个安全的Context。
按照"应该容易的事情应该容易"的现代精神，应该有一个context.getApplicationContext()或application.getApplicationContext()静态方法。这个物体是单件的，不需要穿过铁环就可以够到。在解决这个问题之前，在静态初始值设定项或内容提供程序之外，即在99%的代码中，这个答案提供了一个合理的解决方法。感谢那些评论指出了这种技术不安全的具体情况。
@Crearorotar事实上，存储对应用程序上下文的静态引用并不是一个坏做法，在我看来，不会有任何内存泄漏，因为Android系统已经杀死了您的进程，尽管我同意应该小心使用它。

大多数应用程序需要一种方便的方法来获取应用程序上下文，它们创建自己的类来扩展android.app.Application。

指南

您可以通过在项目中创建一个类来实现这一点，如下所示：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

import android.app.Application;
import android.content.Context;

public class App extends Application {

private static Application sApplication;

public static Application getApplication() {
return sApplication;
}

public static Context getContext() {
return getApplication().getApplicationContext();
}

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

然后，在androidmanifest中，您应该在androidmanifest.xml的标记中指定类的名称：

1
2
3
4
5

然后，可以使用以下方法检索任何静态方法中的应用程序上下文：

1
2
3

public static void someMethod() {
Context context = App.getContext();
}

警告

在将上述内容添加到项目中之前，您应该考虑文档中的内容：

There is normally no need to subclass Application. In most situation,
static singletons can provide the same functionality in a more modular
way. If your singleton needs a global context (for example to register
broadcast receivers), the function to retrieve it can be given a
Context which internally uses Context.getApplicationContext() when
first constructing the singleton.

反射

还有另一种使用反射获取应用程序上下文的方法。在Android中，反射经常被忽视，我个人认为这不应该用于生产。

要检索应用程序上下文，我们必须对自API 1以来可用的隐藏类(ActivityThread)调用一个方法：

1
2
3
4

public static Application getApplicationUsingReflection() throws Exception {
return (Application) Class.forName("android.app.ActivityThread")
.getMethod("currentApplication").invoke(null, (Object[]) null);
}

还有一个隐藏类(AppGlobals)，它提供了一种以静态方式获取应用程序上下文的方法。它使用ActivityThread获取上下文，因此以下方法与上面发布的方法没有区别：

1
2
3
4

public static Application getApplicationUsingReflection() throws Exception {
return (Application) Class.forName("android.app.AppGlobals")
.getMethod("getInitialApplication").invoke(null, (Object[]) null);
}

快乐编码！

不，我想没有。不幸的是，您无法从Activity或Context的其他子类中调用getApplicationContext()。而且，这个问题有些关联。

相关讨论

假设我们在讨论获取应用程序上下文，我按照@rohitghatol扩展应用程序的建议实现了它。然后发生的事情是，无法保证以这种方式检索的上下文总是非空的。在您需要它的时候，通常是因为您想要初始化一个助手或获取一个资源，所以您不能延迟；处理空的情况对您没有帮助。所以我明白我基本上是在和android体系结构作斗争，如docs所述。

Note: There is normally no need to subclass Application. In most situations, static singletons can provide the same functionality in a more modular way. If your singleton needs a global context (for example to register broadcast receivers), include Context.getApplicationContext() as a Context argument when invoking your singleton's getInstance() method.

由黛安·哈克伯恩解释

The only reason Application exists as something you can derive from is because during the pre-1.0 development one of our application developers was continually bugging me about needing to have a top-level application object they can derive from so they could have a more"normal" to them application model, and I eventually gave in.
I will forever regret giving in on that one. :)

她还建议解决这个问题：

If what you want is some global state that can be shared across different parts of your app, use a singleton. [...] And this leads more naturally to how you should be managing these things -- initializing them on demand.

因此，我所做的就是去掉扩展应用程序，并将上下文直接传递给singleton helper的getInstance()，同时在私有构造函数中保存对应用程序上下文的引用：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

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;
}
}

然后调用方将本地上下文传递给帮助程序：

1	Helper.getInstance(myCtx).doSomething();

因此，要正确回答这个问题：有一些方法可以静态地访问应用程序上下文，但它们都不应该被鼓励，您应该更喜欢将本地上下文传递给singleton的getInstance()。

对于任何感兴趣的人，您可以在fwd blog上阅读更详细的版本。

相关讨论

这是最有趣和最正确的答案，尽管在接受的一个上有600多个赞成票。隐形珍珠
@Shine我想这一个需要一些赞成票：)在使用建议的方法6个月后，我再也不会回去静态地检索上下文了；这对我来说是一个很好的学习，我希望这个答案能被更多地阅读(和使用)。感谢您的评论！
getInstance()不应该有static关键字吗？
绝对是@jk7，谢谢你的评论，修好了！
请注意，在android studio(至少2.3.1)中，当您执行此操作(内存泄漏)时，会出现一条警告：不要将上下文保存在静态字段中。在这种情况下，这是正确的吗？我通过从上下文中获取所需的一切并将其(文件路径等)保存在成员中来摆脱它，所以我很好，只是澄清一下。而且，这种方法一开始看起来有点奇怪，因为您对随后调用getInstance()的上下文没有做任何处理。：)尽管如此，这个答案使我比公认的更信服。
@gero我保存应用程序上下文引用，因为我假设myhelper的其他方法需要它。如果你永远不需要它，那么你就不应该保留它的参考(为什么？).另外，您的方法不允许资源更改(例如，当用户切换语言时)，因此我不建议这样做。最后但同样重要的是，lint警告是正确的，因为lint看到的是一个上下文，但在这种情况下，我在一个单例上取应用程序上下文("当前进程的单个全局应用程序对象的上下文")，在延迟初始化之后，该上下文一直可用，直到崩溃为止。
@是的，在我的情况下，我不适应资源的变化，但在我的应用程序的上下文中，这对我来说很好。最后，我确实删除了对上下文的引用(在意识到我可以简单地使用初始化时从中获得的数据之后)。所以我想说，"因此，在我的例子中，继续在随后的getInstance()调用中传递上下文有点奇怪"，如果不清楚的话，很抱歉。另外，感谢您澄清，只要保存应用程序上下文，就可以忽略lint警告。我已经猜到了，但是确认总是好的。
@在您的特定情况下，gero会更加防御性：不要将上下文传递给构造函数或getInstance()，而是直接传递所需的初始化参数，并让调用者使用上下文来检索它们。然后您的接口/API就更加清晰了，因为它表明您的类或助手根本不需要上下文。不客气，我很高兴澄清，而且我还计划为这个答案写一个扩展条目，所以我有更多的空间评论和回答任何疑问。
@是的，那可能更有用。不管怎样，我还没有完成这门课，所以这是我要做的重构工作。我还考虑使用一个特定的setupInstance()方法或其他方法，并让singelton使用一些有意义的默认行为(如果尚未调用)。这样做的缺点是，延迟初始化不太适合这样做，因为当您需要一直传递无用的参数(只在第一次调用中使用)时，不管它是包装在上下文中还是单独的参数中，都不是这样。这是个麻烦，实例本身无法获得。
@Gero最后我为Android Context on Demand写了一篇文章，看看它是否对你有帮助！
@阿莱西奥好文章！这正是我最终做的(除了多线程概念，因为我现在不需要它)。非常感谢你为这个问题付出了额外的努力，也感谢你搜集了有关这个问题的各种资料(比如黛安娜的声明)。
@alessio这个方法不会导致内存泄漏吗
@不，你为什么这么认为？请告诉我更多信息，还请阅读我的日志了解更多有关此的详细信息
@alessio是从组件(活动)中获取上下文的一个单例。当组件被系统杀死时会发生什么。调用onResume()、onStart()时会发生什么。您应该通过在手机上打开其他几个应用程序来测试该应用程序，然后在大约5-10分钟后返回，您可能会发现您的应用程序已崩溃，因为单例引用的是来自已终止组件(活动)的上下文。
@我不明白你在说什么。singleton引用从传递的活动(而不是宿主活动)中检索到的应用程序上下文。这是合法的，不会造成任何内存泄漏。这就是我写的博客的要点。如果你真的认为你是对的，请给我一个示例代码，在那里我可以重现你所说的内存泄漏，因为情况并非如此。
回答很好，谢谢你的额外努力
@不客气！我很高兴有人欣赏，并且喜欢在有意义的时候正确地编码：)
我认为@kigenyiphillip是正确的，这仍然代表着资源泄漏。在第一次调用getInstance(ctx)后，请绘制参考图。您有一个MyHelper类型的gc根instance，它有一个Context类型的私有字段mContext，它引用通过传递给getInstance()的上下文收集的应用程序上下文。instance从来没有设置过第二次，也没有清除过，所以gc永远不会捕获instance引用的appcontext。你不会泄露任何活动，所以在我看来成本很低。
@markmckenna a s you state"which has a private field mcontext of type context，which reference s the application context"，so that's clear to you that mcontext is a reference to the application context，not to any context.在getApplicationContext()文档中，您看到："生命周期与当前上下文分离的上下文，它与进程的生命周期而不是当前组件绑定。"如何造成内存泄漏？只有当进程退出时，应用程序上下文才是gc'd。
@alessio如果您接受对应用程序上下文的引用不符合资源泄漏的条件，那么您可以通过在Application.onCreate()中发布对this的静态引用来简化这一过程，从而使接受的答案更好。
@马克·麦肯纳首先你说这是个漏洞，现在你说不是。对应用程序上下文的引用不是泄漏。但是，接受的答案(以静态方式扩展应用程序和检索上下文)的问题不在于泄漏资源，而在于检索可能是"空"的静态上下文，此时您不能对它做太多的工作。我在我们的博客中详细解释了这个问题，请仔细阅读。之后，如果你有什么问题，请告诉我。如果不是我的话，也要仔细阅读戴安娜的话。

下面是一种从UI线程中的任何位置获取应用程序(上下文)的未经记录的方法。它依赖于隐藏的静态方法ActivityThread.currentApplication()。它至少应该在Android 4.x上工作。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

try {
final Class<?> activityThreadClass =
Class.forName("android.app.ActivityThread");
final Method method = activityThreadClass.getMethod("currentApplication");
return (Application) method.invoke(null, (Object[]) null);
} catch (final ClassNotFoundException e) {
// handle exception
} catch (final NoSuchMethodException e) {
// handle exception
} catch (final IllegalArgumentException e) {
// handle exception
} catch (final IllegalAccessException e) {
// handle exception
} catch (final InvocationTargetException e) {
// handle exception
}

请注意，此方法可能返回空值，例如，当您在UI线程外部调用方法时，或者应用程序未绑定到线程时。

如果可以更改应用程序代码，最好使用@rohitghatol的解决方案。

相关讨论

这取决于您使用上下文的目的。我至少可以想到这种方法的一个缺点：

如果您试图用AlertDialog.Builder创建一个AlertDialog，那么Application上下文将不起作用。我相信你需要现有的背景资料。

相关讨论

如果您愿意使用roboguice，那么您可以将上下文注入您想要的任何类中。下面是一个如何使用roboguice 2.0(本文撰写时是beta 4)的小示例。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

import android.content.Context;
import android.os.Build;
import roboguice.inject.ContextSingleton;

import javax.inject.Inject;

@ContextSingleton
public class DataManager {
@Inject
public DataManager(Context context) {
Properties properties = new Properties();
properties.load(context.getResources().getAssets().open("data.properties"));
} catch (IOException e) {
}
}
}

我曾经用过这个：

1 2	ActivityThread at = ActivityThread.systemMain(); Context context = at.getSystemContext();

这是我在获取系统服务和工作时使用的有效上下文。

但是，我只在框架/基础修改中使用它，并没有在Android应用程序中尝试它。

您必须知道的警告：在此上下文中注册广播接收器时，它将不起作用，您将得到：

java.lang.SecurityException: Given caller package android is not running in process ProcessRecord

科特林

1
2
3
4
5
6
7
8
9
10
11
12
13

open class MyApp : Application() {
override fun onCreate() {
super.onCreate()
mInstance = this
}

companion object {
lateinit var mInstance: MyApp
fun getContext(): Context? {
return mInstance.applicationContext
}
}
}

让上下文像

1	MyApp.mInstance

或

1	MyApp.getContext()

根据这个源代码，您可以通过扩展ContextWrapper来获取自己的上下文。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

public class SomeClass extends ContextWrapper {

public SomeClass(Context base) {
super(base);
}

public void someMethod() {
// notice how I can use"this" for Context
// this works because this class has it's own Context just like an Activity or Service
startActivity(this, SomeRealActivity.class);

//would require context too
File cacheDir = getCacheDir();
}
}

用于ContextWrapper的JavaDoc

Proxying implementation of Context that simply delegates all of its calls to another Context. Can be subclassed to modify behavior without changing the original Context.

相关讨论

您可以使用以下内容：

1	MainActivity.this.getApplicationContext();

mainactivity.java：主要活动.java

1
2
3
4
5
6
7
8

...
public class MainActivity ... {
static MainActivity ma;
...
public void onCreate(Bundle b) {
super...
ma=this;
...

任何其他类别：

1
2
3

public ...
public ANY_METHOD... {
Context c = MainActivity.ma.getApplicationContext();

相关讨论

我想你需要一具尸体来做getAppContext()法：

1 2	public static Context getAppContext() return MyApplication.context;

Kotlin之道：

显示：

1	</application>

我的应用.kt

1
2
3
4
5
6
7
8
9
10
11
12

class MyApplication: Application() {

override fun onCreate() {
super.onCreate()
instance = this
}

companion object {
lateinit var instance: MyApplication
private set
}
}

然后您可以通过myapplication.instance访问该属性。

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

1
2
3
4
5
6
7
8
9
10
11

public class App {
private static Context context;

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

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

并在活动开始时设置上下文：

1
2
3
4
5
6
7
8
9
10
11
12

// MainActivity

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

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

// Other stuff
}

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

相关讨论

我使用了一个单件设计模式的变体来帮助我完成这个任务。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

import android.app.Activity;
import android.content.Context;

public class ApplicationContextSingleton {
private static Activity gContext;

public static void setContext( Activity activity) {
gContext = activity;
}

public static Activity getActivity() {
return gContext;
}

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

然后我在活动中调用ApplicationContextSingleton.setContext( this );，oncreate()和ondestory()中调用ApplicationContextSingleton.setContext( null );；

相关讨论

如果出于某种原因，您希望在任何类中包含应用程序上下文，而不仅仅是那些扩展应用程序/活动的类，可能是对于某些工厂类或助手类。您可以将以下单例添加到您的应用程序中。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

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中初始化它

1	GlobalAppContextSingleton.getInstance().initialize(this);

打电话到任何地方都可以使用

1	GlobalAppContextSingleton.getInstance().getApplicationContext()

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

相关讨论

我刚刚发布了一个基于jquery的Android框架，叫做vapor api，旨在使应用程序开发更简单。

中央EDCOX1×10×Futd类维护一个EDCOX1×11(链接到Ethan Nicholas的关于这个惊人的Java博客文章)到当前EDCOX1 1上下文，您可以通过调用来检索：

$.act()

WeakReference在不阻止垃圾回收回收回收原始对象的情况下维护引用，因此不应该出现内存泄漏问题。

当然，不利的一面是，您有可能面临$.act()可能返回空值的风险。不过，我还没有遇到这种情况，所以这可能只是一个最小的风险，值得一提。

如果不使用VaporActivity作为Activity类，也可以手动设置上下文：

1	$.act(Activity);

而且，许多vapor api框架都固有地使用这个存储上下文，这可能意味着如果您决定使用这个框架，就不需要自己存储它。有关更多信息和示例，请访问网站。

希望有帮助：)

相关讨论

所以我修改了接受的答案，因为它导致了内存泄漏，这就是我想到的……

AndroidManifest.xml

1
2
3

...

</application>

MyApplication.java

1
2
3
4
5
6
7
8
9
10
11
12

public class MyBakingAppContext extends Application {
private static Object mContext;

public void onCreate() {
super.onCreate();
mContext = getApplicationContext();
}

public static Context getAppContext() {
return (Context)mContext;
}
}

我实际做的是，为一个对象分配一个上下文，并将该对象作为上下文返回(将其转换为上下文)。希望能有所帮助。

相关讨论

罗希特的回答似乎是正确的。但是，请注意，据我所知，AndroidStudio的"即时运行"依赖于代码中没有static Context属性。

相关讨论