写Unity数据持久化这一篇酝酿了很久。最近组里做模拟经营类项目存档数据变得越来越复杂从最开始的十几个字段发展到几十个嵌套实体原先那把三板斧完全招架不住了。借着这个项目把Unity里常用的持久化方案重捋了一遍从PlayerPrefs到JSON存档再到SQLite和二进制方案都有涉及这里把完整的思考过程和踩坑记录整理成文给同样在做存档设计的朋友做个参考。1. 先搭一张技术选型地图Unity里到底有几种持久化姿势先说结论Unity没有官方钦定的标准存档方案只有当前条件下最合适的方案。项目里常见的持久化需求其实分好几层选型前必须先搞清楚自己需要的是哪一层。轻量级需求一般只存设置项、音量、画质、玩家ID、几天前的时间戳这类零散KV数据这种直接交给PlayerPrefs底层是注册表、plist或者本地文件一行代码搞定。中等需求是游戏进度存档比如关卡信息、角色属性、背包物品、任务状态这种有成套的结构化数据用JSON序列化后写入本地文件最方便维护。重需求量级再往上走像排行榜数据、聊天记录、用户行为日志动辄几百MB甚至几GB的规模SQLite这类内嵌数据库才是正确方向。除此之外还有一类变种某些竞技游戏为了解决明文存档被修改的问题会改用自定义二进制协议配合校验和加密。这里插一个容易被忽略的维度跨平台。Unity的Application.persistentDataPath在不同平台上指向完全不同的地方我在项目里踩过最早的坑就是这个。编辑器和Windows上它通常指向C:/Users/用户名/AppData/LocalLow/公司名/项目名安卓上指向/data/data/包名/filesiOS上则是App沙盒的Documents目录。写死在代码里的路径切个平台就全废了所以任何时候都不要硬编码路径一律用API去拿。选型没有银弹综合下来的判断标准有三个数据量大小、读写频率、以及是否需要跨端同步。下面的表格是我在实际项目里的经验判断可以直接作为立项时的参考。方案适用数据量单次写入耗时量级跨端同步推荐指数PlayerPrefsKB级几十个Key以内毫秒级不支持只适合设置项JSON到本地文件MB级结构化存档十几毫秒到百毫秒不支持最通用中小项目首选SQLiteGB级检索频繁依赖索引和事务可以配合外部同步大数据量推荐自定义二进制MB级高安全需求毫秒级不支持算法类排行赛常用当初如果不先把这张地图建起来后面很可能把PlayerPrefs塞到爆炸或者反过来用SQLite存三个音频设置参数复杂度白白抬高了几个量级。2. PlayerPrefs的真实调用细节它远没有你想象的那么万能毫不夸张地说PlayerPrefs是Unity里被滥用得最凶的API之一。它确实简单PlayerPrefs.SetInt(Coin, 100)存PlayerPrefs.GetInt(Coin)读零学习成本但代价藏在背后。存储位置上PlayerPrefs在不同平台的实现差异巨大。Windows下它写进Registry安卓下是一个XML文件iOS下是UserDefaults的plist。这带来的第一个坑是数据完全不透明玩家可以在注册表里改你的金币数或者直接编辑XML文件你的存档等于门户大开。第二个坑是性能PlayerPrefs每次调用Set之后并不是立即落盘而是在OnApplicationPause或OnApplicationQuit的时候批量同步如果你在游戏过程中高频调用帧率会出现偶发性卡顿。我曾经在某个原型里用PlayerPrefs每帧记录几十个调试参数结果真机Profile发现StoreValue的调用在GC Alloc里占了不小比例。另一个问题是它只支持int、float、string这几种基本类型。虽然Unity后来加了SetString的JSON技巧可以把任何可序列化对象塞进字符串里再存但本质上中间多了一层序列化和反序列化数据大了以后性能和可维护性都直线下降。那么PlayerPrefs到底该用来干什么我现在的标准很明确只存设置项和低频状态。音量大小、画质等级、语言选择、上次登录时间戳这些用它没问题。游戏进度、玩家角色、背包数据一律不进PlayerPrefs。还有一个操作上的好习惯值得强调写操作前先判空再取值。PlayerPrefs没值的时候GetInt返回0、GetString返回空串有时候0和空串恰好是正常业务状态就会出现无法区分没存过和存的就是0的bug。你要是需要区分这种情况要么初始化时给Key写入一个默认哨兵值要么手持PlayerPrefs.HasKey先判断。// 一个合理使用PlayerPrefs的例子存档最后写入时间 public static void SetLastSaveTime(int unixTs) { PlayerPrefs.SetInt(LastSaveTs, unixTs); PlayerPrefs.Save(); // 强制落盘避免应用被杀丢失 }PlayerPrefs.Save()是个冷门但关键的API它在部分平台上会强制把内存缓存写进磁盘对敏感数据来说值得调用。大体上我对PlayerPrefs的定义就一句话它是一座桥但桥对面不是大路你需要过桥之后赶紧换乘不要在桥上搭房子。3. JSON本地存档的完整实现从JsonUtility到Newtonsoft的跨越绝大多数Unity项目的正式存档表最终都会落到JSON加本地文件这条路上来。原因很简单JSON可读性强便于调试和导出配合UTF-8编码人工排查存档bug时直接拿文本编辑器打开看就行。Unity自带的JsonUtility是个被不少新项目忽视的利器之所以被忽视是因为它有几个明显的坑不支持Dictionary字典不支持多态只能序列化public字段而且null的处理很别扭。但我依然建议中小项目优先考虑它因为它是引擎内置的零依赖序列化速度快在数据量不大时和Newtonsoft.Json的差距可以忽略。如果要序列化Dictionary我推荐的做法是绕一下先把Dictionary转成List结构比如定义一个[Serializable]的KeyValuePair替代类序列化一个List反序列化时再重建Dictionary。这样既绕开了JsonUtility的限制也能保住引擎内置方案的便利。[Serializable] public class SaveEntry { public string key; public int value; public SaveEntry(string k, int v) { key k; value v; } } // 序列化前转换 ListSaveEntry entries new ListSaveEntry(); foreach (var kv in dict) { entries.Add(new SaveEntry(kv.Key, kv.Value)); } string json JsonUtility.ToJson(entries, true);但如果你项目的存档结构复杂、嵌套深、包含多态继承体系建议直接上Newtonsoft.Json。它的用法对写过一点点服务端的我来说简直像回家一样直接JsonConvert.SerializeObject和DeserializeObject能够完美处理Dictionary、Nullable、枚举、多态配合JsonExtensionData还能兼容旧版本存档字段的新增和删除这个特性在做存档版本升级时帮了大忙。这里必须提一个序列化选项的问题。Newtonsoft有一个Formatting.Indented参数做开发阶段我强烈建议开启它会生成带缩进的多行JSON方便在Unity编辑器的Console里直接查看。比如存档长成这样{ Player: { Name: 某玩家, Level: 12, Items: [Apple, Stone] }, IsNewGame: true }一眼就能看出结构排查问题效率极高。而出正式包或者存档体积极端敏感时再关掉缩进压缩体积。这个决策不是技术能力问题纯粹是Debug体验问题。文件IO这块同样有讲究。直接在Application.persistentDataPath目录下写文件用的是File.WriteAllText或者FileStream但这里有个大坑就是异步。移动端上层Unity主线程如果直接做同步IO复杂碎片化的Flash存储会卡顿明显。实测下来一个2MB的JSON存档在低端安卓机上同步写入能卡200毫秒以上这在高频保存的游戏里就是明显掉帧源。所以存档写入的正确姿势是主线程只管把对象序列化成字符串然后交给异步任务去写文件。Unity里可以用async/await也可以用Task.Run不过注意后者在线程池上跑文件流可能会和主线程互抢资源我在项目里用了Unity的NativeArray加JobSystem做大量节点数据写入之前最稳定的方案其实是封装一个FileIO单例public class Saver { private const string FILE_NAME save.json; private string savePath Path.Combine(Application.persistentDataPath, FILE_NAME); public async Task Save(GameData data) { string json JsonConvert.SerializeObject(data, Formatting.Indented); using (var writer new StreamWriter(savePath, false, Encoding.UTF8)) { await writer.WriteAsync(json); } } public async TaskGameData Load() { if (!File.Exists(savePath)) return null; using (var reader new StreamReader(savePath, Encoding.UTF8)) { string json await reader.ReadToEndAsync(); return JsonConvert.DeserializeObjectGameData(json); } } }注意这里写入前没有加密只是先解决读写性能。加密要不要加、加多少后面专门聊。4. 权衡二进制与SQLite当JSON撑不住时应该往哪个方向升级项目推进到中后期JSON方案开始出现两个致命问题第一是存档体积膨胀几千个嵌套对象序列化成长字符串写入读取耗时都跟着涨第二是查询困难存档是一整块整体想取出其中一条玩家交易记录必须把整个存档反序列化一遍再遍历查找这在排行榜、日志这类场景里完全没有效率。第一个方向是自定义二进制。二进制的好处是体积小、写入快、天然具备一定防读效果至少文本编辑器打开是一堆乱码。我用二进制写过一次模拟存档核心思路是把所有数据按固定长度切片头部写版本号和字段数随后每个字段按类型序列化进字节流。public class BinarySaver { public byte[] Serialize(SaveData data) { using (var ms new MemoryStream()) using (var writer new BinaryWriter(ms, Encoding.UTF8)) { writer.Write(data.Version); writer.Write(data.PlayerName); writer.Write(data.Coin); writer.Write(data.KillCount); // 数组长度 writer.Write(data.HeroIds.Length); for (int i 0; i data.HeroIds.Length; i) writer.Write(data.HeroIds[i]); return ms.ToArray(); } } public SaveData Deserialize(byte[] bytes) { using (var ms new MemoryStream(bytes)) using (var reader new BinaryReader(ms, Encoding.UTF8)) { SaveData data new SaveData(); data.Version reader.ReadInt32(); data.PlayerName reader.ReadString(); data.Coin reader.ReadInt32(); data.KillCount reader.ReadInt32(); int count reader.ReadInt32(); data.HeroIds new int[count]; for (int i 0; i count; i) data.HeroIds[i] reader.ReadInt32(); return data; } } }上面这套代码看起来挺清爽但一旦数据结构调整比如新增字段、删除字段、改变字段类型二进制协议的解析逻辑就必须同步更新并且无法向前兼容。这是二进制方案最大的维护成本。所以我的建议是除非你有明确的体积敏感或反作弊需求否则别为了看起来更技术去用二进制JSON加压缩的效果往往更省事。第二个方向是SQLite。Unity接入SQLite需要额外导入动态库比较成熟的方案是Mono.Data.Sqlite配合他人封装好的Sqlite4Unity或自己写一层wrapper。SQLite带来的核心价值是SQL查询能力和事务支持往数据库里插入几千条排行榜数据反序列化只回需要的Top10直接一条SELECT就行比JSON整包解出来再排序快了两个数量级。在Unity里使用SQLite时有个容易忽略的点不要把数据库连接放在主线程频繁打开关闭。正确做法是启动时打开一个连接业务写入统一走事务批量提交。代码层面像这样public class DataAccess { private readonly string dbPath Path.Combine(Application.persistentDataPath, game.sqlite); private SqliteConnection conn; public void Init() { conn new SqliteConnection(Data Source dbPath); conn.Open(); using (var cmd conn.CreateCommand()) { cmd.CommandText CREATE TABLE IF NOT EXISTS T_ITEM(ID INTEGER PRIMARY KEY, ItemName TEXT, Count INTEGER, OwnerID INTEGER); cmd.ExecuteNonQuery(); } } public void BatchInsert(ListItemData items) { using (var tx conn.BeginTransaction()) using (var cmd conn.CreateCommand()) { foreach (var item in items) { cmd.CommandText INSERT INTO T_ITEM (ItemName, Count, OwnerID) VALUES (name, count, owner); cmd.Parameters.AddWithValue(name, item.Name); cmd.Parameters.AddWithValue(count, item.Count); cmd.Parameters.AddWithValue(owner, item.Owner); cmd.ExecuteNonQuery(); } tx.Commit(); } } }SQLite方案也有自己的坑比如主线程和异步线程同时访问同一连接会直接报错所以项目里如果选了它务必要做一个单一连接、统一调度的封装层。我见过有项目在协程和Update里同时开新连接去访问同一个DB文件结果直接锁库表现为随机卡死几秒排查起来比看代码还痛苦。结论很清晰了JSON撑不住的时候先判断瓶颈在哪里——如果瓶颈是每次要全量反序列化、而我只需要一部分数据上SQLite如果瓶颈是文件体积大、写入慢、IO压力高可以考虑二进制或者JSON压缩。二选一别混用架构会清晰很多。5. 存档系统的隔离清理与双缓存机制持久化之外的工程质量写过一段时间存档后会发现一个很有意思的现象存档系统的核心难点根本不在读写而在于版本迁移、脏数据清理、以及写入失败的恢复策略。这一节基于前文所有方案之上聊几个工程层面的通用设计。版本迁移是第一个绕不开的话题。游戏每次发版存档结构几乎都在变最常见的情况是给属性加了新字段比如角色新增了声望值老玩家打开新版本反序列化时DeserializeObjectGameData直接返回null或者默认值轻则显示异常重则存档崩溃。比较稳的做法是给存档对象定义一个Version字段和Migrate()方法每次结构变更就升一次版本号反序列化后立刻检查版本不匹配就按旧版到新版逐级升级public class GameData { public int SaveVersion; public string PlayerName; public int Coin; public int Reputation; public GameData Migrate() { if (SaveVersion 2) { Reputation 0; // 补默认值 SaveVersion 2; } if (SaveVersion 3) { // 例如把装备列表从旧字段迁移到新字段 SaveVersion 3; } return this; } }配合上面的JsonExtensionData字段可以收集反序列化时出现的未知老字段不至于直接抛异常这在做平滑升级时能少掉不少线上告警。双缓存机制是另一个重要实践。写存档时永远不要直接改主存档文件先写save.json.tmp临时副本写成功后再File.Copy覆盖主存档。为什么这么做因为如果写入中途崩溃、断电、App被系统杀掉主文件可能只写了一半下次启动读到一个残缺JSON整个存档直接废了。临时副本加原子重命名的策略可以把这个风险降到几乎为零。我在项目里甚至进一步做了三份冗余save.json.bak留上一份可用存档万一主存档和临时副本同时损坏回退到bak玩家损失只在一小段进度。防篡改校验就放在这个位置一起做。常见做法是存档内容之外额外存一个CheckSum字段用MD5或CRC32对序列化后的字符串做哈希。更稳妥一些是引入加密哈希比如HMAC-SHA256需要把密钥藏在代码里而非客户端资源里。老实说纯客户端方案对抗内存修改器和主动外挂都效果有限但对抗玩家直接改文件这类青铜段位问题已经绰绰有余。需要明确的是任何数据校验都不能影响主流程性能所以这笔开销放在后台异步算。最后是脏标记和延迟写。为了减少IO次数我习惯在内存里维护一个DirtyFlag任何修改数据的操作只置位不做文件IO。每隔固定时间或者关键节点切场景、弹结算、点保存按钮检查Flag有脏数据才真正调用写入流程。实测下来玩家在一场战斗里的死亡、拾取、扣血、状态变化——几百个小修改最终只落盘一次IO压力骤减体验还更稳定。6. 一条最被低估的护城河把持久化接口做成多层缓存上面聊的全是具体方案最后想分享一个我在做框架时坚持了很久的设计理念给持久化系统加一层内存缓存让读写全部先经过缓存层而不是直接落盘。很多团队在写存档时直接调用File.WriteAllText表面上看很直观但耦合性极强。一旦你需要改方案——比如从JSON切换成SQLite——所有调用点都要跟着改。正确的做法是先定义一个IArchive接口public interface IArchive { void SaveGame(GameData data); GameData LoadGame(); void SaveSetting(string key, string value); string LoadSetting(string key); }然后实现一个MemoryCacheArchive内部维护一个字典缓存所有数据调用时先查缓存缓存没有才去底层读文件或读数据库同时启动一个后台协程定期将缓存写回。这一层带来的直接收益是游戏运行时的读写请求几乎全部在内存中完成磁盘IO被压缩到一个可控的频率并且底层方案随意替换而不影响上层逻辑。更妙的是它可以配合事件系统做自动保存触发器。比如项目里设定信用点、同伴的好感度、章节序数这三个是玩家最敏感的数据一旦它们变化且满足时间间隔10秒就自动走缓存层写回。玩家体验是存档在我无感知的时候完成技术上的IO开销却被平滑稀释掉。这个模式在中小项目里也许被视为过度设计但当你接手那种维护到后期、到处是直接访问磁盘、动不动改存档导致存档崩溃的项目时就会明白内存缓存层和IArchive接口这两层薄薄的封装是支撑一个游戏活过三年两年不断发版本的生命线。所以最后我的总结不打算给什么最终方案ABC就留一个观点Unity数据持久化这条路方案本身不是壁垒壁垒在于你为方案预留的扩展空间以及你是否在动手写第一行代码之前把上面这几个关键问题都问过自己一遍。