我在Android中发现并阅读了很多关于全局变量的文章，其中一些建议使用Application的子类+在清单文件中将其声明为glbal变量容器。
但有些文章提到，当系统内存不足时，这个类也可以被杀死，这是正确的吗？
那么，将Application子类用作全局变量容器是否100％可靠？有人可以给我一些文件的链接，解释Android中应用程序的生命周期（不是活动）吗？
编辑：
感谢您的回答，我想我需要解释一下我的问题。
情况是，我只想共享一个全局String变量，Activity A修改它，而活动B读取它。
当B当前可见且用户接到电话时， 如果A和B被杀死但应用程序保持不变（这是谷歌称之为空进程吗？），我很好。 如果A，B和Application类都被杀死，当用户回来时我的应用程序开始干净，我很好。
我不熟悉它，包括Application类在内的一切都被杀死了，当用户回来时我的应用程序没有重新启动，我的意思是，它从Activity B开始，会发生吗？我应该手动启动A还是让Application类进行启动？这些想法对我来说都不合适......
答案 0 :(得分：2)
答案是“YES”和“NO” - Application类可以用作“全局变量容器”，因为所有活动和类都可以依赖它。
但是，无法依赖Application类（或任何其他类）无限期地保留。换句话说，如果用户接听了他们的电话，您的应用程序可能会被销毁，然后在用户完成呼叫并重新启动到您的应用程序时重新创建。因此，您绝对不能依赖它来持久化数据，但您可以依赖它来在应用程序处于活动状态时提供对数据的全局访问。
这是Android文档：
http://developer.android.com/training/basics/activity-lifecycle/index.html
这是一个非常好的帖子 - 阅读第二高投票回复，除了“接受”回复：
Using the Android Application class to persist data
它清楚地解释了您的应用程序如何被杀死/破坏，无论您是否期望它。
编辑：
为了澄清，如果你在Application类中有一个变量（称之为“myVar”）并且用户在Activity A中设置它，那么进入活动B，活动B将能够读取更改。
如果Android“销毁”应用程序类，这可能在用户不在您的应用程序中时发生（在极少数情况下即使它们是......），也会重建应用程序以使活动堆栈仍然有效但是“myVar”没有设置，除非你持久保存数据。
换句话说，Android将重新创建Application类和Activity B，但不能保证它会重新创建活动A，直到用户做某事来销毁活动B.此外，它肯定不会“重放”用户操作在活动A中，为了重新创建应用程序状态，在您的情况下，这意味着“myVar”不可靠。
如果您阅读所提供的参考资料，您会看到情况就是这样（我也测试了它）。
编辑2：
要保留数据，请考虑SQLite（这是非常复杂且有很多引用）或SharedPreferences：
How to use SharedPreferences in Android to store, fetch and edit values
答案 1 :(得分：1)
当系统内存变低时，这个类也可以被杀死，这是正确的吗？
是
因此，将Application子类用作全局是否100％可靠 变量容器？
如果要使用它来传递值，则不可靠。 为什么？
编辑：
我不熟悉的是，一切都被杀死了，其中包括 应用程序类，当用户回来我的应用程序时，我没有重新开始 意思是，它从活动B开始，会发生这种情况吗？
是肯定的。您可以在活动A中设置应用程序中的值，然后当您在活动B中时，用户将离开您的应用程序，并且在一段时间后，Android会终止您的进程。然后用户回来想看看你的应用程序。 android再次重新创建应用程序和活动B但不重新创建活动A，而不是使用已将活动A传递给它的应用程序变量填充它，它从默认初始化重新创建它。所以，你只是错过了活动A通过或设定的内容。