Android加密对象序列化问题：无法从文件加载数据

嘿，别担心，首次发帖踩坑太正常啦～针对你遇到的密封类序列化加载问题，结合Android平台的特性，我整理了几个核心排查方向和解决方案：

首先得明确：Android上的Serializable和桌面Java逻辑基本一致，但Android对序列化兼容性要求更苛刻——比如必须显式声明serialVersionUID，否则系统自动生成的数值可能因设备、Android版本不同导致反序列化直接失败，这也是很多旧帖子反复强调但容易被忽略的点。

另外，要是你用了Android推荐的Parcelable，可得注意：它是专为跨进程通信优化的，完全不适合用来持久化到文件！硬用的话，类结构稍有变化就会彻底解析失败，这和桌面Java序列化是完全两套逻辑。

1. 确认序列化方式适配持久化场景

   • 如果你用的是Serializable：
     • 密封类及其所有子类必须显式声明serialVersionUID，示例如下：

       sealed class EncryptedVolume : Serializable {
           companion object {
               private const val serialVersionUID: Long = 123456789L
           }
           data class SingleFile(val file: File) : EncryptedVolume() {
               companion object {
                   private const val serialVersionUID: Long = 987654321L
               }
           }
           data class MultiFile(val files: Array<File>) : EncryptedVolume() {
               companion object {
                   private const val serialVersionUID: Long = 135792468L
               }
               // 注意：Array类型在Serializable中需重写equals和hashCode，否则反序列化后判等会异常
               override fun equals(other: Any?): Boolean {
                   if (this === other) return true
                   if (javaClass != other?.javaClass) return false
                   other as MultiFile
                   if (!files.contentEquals(other.files)) return false
                   return true
               }
               override fun hashCode(): Int {
                   return files.contentHashCode()
               }
           }
       }
       

     • 重点提醒：File对象序列化的只是路径信息，不是文件实际内容！如果你想序列化文件数据，得先把内容读成ByteArray再存入对象。
   • 要是误把Parcelable用来持久化文件：赶紧换成Serializable或者Gson/Moshi这类JSON序列化库，别在IPC专用的API上硬套持久化场景。

2. 文件IO操作的权限与流处理检查

   • Android 10+的文件权限限制很严：不能直接访问外部存储的任意路径，建议用应用私有目录（context.filesDir/context.cacheDir）或者MediaStore，不然哪怕文件创建成功，加载时也会因权限不足读不到内容。
   • 序列化/反序列化的IO流必须确保正确关闭，推荐用try-with-resources包裹，避免流未关闭导致文件内容不完整：

     // 序列化到文件
     fun saveVolume(volume: EncryptedVolume, file: File) {
         ObjectOutputStream(FileOutputStream(file)).use { outputStream ->
             outputStream.writeObject(volume)
         }
     }
     // 从文件加载
     fun loadVolume(file: File): EncryptedVolume? {
         return try {
             ObjectInputStream(FileInputStream(file)).use { inputStream ->
                 inputStream.readObject() as EncryptedVolume
             }
         } catch (e: Exception) {
             e.printStackTrace()
             null
         }
     }
     

3. 密封类的序列化兼容性维护

   • 密封类的子类如果新增、删除，或者字段有变化，必须同步更新对应的serialVersionUID，否则反序列化会抛出InvalidClassException。
   • 确保所有密封类子类都实现了Serializable接口，不能有漏网的非序列化子类。

要是Serializable的兼容性问题太头疼，推荐用Gson或Moshi这类JSON库来序列化密封类，它们对Android适配更好，还方便调试：

• 以Gson为例，搭配Kotlin扩展可以自动处理密封类：

  val gson = GsonBuilder().registerTypeAdapterFactory(KotlinAdapterFactory()).create()
  // 序列化
  val json = gson.toJson(volume)
  FileWriter(file).use { it.write(json) }
  // 反序列化
  val volume = gson.fromJson(FileReader(file), EncryptedVolume::class.java)
  

  这种方式生成的是可读的JSON内容，调试起来一目了然，类结构变化时还能通过@SerializedName注解兼容旧版本数据。

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