【转载】http://blog.csdn.net/a237653639/article/details/50076755
游戏存档
在Unity中游戏存档有如下四种方式：
- PlayerPrefs
- c#序列化
- XML序列化
- Json
游戏存档是老大之前吩咐要做的，一开始我问可以用PlayerPrefs不呢，锐哥老大回答说不可以，用Unity自带的会有很多的限制。那好吧，为了自由故，我就只好研究另外的三种了。于是就上网去查别人是怎么做存档的（我有个习惯，如果自己是第一次做，我就会先去看别人是怎样做的），很容易就找到了一位大大的博客，一试之下，果然是棒棒的。于是第二天我就喜滋滋地去交差了。在锐哥的一番审视下，对我写的存档提出了几点意见和要求：
1.游戏版本的升级
2.玩家有多个存档
3.玩家破坏存档的情况
4.注释太多和把玩家类再包一层等编码的细节的建议
既然有新需求了，那咱就再加把劲继续干活完成任务吧！于是经过一天和晚上到凌晨的折腾，终于把需求2实现了，需求3也容易，用try catch，只要解析不正确则认为存档被破坏。第四个也改了。而需求1的好像用这个代码什么也不做也实现了。非常完美！内心激动的跟主城说这些功能都实现啦！（如果事情就到这里，也就没有下文了。）而后锐哥说你用的是XML么。我说是的。这时一旁的皮皮说，你咋不用Json呢，好用又轻量。既然代码还可以更好，那好吧，我就再研究研究~~毕竟程序员对于优化都是有情结的=。=而后我采用改了c#序列化方式，既不用XML，也不用Json，而且一序列化相当于也加密了，这么多的优点！过了一个月后，直到今天，我才发现用C#序列化的缺点，然后果断放弃了，最后用的是Json。
下面说一说每个的优点与缺点：
- PlayerPrefs
优点：上手简单，存储方便，不用考虑内部实现，适合做小游戏的数据存档（网上一搜，发现很多网友都是用的这种方式。
缺点：只支持基本数据类型，无法存储一个类，数组，集合，字典等。不过肯定是可以用一个框架来实现自动赋值的，只是感觉更麻烦一点。
- c#序列化
优点：除了静态类型和抽象类型以及类必须标记为[Serializable]的（其实这个不是什么问题了），其他的都可以被序列化：类，数组，集合，字典，类及其子类等。而且序列化之后你也看不懂是什么鬼（哈哈）~~。
缺点：
1.不会调用要序列化类的构造函数（当然可以通过实现ISerializable和IDeserializationCallback接口来实现在序列化和反序列化之前对数据的处理，所以这个不是我放弃它的重点）。
2.在升级版本后，新增一个字段也只是采用系统默认值，而不是我在类中直接赋的值，这导致我需要自己去比较当前版本和之前的每一个版本的版本号，然后再挨个处理每个以前版本的升级，就意味着当前是第N次更新，我要做N-1次if判断并手动赋值（这段话是结合自己的项目记录的，当然也就我看得懂了^^）。
3.而让我放弃它的最终原因是，在升级版本后，如果删除了之前的一个字段，则无法正确解析（反序列化），这种情况就最不能容忍了。我不敢冒这样的风险，保证以后的版本不会删除其中一个字段。或许你会想到“你可以保留啊，然后不管它就是了”，不过鉴于我有个超追求完美的boss，只好放弃。毕竟这还不如XML。
- XML序列化
优点： 1.序列化出来的数据直观，可以序列化类和类中的对象。 2.升级版本后，如果新增了字段，则自动采用你在类中赋给该变量的值。 3.升级版本后，如果删除了之前的字段，则自动忽略之前的字段，而不会像c#序列化一样报错，
缺点： 1.不能序列化字典，二维数组以上的数据 2.比Json更占空间，且引入的dll也更大
- Json(LitJson)
优点： 1.简单轻量 2.可以满足你要序列化的几乎任何类型数据（除了float必须用double来存） 3.如果要升级版本，可以任意删除之前的字段而不会出现不能解析的情况；可以新增字段且采用你在类中直接赋的值（不用像c#序列化那样手动赋值了）。
缺点： 1.相对PlayerPrefs来说，引入了一个50kb左右的dll。 2.不能序列化float类型。3.不支持更改字段名。如果更改了，就相当于是两个操作，即删除之前的并新增加一个（这一点很重要）。
以上是我今天辛勤耕耘的成果，白天耕种，夜晚收割。如果不写下来，今天我肯定就白搞了。