Unity二进制存储实战：从序列化到存档加密与性能优化

做Unity项目做到中期以后，大多数开发者都会遇到一个绕不开的问题：存档到底用什么格式存？PlayerPrefs存键值对太简陋，JSON明文可读但臃肿，XML更别提了。我自己早期做过一个Roguelike项目，存档里要放几百个地牢房间的布局数据、敌人状态、物品掉落表，用JSON序列化下来随便就是十几MB，读取时GC压力大得吓人，手机发烫、加载卡顿。后来痛定思痛，全面切到二进制存储，存档体积直接缩到原来的十分之一，读档速度从秒级降到毫秒级。这篇随笔就把我折腾二进制存储的完整经验和踩过的坑整理出来，给正在做存档系统或者需要高性能数据落地的朋友做一个参考。

二进制存储听起来像是底层技术，实际用起来并不复杂，核心就是三件事：把对象变成字节、把字节写进文件、以及从文件读回字节还原对象。难点在于中间的细节处理，类型变化、平台差异、加密需求、异常恢复，任何一个环节没兜住，玩家就可能在读档时直接闪退，或者更糟——坏档。这篇内容适合正在做Unity存档模块的开发者、想优化数据读写性能的客户端程序，以及准备面试时被问“存档方案怎么选”的朋友。

1. 为什么折腾了一圈最后选了二进制存储

1.1 PlayerPrefs、JSON、XML的痛点

先聊聊我一开始为什么没继续用那些“省事”的方案。PlayerPrefs定位就是存小量偏好设置，我在项目里用它存过复杂存档，结果就是痛不欲生。它本质是键值对，Value是字符串，你要是把一整个对象塞进去，还得先序列化成字符串，取出来再反序列化，绕了一圈不说，PlayerPrefs在不同平台上的存储机制完全不一样，Windows上藏注册表里，macOS上放plist，Android是XML文件，iOS是NSUserDefaults。数据量一大，写入性能断崖式下跌，而且没有任何事务保护，写一半崩了，存档直接报废。

JSON和XML作为文本格式，最大的问题是体积和解析效率。Unity官方自带的JsonUtility用起来确实方便，但它的局限性也很明显：不支持Dictionary，不支持多态，不支持继承字段序列化。我当初那个地牢项目是用Newtonsoft.Json做序列化的，功能是强了，但跑在低端Android机上，反序列化几百KB的存档要花一两秒，而且会产生大量临时字符串，触发GC频繁卡顿。XML的标签冗余就更严重了，同样的数据量体积是二进制的五到十倍，网络传输和本地读写都亏。

1.2 二进制方案的核心优势在哪里

二进制存储为什么强？因为它是直接面向内存结构的存储方式，不需要文本解析的过程。字节数组还原成对象时，本质是一次内存拷贝加少量转换，性能天生就比文本解析高一个量级。体积方面，一个int在JSON里可能是“12345”五个字节，二进制里就是固定4个字节；浮点在二进制的精度问题也更好处理，直接按IEEE 754标准写入4字节或8字节即可。

还有一点用户体验上的提升：明文存档玩家用记事本一打开就能改，什么金币数、血量上限一目了然，这在单机游戏里基本等于没有安全边界。二进制存档至少能挡住99%的普通玩家修改，虽然防不住刻意逆向的，但门槛高了很多。对联网游戏来说，存档数据用二进制压缩加加密后，再配合校验码，被篡改的概率会大大降低。

1.3 什么样的项目最适合上二进制存储

不是所有项目都需要二进制存储。我的经验是，满足以下任意两个条件，就值得切：

• 单个存档文件预期超过100KB，或存档总数据量大
• 存档更新频率高，比如每30秒自动存一次
• 存档内容包含大量数组、容器类数据
• 有防止玩家改存档的需求（哪怕只是防小白）
• 目标平台包含移动端，对IO性能和内存占用敏感

反过来，如果只是存音量设置、画质选项、角色ID这些零散小数据，PlayerPrefs仍然是够用的，没必要为复杂度买单。项目里最终是组合方案：设置类数据走PlayerPrefs，核心游戏进度走二进制文件，这样各取所需。

2. 二进制读写核心API选型和原理补课

2.1 BinaryWriter和BinaryReader：最基础的积木

Unity里做二进制文件读写，最常用的是System.IO.BinaryWriter和System.IO.BinaryReader这对搭档。它们本质上是给FileStream套了一层“类型化”包装：往文件里写一个int，底层就是按固定字节序写入4个字节；写一个float就是写入4字节的IEEE 754表示。

看一个最简单的写入示例：

csharp复制using System.IO;

public static class BinarySaver
{
    public static void SaveInt(string path, int value)
    {
        using (FileStream fs = new FileStream(path, FileMode.Create, FileAccess.Write))
        using (BinaryWriter writer = new BinaryWriter(fs))
        {
            writer.Write(value);
        }
    }

    public static int LoadInt(string path)
    {
        using (FileStream fs = new FileStream(path, FileMode.Open, FileAccess.Read))
        using (BinaryReader reader = new BinaryReader(fs))
        {
            return reader.ReadInt32();
        }
    }
}

这段代码看着简单，里面其实有不少讲究。using关键字保证了FileStream和BinaryWriter在异常时也能正确释放，这在反复写入存档的场景里非常重要，文件句柄泄漏会导致后续写入失败。FileMode.Create会直接覆盖已有文件，适合写存档；读的时候用FileMode.Open，文件不存在时会抛异常，需要提前判断File.Exists。

BinaryWriter支持直接写入几乎所有基本类型：Write(int)、Write(float)、Write(string)、Write(bool)、Write(byte[])等。字符串的写入则体现了两种写法的差异，BinaryWriter默认使用UTF-8编码，并在字符串前面写一个7-bit长度前缀，读取时会自动按这个长度还原，不用自己在数据里维护长度字段，这对可变长度的数据非常友好。

2.2 字符串编码是第一个大坑

很多新手写二进制文件时，容易自己踩字符串编码的坑。比如直接用File.WriteAllBytes把一个UTF-8编码的字符串转成字节写进去，读的时候用Encoding.ASCII.GetString还原，结果中文全变成问号。就是因为ASCII编码表只覆盖了128个字符，中文UTF-8编码下至少占3字节，ASCII无法解析。

BinaryWriter和BinaryReader默认就是UTF-8编码读写字符串，所以中文不会有问题。但如果你需要自定义二进制格式，比如为了兼容已有的数据结构，建议始终明确用Encoding.UTF8来转换字符串和字节数组，别依赖平台的默认编码，那在不同操作系统上结果可能完全不同。

2.3 BinaryFormatter：能不用就别用

很多老教程会教你用BinaryFormatter.Serialize(stream, data)这样一行代码完成对象序列化，确实方便，但我在实际项目中基本不推荐了。原因有几层：

第一，BinaryFormatter依赖CLR类型元数据，序列化结果里会带上完整的程序集名和类型名。项目升级、类名改名、命名空间调整都会导致反序列化失败。第二，IL2CPP打包后在AOT（提前编译）环境下，BinaryFormatter经常会出现“Unable to load DLL 'slua'”这类奇怪的报错，本质上是因为AOT裁剪掉了反射所需的元数据，导致反序列化找不到对应类型。第三，Unity官方和.NET团队都已经明确把BinaryFormatter标记为不安全API，新项目里用它，等于把后续维护的坑提前埋好了。

那什么时候还需要了解它？接手老项目时，如果项目里现有存档就是用BinaryFormatter写的，那至少得能看懂并迁移处理。但新代码里写二进制存档，我建议要么手写字段读写，要么用更适合Unity的方案，比如Google的Protobuf或者MessagePack。

2.4 手动字段拼接和序列化库怎么选

手写字段读写，最笨也最稳。给每个存档类写一个Save(BinaryWriter writer)和Load(BinaryReader reader)方法，字段按顺序写入和读取，逻辑完全可控。缺点是字段一多，方法体就很长，而且增加字段时得维护版本迁移。适合存档结构稳定的项目。

如果想兼顾灵活性和性能，现代Unity项目我会优先推荐MessagePack-CSharp。它的序列化速度比BinaryFormatter快很多倍，生成的结果也比JSON小至少一半。还有代码生成器，可以提前生成序列化代码，IL2CPP兼容性也好。Protobuf-net也可以，但它对Unity的版本兼容和AOT支持略折腾。如果项目里已经用了Addressables这类资源管理，那数据文件也可以直接按二进制TextAsset放在Addressables里下发，读取时用LoadAssetAsync<TextAsset>拿到字节数组，整体流程非常顺。

3. 设计一套能扛住生产环境的二进制存档系统

3.1 存档结构设计：从单一对象到分段布局

拿一个实际的RPG游戏存档来举例。一个典型存档包含以下数据：

• 玩家元信息：ID、名字、等级、经验值
• 背包数据：物品ID列表、数量、装备槽位
• 世界状态：当前关卡、已解锁节点、地牢房间布局
• 时间信息：创建时间、最后保存时间、累计游戏时长
• 校验信息：版本号、校验和

如果只是简单把整个对象序列化成一个文件，后续每次加新功能都要处理兼容问题。我的做法是把存档组织成“文件头 + 数据段”的结构：

code复制文件头（固定长度）
- 魔数 Magic Number（4字节）：0x5A5A5A5A，用来确认这是本游戏存栏
- 版本号 Version（4字节）：存档结构版本，每次新增字段就+1
- 数据长度 DataLength（4字节）：数据段总字节数
- 校验和 Checksum（4字节）：CRC32或MD5的散列值

数据段（变长）
- 玩家数据（自定义序列化）
- 背包数据（自定义序列化）
- 世界状态（自定义序列化）

这样设计的好处是运行时可以先读文件头，快速验证版本、长度、校验，然后决定是否继续解析数据段。版本不对时可以直接提示玩家“存档版本过旧”，避免反序列化过程中间崩溃。

3.2 手写一个支持版本迁移的存档类

下面给一个可以直接抄作业的轻量实现。先定义存档数据类：

csharp复制using System;
using System.IO;

[Serializable]
public class SaveData
{
    public int version = 1;
    public string playerName;
    public int playerLevel;
    public long exp;
    public int[] inventoryItems;
    public int[] inventoryCounts;
    public int currentLevel;
    public long saveTimestamp;

    // 序列化：按固定顺序写字段
    public void Serialize(BinaryWriter writer)
    {
        writer.Write(version);
        writer.Write(playerName);
        writer.Write(playerLevel);
        writer.Write(exp);
        
        // 数组先写长度再写元素
        writer.Write(inventoryItems.Length);
        for (int i = 0; i < inventoryItems.Length; i++)
        {
            writer.Write(inventoryItems[i]);
        }
        // 数量数组同理
        writer.Write(inventoryCounts.Length);
        for (int i = 0; i < inventoryCounts.Length; i++)
        {
            writer.Write(inventoryCounts[i]);
        }

        writer.Write(currentLevel);
        writer.Write(saveTimestamp);
    }

    // 反序列化：按相同顺序读字段
    public static SaveData Deserialize(BinaryReader reader)
    {
        SaveData data = new SaveData();
        int saveVersion = reader.ReadInt32();

        // 根据版本决定读取逻辑
        data.version = saveVersion;
        data.playerName = reader.ReadString();
        data.playerLevel = reader.ReadInt32();
        data.exp = reader.ReadInt64();

        int invCount = reader.ReadInt32();
        data.inventoryItems = new int[invCount];
        for (int i = 0; i < invCount; i++)
        {
            data.inventoryItems[i] = reader.ReadInt32();
        }

        int countSize = reader.ReadInt32();
        data.inventoryCounts = new int[countSize];
        for (int i = 0; i < countSize; i++)
        {
            data.inventoryCounts[i] = reader.ReadInt32();
        }

        data.currentLevel = reader.ReadInt32();
        data.saveTimestamp = reader.ReadInt64();
        return data;
    }
}

注意一个关键点：数组的长度字段必须先写。读的时候先读长度，再根据长度循环读取每个元素，这样才能确定要循环多少次。所有引用类型字段在写之前都要保证非null，否则会抛NullReferenceException。我在项目里会额外封装一个SafeWriteIntArray方法，写入前判断数组是否为null，为null时写长度0，读取时也做同样处理，这样老存档某个数组缺失也不会导致整个读档流程崩溃。

3.3 文件写入策略：临时文件、双缓冲和原子性

直接覆盖存档文件在真实项目里是灾难级的隐患。如果游戏在写入过程中崩溃，正写到一半的存档文件就损坏了。更稳妥的做法是“临时文件 + 原子替换”。

写入流程一般是这样：

1. 把数据序列化到内存流MemoryStream
2. 将内存流的字节数组先写到save.tmp临时文件
3. Flush确保写入物理磁盘
4. 用临时文件替换正式存档文件（File.Replace或先删后移）

具体示例：

csharp复制public static void WriteAtomic(string savePath, byte[] data)
{
    string tmpPath = savePath + ".tmp";
    using (FileStream fs = new FileStream(tmpPath, FileMode.Create, FileAccess.Write))
    {
        fs.Write(data, 0, data.Length);
        fs.Flush(true); // 强制写入磁盘，避免操作系统缓存导致丢数据
    }
    File.Replace(tmpPath, savePath, savePath + ".bak");
}

File.Flush(true)的参数表示同时刷新技术设备缓冲区，不是所有平台都支持，但在Windows上实测有效。移动端Android上File.Replace可能不可用，那就用File.Delete后File.Move。多一步删除老文件，如果删除后移动前崩溃，最多是丢一个临时文件，老的“半损坏”存档还是能恢复的。另外我还习惯保留一份.bak备份文件，新文件写入成功后才会覆盖备份，这样玩家手里永远有一个可用回退存档。

3.4 加一层轻量加密和校验

二进制只是防小白，真正不想让人改存档或者防止坏档蔓延，还要加校验。我常用的方案是：

• 写入时对整个数据段的字节数组计算CRC32或MD5值，存入文件头的Checksum字段
• 读取时先重新计算数据段的校验值，跟文件头里的对比，不一致就判定为损坏
• 在写入字节数组前，对每个字节做一次异或加密，密钥保存在客户端代码里

异或加密实现非常简单：

csharp复制public static byte[] XorEncrypt(byte[] data, byte key)
{
    byte[] result = new byte[data.Length];
    for (int i = 0; i < data.Length; i++)
    {
        result[i] = (byte)(data[i] ^ key);
    }
    return result;
}

更安全一点的做法是用AES，但Unity端做AES要引入System.Security.Cryptography，WebGL和IL2CPP下运行时有兼容性风险。如果游戏不是强竞技或者数值敏感类型，异或加密加混淆已经够挡普通玩家了。真需要强保护的话，核心数值一般都不落本地，而是由服务器计算，本地存档只存战斗之外的展示数据。

3.5 用二进制存储扩展数据：技能树、任务列表、地图布局

上面只是基础存档，实际上二进制存储最爽的运用场景是复杂结构的数据。

比如技能树：每个技能有ID、等级、解锁状态、冷却配置。传统JSON会写成冗长的嵌套对象，二进制里可以紧凑地写成：技能数量 + 循环写入每个技能的ID(int)、等级(int)、解锁状态(bool)。再比如地牢地图布局，几百个房间分别有位置坐标、类型、连通的邻接房间索引，二进制存法就是每个房间6个int连续排列，一下把文本几MB的数据压到几十KB。

我在地牢项目里就是这种做法。地图生成完以后，用二进制字节数组存到存档里，玩家中断后重开，地图布局、物品掉落、已探索状态全都能精确还原。地图数据加上种子值，甚至可以只存房间数量、种子、玩家操作轨迹，打开时再按种子重新生成一遍，这样数据量更小，但确定性要求高，属于进阶玩法了。

4. 常见问题与排查技巧实录

4.1 反序列化报错：文件格式无效或者长度不够

这类报错90%是因为写入和读取的字段顺序不一致，或者类型不一致。解决办法是先检查两段代码中所有Write和Read调用的顺序，逐一对照。另一类原因是版本兼容问题，老存档的字段数量跟新代码对不上。我维护的存档在每次新增字段时，都会将version号+1，读取时根据版本号走不同分支，比如if (saveVersion <= 3) { 读取旧格式 } else { 读取新格式 }。千万别试图让所有版本都码进一段“万能读取”逻辑，那只会让代码越改越乱。

4.2 IL2CPP打包后读档崩溃或者DLL加载失败

前面提到过BinaryFormatter在IL2CPP下的坑，补充一个排查思路。如果打包后报类似Unhandled Exception: System.Reflection.TargetInvocationException或者跟DLL加载相关的异常，最好先确认是不是用了BinaryFormatter。Unity的IL2CPP会把C#代码转成C++再编译，反射和动态生成代码的路径受限很多，能提前生成序列化代码的方案（MessagePack的Source Generator）是首选，运行时不依赖反射。

4.3 存档文件越来越大，读写越来越慢

存档变大最常见的原因是把临时数据也存进去了。比如对象池里所有实例的状态、UI相关的临时值、缓存列表全部塞进了存档。二进制的效率优势是建立在“该存的数据才存”的前提上的。我在项目里对存档内容做了白名单制度，只有标记了[SaveField]的字段才允许进入序列化流程，其它的一律不存。

另一个原因是频繁改写同一个大文件造成的文件碎片，这在机械硬盘上不明显，但有些嵌入式设备和部分Android存储会有影响。做法是定期（比如每隔几天或每次大版本升级时）做一次存档全量重写，相当于“碎片整理”。

4.4 存档损坏的兜底方案

无论怎么防护，存档损坏在真实环境里防不胜防。玩家手机存储空间不足、系统后台杀掉进程、磁盘读写异常，都可能导致存档不完整。所以我在正式项目里做了三层兜底：

• 层级一：文件头Checksum校验，不匹配就提示损坏
• 层级二：自动尝试恢复.bak备份文件
• 层级三：备份也没了，至少保证游戏能新建存档走新手流程，不让玩家卡死在加载界面

另外，写存档的时机也很重要。不要在玩家每做一步操作就立刻写，会加重闪存磨损；不要在场景切换中间写，如果游戏正好在加载场景时崩溃，很可能写一半。推荐的做法是：在关键节点（完成副本、升级、退出游戏前）触发一次全量存档，日常每30秒到60秒在后台线程做一次自动保存，但自动保存和手动保存要使用不同的临时文件名，避免相互覆盖。

4.5 Unity版本与平台差异避坑指南

不同Unity版本和不同平台对文件IO的支持有细微差别，我踩过几次坑后发现最强兼容的组合是：

• 存档目录要用Application.persistentDataPath，不要用Application.dataPath。dataPath在Windows里是项目目录，在Android里是压缩包内部，只读区域，写入直接失败。
• 涉及中文文件名或者玩家名字里带特殊字符时，路径处理要用统一的编码，最好全部改用英文字符做文件名，玩家数据存到文件里面去。
• WebGL平台的存档没有文件系统，常见做法是用PlayerPrefs做桥梁，把二进制字节转成Base64字符串存进去，虽然体积膨胀约三分之一，但好歹能用。真要上IndexedDB直接操作，得写js插件互操作，成本比较高。
• iOS平台的File.Replace行为跟Windows不同，有时候会抛异常，所以平台判断分支要写好。

4.6 工具与排查：十六进制查看器和打点日志

最后分享一个调试利器：十六进制查看器。写二进制存档的时候，强烈建议在编辑器模式下加一个“导出Hex View”的调试按钮，把生成的存档文件字节内容输出成十六进制字符串，配合Log逐字段验证写入顺序是否正确。我一般会在Editor脚本里做这件事，比直接用人眼看二进制文件高效得多。

排查读档问题时，也可以先在关键代码路径上打日志，记录读取到多少字节、解析到哪个字段。这样一旦出问题，看到日志就能定位是玩家数据段崩的还是世界状态段崩的，不用从头到尾查一遍。

5. 存档系统后续还可以扩展的方向

这套二进制存储的基础打好了，后续扩展其实很方便。比如存档云同步，把序列化好的字节数组用UnityWebRequest上传到后端，下载时直接拉字节流反序列化，不用走文本转义和解析的弯路。再比如给存档加密算法的密钥做动态变化，每次版本更新时用不同的异或密钥，老存档要在加载时做一次密钥迁移。还有就是把数据分段独立存储，玩家数据高频更新只写玩家段，世界地图低频更新单独维护，能大幅减少写盘频率和数据损坏概率。

我现在做项目标配就是这套“文件头 + 数据段 + 校验 + 临时文件替换”的二进制存档方案，从单机Roguelike到轻度联网卡牌都适用。真要说的话，二进制存储的门槛不在技术实现，而在你没有踩过那些坑之前，很难凭空想到版本迁移和原子写入这些细节。希望这篇随笔能帮你把坑提前填上，省下来的时间多琢磨一下游戏玩法本身。