在活动之间共享全局变量的最佳实践

Question

我有点困惑如何在安全的 android 项目中在活动之间共享全局变量。

哪种做法是最佳实践？扩展 Application 类还是创建自定义单例类？

希望能得到帮助，提前致谢。

- Augusto Picciani

---

你能解释一下你想要实现什么或者需要解决什么问题吗？ - Asahi

使用 Application 类 https://www.intertech.com/Blog/androids-application-class/ - NoWar

Answer 1

将东西存储在应用程序类中的问题是，您无法保证活动将从应用程序对象的相同实例恢复。例如，活动可以暂停，由于内存而终止（以及您在该实例中对对象所做的任何更改），然后使用新的应用程序实例恢复活动。

这里有一篇非常好的博客文章，解释了存储在应用程序类中的数据可能会丢失： http://www.developerphil.com/dont-store-data-in-the-application-object 我不确定这是否是最佳实践，但我认为这是一个不错的解决方案。

我有一个PersistData类，保存应用程序范围的“全局变量”。我使用Dagger将此单例的实例注入到需要这些变量的任何类中。

基本过程如下：

当我通过类似以下内容保存值时：

mPersistData.saveEmailId("[e-mail]");

1. 首先将其写入SharedPreferences中的一个条目
2. 然后将其保存到成员变量中

在类的构造函数中，通过从SharedPreferences中读取它们来初始化成员变量。这样，对于该变量的读取是“缓存”的，即它们不需要从SharedPreferences中读取，如果应用程序被杀死并重新启动，则成员变量具有正确的值。如果只在应用程序类中保存值，则在应用程序重新启动时，成员变量将无效（不是您预期的或甚至为null）。

下面是一个例子：

public class PersistData {
    private String email; 
    public PersistData(MyApp app) {
        mApp = app;
        email = readEmailId();

    }

    public void saveEmailId(String emailToSave) {
        writeEmailId(emailToSave);
        email = emailToSave;
    }

    private void writeEmailId(String emailId) {
        generalSettingsFileEditor.putString("USER_ID", emailId);
        generalSettingsFileEditor.commit();
    }

    public String readEmailId() {
        String emaiId = generalSettingsFile.getString("USER_ID","");
        return(emaiId);
    }

    public String getEmail() {
        return email;
    }
}

在我的应用程序Dagger模块中，我有以下内容：

@Provides @Singleton
public PersistData providePersistData () {
    System.out.println(String.format("mApp = %s", mApp));
    return new PersistData(mApp);
}

每当我需要访问这些变量中的任何一个时，我都会这样注入单例：

public class HomePresenter {
    @Inject
    PersistData mPersistData;
    ...

    mPersistData.saveEmailId("[e-mail]");
    myEmail = mPersistData.getEmailId();

   ...
}

- nPn

Answer 2

什么是最佳实践？扩展应用程序类还是创建自定义单例类？

1. 仔细考虑这些变量是否真的是全局的，它们必须在活动之间共享。

2. 如果第一个问题的答案是“是”，那么最好的地方就是将它们存储在Application中。

你也可以实现一个单例，但是1）它稍微难以测试，2）如果您的全局变量需要Context，则再次使用Application实例最合适。

- sergej shafarenka