我知道扩展 Application 类以提供全局存储的技术。但是，在我的情况下，我正在为库函数编写一个类，因此不希望强制该类的用户走这条路。我需要一些静态类变量。我在 StackOverflow 中看到了传递引用，这些引用可能不安全。但是，我尝试了两个使用同一个类的不同应用程序，即使在 Galaxy S3 上以多窗口模式并排运行这两个应用程序时，静态类变量仍然是分开的。
那么，对 Android 内部有深入了解的人能否确认这是否安全。
如果不安全，我可以将变量包装在嵌套类中，并将它们添加到 Serializable 静态 HashMap 中，使用应用程序包名称作为键。这将迫使他们安全。但是，如果这不是必需的，那么我宁愿不这样做。
我在 StackOverflow 中看到了传递引用，这些引用可能不安全。
它们不是“安全的”，因为您的进程将不时终止，从而清除您的静态数据成员（以及您的 custom Application）。因此，静态数据成员对缓存有好处，而不是其他。
在该范围内，它们是“安全的”。
您只需要确保这些数据要么永久存储在某个地方（例如，文件），要么可以在进程终止并稍后再次启动时重新生成。这与 with 没有什么不同Application。
但是，我尝试了两个使用同一个类的不同应用程序，即使在 Galaxy S3 上以多窗口模式并排运行这两个应用程序时，静态类变量仍然是分开的。
正确的。这些是单独的过程，具有您的类和对象的单独副本。
如果您的目标是在应用程序生命周期的曲折中存储持久数据，那么我建议不要使用静态变量来这样做。这种方法的明显问题是，当操作系统决定回收内存时（即当屏幕休眠或其他应用程序启动内存密集型任务时），它们很容易被系统垃圾收集。我不确定您要“存储”什么样的数据，但我建议您将状态保存在SharedPreferences其中SQLiteDatabase。
我对你想要做什么感到有点困惑。您正在尝试在 Java 中创建一个实用程序库以供其他应用程序使用？您正在尝试创建一个供其他应用程序使用的整个 Activity？
无论如何，正如其他海报所提到的，应用程序几乎可以在资源紧张的任何时候被终止。根本无法保证静态全局值将保留在内存中。您必须提供一种在onPause()或onSaveInstanceState()上备份它的方法。
如果您正在编写一个实用程序库，我认为它会返回一些包含其所有状态的主对象。向该对象添加saveState(Bundle)、restoreState(Bundle)方法，以及可选的 saveToSharedPreferences()和restoreFromSharedPreferences()方法。
如果您正在编写一个 Activity，那么您可能已经熟悉了保存状态的方法。
我，我喜欢将“单例模式”与共享偏好结合起来：https ://stackoverflow.com/a/13673178/338479
您似乎对课程的工作方式有很深的误解。
即使两个类在两个单独的应用程序（默认情况下）中的同一个包中，这些应用程序也运行在单独的虚拟机（即进程）上。它们实际上彼此无关（应该如此，否则您可能会遇到不可接受的跨应用程序名称冲突）。
您正在寻找的不是一种使用静态变量的方法，而是一种进行进程间通信 (IPC) 的方法。Android 的服务非常适合这一点，尽管那里的学习曲线有点陡峭。