关于前篇文章“存储/读取工具”的补充

详见：

【Unity3D】一个简单的基于反射和XML的存储/读取工具

22年10月29日 03:34

34070

本来搁床上都快烂了，无聊翻了翻其他的Unity存储文章，又发现了很重要的事情。

之前我认为Unity的序列化不支持List<>（看到有篇文章是这样写的)，但是又有一篇文章说Unity可以做到。新看到的文章说的更加详细具体，所以我选择相信后者。

另外，新文章中提到了Unity序列化关于多态的问题，如 基类 a = new 派生类（）这种，序列化和反序列化后得到基类实例，除非基类继承UnityEngine.Object或者Monobehaviour。

我写的工具，按照原理是依赖于给定类的结构的，因此读取的时候要求给定其类型，并且显然是不支持用基类类型去读取派生类或者反过来了。读取时需要给定类型这点用起来可能不太方便，不过比Unity序列化那样还要给基类加上继承才能解决多态问题要好一点。

另外，Unity关于结构体的序列化做得很好，这点属于是薄纱我了。为了让写的工具能和Unity序列化有个区分，我就列个列表吧。

综上，这个工具用起来可能比Unity序列化方便一点（主要是没有标签要求，不需要public或者打上标签），但是上限和性能远比不上Unity序列化。好处是能够尽量减少对源代码的影响（你可以随时换用其他存储方式而不需要改变源代码，不像Unity序列化一样到处需要打标签），并且简单易上手（调用方法，传入实例和文件名就能存储，传入类型和文件名就能读取）。

（11.2编辑）以上对Unity序列化的理解有误。当需要存/读档时，一般只能使用垃圾到不行的JsonUtility（如果使用plasticscm，也可以导入newtonsoft）。这东西甚至不支持可序列化类的数组，难用至极。所以此工具的唯一优点就在于使用方便了。

一句话就是：不需要动脑子，直接保存就行了，省去大部分烦恼。