就像上面讨论的那样，操作系统可以在没有任何通知的情况下杀死应用程序(没有onDestroy事件)，所以没有办法保存这些全局变量。

SharedPreferences可以是一个解决方案，除非你有复杂的结构化变量(在我的情况下，我有一个整数数组来存储用户已经处理的id)。SharedPreferences的问题在于，每次需要值时都很难存储和检索这些结构。

在我的情况下，我有一个后台服务，所以我可以把这些变量移动到那里，因为服务有onDestroy事件，我可以很容易地保存这些值。

创建这个子类

public class MyApp extends Application {
  String foo;
}

在AndroidManifest.xml中添加android:name

例子

<application android:name=".MyApp" 
       android:icon="@drawable/icon" 
       android:label="@string/app_name">

class GlobaleVariableDemo extends Application {

    private String myGlobalState;

    public String getGlobalState(){
     return myGlobalState;
    }
    public void setGlobalState(String s){
     myGlobalState = s;
    }
}

class Demo extends Activity {

@Override
public void onCreate(Bundle b){
    ...
    GlobaleVariableDemo appState = ((GlobaleVariableDemo)getApplicationContext());
    String state = appState.getGlobalState();
    ...
    }
}

BARACUS框架也使用了子类化的方法。从我的观点来看，子类化Application是为了与Android的生命周期一起工作;这是任何应用程序容器所做的。我没有使用全局变量，而是将bean注册到这个上下文中，让它们被注入到上下文可管理的任何类中。每个注入的bean实例实际上都是单例的。

有关详细信息，请参阅此示例

如果你能有这么多，为什么还要做体力活呢?

如果一些变量存储在sqlite中，你必须在应用程序的大多数活动中使用它们。 那么应用可能是实现它的最好方式。 当应用程序启动时，查询数据库中的变量，并将它们存储在一个字段中。 然后可以在活动中使用这些变量。

所以要找到正确的方法，没有最好的方法。

Soonil建议的保持应用程序状态的方法是好的，但是它有一个弱点——在某些情况下，操作系统会终止整个应用程序进程。这里是关于此的文档—流程和生命周期。

考虑一个案例-你的应用程序进入后台，因为有人正在呼叫你(电话应用程序现在在前台)。在这种情况下&&在其他一些情况下(检查上面的链接了解它们可能是什么)，操作系统可能会杀死你的应用程序进程，包括application子类实例。结果，状态丢失了。当您稍后返回到应用程序时，操作系统将恢复其活动堆栈和application子类实例，但myState字段将为空。

AFAIK，保证状态安全的唯一方法是使用任何类型的持久化状态，例如为应用程序文件使用私有或sharedpreferences(它最终在内部文件系统中为应用程序文件使用私有)。