如何通过Gradle修改Android Flavor应用包名及解决迁移后反序列化问题

这个问题我之前帮不少从Eclipse迁移到AS的开发者解决过，核心原因基本都是序列化类的全限定名或serialVersionUID和新版本不匹配导致的——毕竟Ant的Flavor是复制项目改包名，和AS的Product Flavors架构差异很大。下面给你几个针对性的解决方案：

1. 确保serialVersionUID完全一致 #

Java序列化时，serialVersionUID是判断类兼容性的核心标识：

• 如果旧版本的类没有显式定义这个值，JVM会根据类的结构、包名等自动生成；一旦新版本类的包名或结构变化，自动生成的UID就会和旧版本不一致，直接触发反序列化失败。
• 解决步骤：
  • 先获取旧版本类的serialVersionUID：用JDK自带的serialver命令，把旧版本的class文件拿出来，执行serialver com.oldpackage.YourSerializableClass，得到对应的UID值。
  • 在新版本的序列化类中显式定义完全相同的UID，比如：

    public class YourSerializableClass implements Serializable {
        // 和旧版本类的UID完全一致
        private static final long serialVersionUID = 123456789L;
        
        // 其他字段和方法
    }
    

2. 处理类全限定名不匹配的问题 #

旧Ant方式每个Flavor是独立项目，包名完全独立；而AS的Flavors是同项目下的变体，核心类通常放在main sourceSet中，包名可能和旧版本不一致，这时候序列化对象存储的旧包名类路径会找不到新版本的类：

方案A：保持Flavor包名和旧版本一致 #

如果业务允许，直接在AS的build.gradle中给每个Flavor设置和旧版本完全相同的applicationId，同时确保核心序列化类的包名也和旧版本一致：

android {
    productFlavors {
        flavor1 {
            // 和旧Ant生成的Flavor包名完全一致
            applicationId "com.oldcompany.app.flavor1"
        }
        flavor2 {
            applicationId "com.oldcompany.app.flavor2"
        }
    }
}

方案B：自定义类名映射（无法改包名时） #

如果必须修改包名，自定义ObjectInputStream来将旧包名映射到新包名：

class CustomObjectInputStream extends ObjectInputStream {
    public CustomObjectInputStream(InputStream in) throws IOException {
        super(in);
    }

    @Override
    protected Class<?> resolveClass(ObjectStreamClass desc) throws IOException, ClassNotFoundException {
        String oldClassName = desc.getName();
        // 替换旧包名为新包名，比如把com.oldcompany.app改成com.newcompany.app
        String newClassName = oldClassName.replace("com.oldcompany.app", "com.newcompany.app");
        return Class.forName(newClassName);
    }
}

然后反序列化时使用这个自定义流：

try (CustomObjectInputStream ois = new CustomObjectInputStream(new FileInputStream("your_serialized_data.ser"))) {
    YourSerializableClass obj = (YourSerializableClass) ois.readObject();
    // 处理反序列化后的对象
} catch (Exception e) {
    e.printStackTrace();
}

3. 排查序列化对象中的资源引用问题 #

如果旧版本序列化的对象中包含了Drawable等资源对象（这其实是不推荐的不良实践），新旧版本的资源ID可能不一致，导致反序列化失败：

• 解决方案：避免序列化资源对象，改为序列化资源的名称（比如R.drawable.icon对应的名称字符串"icon"），反序列化时通过getResources().getIdentifier()重新加载资源。

4. 分步测试验证 #

建议找旧版本生成的序列化测试文件，分步验证：

• 先单独测试serialVersionUID是否匹配：临时把新版本类的UID改成旧版本的值，看是否能反序列化。
• 再测试类名映射是否生效：用自定义流测试包名替换是否能找到对应的类。
• 最后检查对象中的字段是否兼容：比如旧版本有某个字段，新版本是否保留了（如果删除了字段，需要用transient标记或者处理字段缺失的情况）。

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