在Android编程中，几乎到处传递的最常用的参数是Context。我们知道the purposes it serves。但我们无法找出为什么我们应该为此目的传递它，以及为什么不从全局静态位置访问它。
基于Uncle Bob的清洁代码，获得更清晰代码的一种方法是减少参数，使其对您正在执行的任务更有意义。基于此，并基于DRYing参数，我们决定试一试，并创建一个功能齐全的应用程序，其中包含活动，片段，前台和后台服务，通知，媒体等，并使用许多设备API，如相机， GPS等是一个真实的应用程序，只在应用程序创建时初始化了一个静态上下文。
因此在应用程序创建中我们创建了一个public static Context context变量，并使用getApplicationContext()覆盖中的onCreate()方法对其进行初始化。
然后我们不是在整个代码中传递this，getContext等上下文，而是使用App.context，我们没有将它作为构造函数参数传递给我们的适配器和其他实用程序函数。
在冒险尝试这个大胆的运动后，我们认为我们的应用程序没有任何问题。一切正常，电池消耗没有改变，至少它对我们来说是不可测量的，所以它非常低。内存消耗没有改变，我们无法测量它。应用程序性能和速度不会发生显着变化。
因此，我们心中有这个非常大的问题，我们的方法有哪些缺点？为什么Android人员不仅暴露可以初始化的全局上下文并从整个生态系统中删除所有上下文参数，只在他们需要的时候访问该全局变量？
请仔细阅读this博客，了解上下文更好。
静态变量在类的全局范围内定义，因此它们也称为类成员。
在我的项目中，我将静态应用程序上下文用于除图形之外的所有内容事实是应用程序上下文不包含有关样式的信息，如果您基于它创建窗口小部件，那么它将具有默认样式。
在这一刻，我从未遇到过这种方法的问题。重要的是，我没有为我的项目编写测试。但我确信这不会成为问题。
如果你指出我使用上下文的问题，我也将非常感激。 （测试除外）
您的应用程序不会因为您正在使用应用程序上下文而中断：这可能不是最佳实践，但通常很好。
您缺少的是Context是一个具有许多不同实现的抽象类（Activity是Context，Service是Context，Application是Context），具有不同的属性和功能。 Activity具有与其关联的整个图形上下文以及可在内存中占用兆字节的完整视图层次结构。
一个常见的错误（我早期就做过）是将Activity存储在一个静态字段中：一旦用户将应用程序置于后台，就会在内存中产生两个完整的视图层次结构，从而导致内存泄漏onDestroy(...)回调，用户再次打开应用程序。