启用代码混淆后读取旧版本SharedPreferences时App崩溃求助

核心原因 #

你遇到的问题本质是混淆改变了代码中与SharedPreferences交互的关键标识（比如实体类字段名、反射用到的类/字段名称），导致新版本混淆后的代码无法匹配旧版本未混淆时写入的SP数据结构，进而读取失败抛出NullPointerException。

具体解决方案 #

1. 保留SharedPreferences相关的实体类不被混淆 #

如果你是把自定义实体类（比如UserSettings）通过序列化（比如Gson、Serializable）存入SP，必须在ProGuard规则中保留这些类的字段名：

# 保留自定义偏好设置实体类的所有字段和方法
-keep class com.yourpackage.models.UserSettings {
    *;
}

# 如果用Gson序列化，补充Gson相关混淆规则
-keepattributes Signature
-keepattributes *Annotation*
-keep class com.google.gson.** { *; }
-keep class sun.misc.Unsafe { *; }
-keep class com.google.gson.stream.** { *; }

这样混淆后的代码依然能使用原字段名解析旧版本存入的序列化数据。

2. 固定SharedPreferences的键名，避免依赖反射/字段名 #

如果你的SP键名是通过反射获取类字段名生成的（比如Field.getName()），混淆后字段名会变成a、b这类无意义名称，导致新版本找不到旧版本的键。解决办法：

• 把SP的键名定义为常量字符串，比如：

public class PrefConstants {
    public static final String KEY_USER_NAME = "user_name";
    public static final String KEY_AUTO_LOGIN = "auto_login";
}

• 在ProGuard中保留这个常量类不被混淆：

-keep class com.yourpackage.utils.PrefConstants {
    public static final java.lang.String *;
}

这样新旧版本用的键名完全一致，不会因为混淆出现不匹配。

3. 兼容旧数据的过渡方案 #

如果已经发布了混淆版本且用户出现问题，可以在代码中做兼容处理：

• 先尝试用混淆后的键名读取，如果返回null，再尝试用旧的未混淆键名读取；
• 读取到旧数据后，立即用新的键名重新写入，后续只用新键名操作。
  示例代码：

SharedPreferences sp = getSharedPreferences("user_prefs", MODE_PRIVATE);
String userName = sp.getString("a", null); // 混淆后的键名
if (userName == null) {
    userName = sp.getString("userName", null); // 旧版本未混淆的键名
    if (userName != null) {
        // 写入新键名，完成过渡
        sp.edit().putString("a", userName).apply();
    }
}

这个方法需要你明确旧版本的键名，适合临时过渡修复。

4. 保留调试信息，方便定位问题 #

即使开启混淆，也可以在ProGuard中保留必要的调试信息，让错误日志更有价值：

# 保留行号信息，崩溃日志会显示具体行号
-keepattributes SourceFile,LineNumberTable
# 混淆后用原类名的缩写，而非完全无意义的名称
-renamesourcefileattribute SourceFile

这样即使混淆了，崩溃日志也能显示具体的类和行号，帮助你快速定位是哪段读取SP的代码出了问题。

验证建议 #

• 测试时先安装未混淆的旧版本，写入测试数据；
• 再安装开启混淆的新版本，验证是否能正常读取旧数据；
• 如果依然有问题，结合保留的调试日志，排查是键名不匹配还是实体类序列化失败。

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