Unity3D SQLiteDB与LiteDB两种存储方式的性能对比

自言自语：项目太赶，忙于搬砖，好久没来更新了。回顾了一下以前写的/转载的文章，现在再来看，有了更深更透彻的理解了，才发现自己又进步了，继续加油！

先上测试结果，单位为ms，因为没有苹果机，这里只测试了PC端与安卓：

        //SQLite插入测试
        for (int i = 0; i < 500; i++)
        {
            userRecord.SetRecord("key_" + i,"value_" + i); 
        }

        //LiteDB插入测试
        for (int i = 0; i < 500; i++)
        {
            // Create your new customer instance
            var userdata = new UserData
            {
                Key = "key_" + i,
                Value = "value_" + i,

            };
            col.Insert(userdata);
        }

先说SQLite，目前的项目是一款大型MMORPG,因为沿用的是老项目的框架，所以SQLite这玩意自然也从老项目里搬过来了。笔者觉得这个已经不适合大型项目了，首先SQLite比较笨重，他的第三方库文件总的有7mb左右，对于想要把安装包控制在40mb左右的我们来说，是难以忍受的，而且老项目旧的库文件是不支持新项目的Unity 2017的版本的，又得费时间去找新的dll；另一个问题就是同时操作同一个SQLite文件会导致死锁，而且性能比较差，批量执行会导致卡顿。总而言之大项目就是不建议用这个东西了。。。。单机小游戏可以用下面的LiteDB代替。

LiteDB（GitHub）不同于以上的键值对存储，他是可以直接存储C#类，非常方便，且速度快，虽说测试数据内存消耗相对较大，但是因为它不是键值对存储，笔者为了保证变量唯一，创建了大量的临时变量导致的；在逻辑上优化过后，内存消耗应该会远小于测试数据；并且LiteDB的亮点是可以直接存储Lua表，而其他存储方方式需要拼接成字符串存进键值对，取数据还得再去解析他，这里的内存消耗其实也挺大的。综合考虑，LiteDB的内存消耗并没有那么恐怖。

说到存储方式，当数据量较小、不涉及频繁的查找与修改时，另外还有Json与XML这两种方式，JsonUtility是Unity3D内置的，不能解析复杂的Json,一般LitJson插件用的比较多 ；XML的话用C#提供了XmlDocument。Json与XML怎么取舍，这篇文章写的很详细了，戳一下Json与Xml优劣。还有Unity3D中内置的数据持久化方案PlayerPrefs，一般用于单机游戏吧，存储一些简单的游戏数据，查了下官方文档，本质应该也是使用Xml存储键值对。怎么选择，最终还是要根据项目根据需求来，因地制宜。