多Activity共享SharedPreferences：两种实现方案优劣咨询

问题背景 #

我开发的Android应用包含三个Activity，生命周期为Activity1 -> Activity2 -> Activity3，所有Activity需要使用完全相同的偏好设置。为此我创建了一个继承自Activity的myPreferences基类，供所有Activity继承。

第一种实现方案 #

public class myPreferences extends Activity{
 protected String PlayerName;
 protected float maxPlayerHealth;
 protected float minPlayerHealth;
 // 约15个变量
 @Override
 protected void onCreate(Bundle savedInstanceState) {
 super.onCreate(savedInstanceState);
 SharedPreferences prefs = this.getSharedPreferences("general_settings", Context.MODE_PRIVATE);
 PlayerName = prefs.getString("PlayerName", null);
 maxPlayerHealth = prefs.getFloat("maxPlayerHealth", 0.0f); // 注：原代码key写错，此处修正
 minPlayerHealth = prefs.getFloat("minPlayerHealth", 0.0f); // 注：原代码key写错，此处修正
 // 其余偏好设置读取逻辑
 }
}

各Activity继承示例：

public class Activity1 extends myPreferences{ }
public class Activity2 extends myPreferences{ }
public class Activity3 extends myPreferences{ }

第二种实现方案 #

在myPreferences中使用静态变量，仅在应用中读取一次SharedPreferences：

public class myPreferences extends Activity{
 protected static String PlayerName;
 protected static float maxPlayerHealth;
 protected static float minPlayerHealth;
 // 约15个变量
 @Override
 protected void onCreate(Bundle savedInstanceState) {
 super.onCreate(savedInstanceState);
 if(PlayerName == null) {
 SharedPreferences prefs = this.getSharedPreferences("general_settings", Context.MODE_PRIVATE);
 PlayerName = prefs.getString("PlayerName", null);
 maxPlayerHealth = prefs.getFloat("maxPlayerHealth", 0.0f); // 注：原代码key写错，此处修正
 minPlayerHealth = prefs.getFloat("minPlayerHealth", 0.0f); // 注：原代码key写错，此处修正
 // 其余偏好设置读取逻辑
 }
 }
}

方案优劣对比与问题解答 #

先直接给结论：第二种方案（静态变量+单次读取）整体更优，但有几个细节需要注意。接下来针对你的问题逐一拆解：

1) 内存使用方面：静态变量会占用更多内存吗？存在内存泄漏风险吗？ #

• 内存占用：刚好相反，第二种方案内存占用更少。静态变量属于类本身，只会在类加载时创建一份；而第一种方案中每个Activity实例都会持有独立的变量副本（15个变量×3个Activity），相当于存了三份重复数据。
• 内存泄漏风险：只要你不在静态变量里持有Context或Activity的引用（你这里只存字符串和基本类型，完全没问题），就不会有泄漏。静态变量的生命周期和应用进程一致，而偏好设置本身就是需要全局共享的数据，这种内存占用是合理的，不属于泄漏。

2) 性能方面：哪种方案性能更优？我认为避免重复读取偏好设置性能会略好。 #

你的判断完全正确，第二种方案性能更优：

• SharedPreferences读取是轻量级IO操作，但多次重复读取（每个Activity onCreate都读一次）还是会产生不必要的开销，尤其是变量数量多达15个时；
• 第二种方案只在第一次创建子类Activity时读取一次，后续所有Activity直接用内存里的静态变量，省去了重复IO和解析的耗时，优势很明显。
• 补充提醒：如果后续偏好设置有更新，你需要手动同步静态变量的值，否则其他Activity会读到旧数据——这是唯一需要额外处理的点。

3) 访问修饰符：应使用private而非protected吗？还是无关紧要？ #

建议用private静态变量，配合public static的getter方法，原因如下：

• 封装性：避免子类直接修改静态变量，防止意外篡改。比如某个子类不小心把PlayerName设为null，会导致后续创建的Activity重新读取偏好，破坏了单次读取的设计；
• 可控性：如果后续要加数据校验、日志记录或者更新同步逻辑，getter方法可以统一处理，不用修改所有子类的代码；
• 如果子类只需要读取不需要修改，完全可以把变量设为private，通过getter暴露。如果确实需要修改，也要通过统一的静态方法来做，同时同步更新到SharedPreferences。

4) 若所有Activity同时处于栈中，变量会被创建三次吗？每个继承myPreferences的Activity各一次？ #

• 第一种方案：是的。每个Activity实例都会创建自己的PlayerName、maxPlayerHealth等成员变量，三个Activity就有三份独立的副本，虽然值相同，但内存里存了三份；
• 第二种方案：不会。静态变量属于myPreferences类，不管创建多少个子类实例，静态变量只会有一份，所有Activity共享这一份数据。

额外优化建议 #

其实更规范的做法是把偏好设置逻辑从Activity基类抽离，单独做一个AppPreferences单例类，比如：

public class AppPreferences {
    private static AppPreferences instance;
    private SharedPreferences prefs;

    private String playerName;
    private float maxPlayerHealth;
    private float minPlayerHealth;

    private AppPreferences(Context context) {
        prefs = context.getApplicationContext().getSharedPreferences("general_settings", Context.MODE_PRIVATE);
        loadPreferences();
    }

    public static synchronized AppPreferences getInstance(Context context) {
        if (instance == null) {
            instance = new AppPreferences(context.getApplicationContext());
        }
        return instance;
    }

    private void loadPreferences() {
        playerName = prefs.getString("PlayerName", null);
        maxPlayerHealth = prefs.getFloat("maxPlayerHealth", 0.0f);
        minPlayerHealth = prefs.getFloat("minPlayerHealth", 0.0f);
        // 其余变量读取
    }

    // Getter方法
    public String getPlayerName() {
        return playerName;
    }

    // 如果需要修改，添加Setter并同步到SharedPreferences
    public void setPlayerName(String playerName) {
        this.playerName = playerName;
        prefs.edit().putString("PlayerName", playerName).apply();
    }
}

这样做的好处：

• 完全解耦，不需要所有Activity继承同一个基类，灵活性更高；
• 单例模式确保只读取一次偏好，同时统一管理数据的读写；
• 使用ApplicationContext彻底避免内存泄漏风险。

内容的提问来源于stack exchange，提问作者user10775950