长话短说：我正在努力重构我的旧Android项目。以前，它使用序列化，这是非常缓慢的，从我正在阅读，一般来说，Android应用程序的一个非常糟糕的想法。我正在寻找另一种方法来保存用户特定数据以及应用程序的只读数据。
双方都会有大量的数据，我不确定是否有一种“好”的存储方式。基本上，该应用程序是一个小型RPG。有许多“地图”表示为Tiles的2D数组。每个Tile将具有许多属性，一些简单的基元或枚举，其他其他对象，例如Events，也可能包含各种对象等。仅在20x20地图中有400个Tiles，就有大量数据需要存储。除了存储该数据外，还需要存储大量特定于用户的数据，例如访问过哪些Tiles，哪些事件已成功运行等等。
我一直在研究保存这些数据的方法，我似乎无法解决某些问题。我想这可以归结为XML或JSON vs SQLite。 XML或JSON在未来的变化方面会更灵活，这很好，因为我想要数据的灵活性，即向现有对象添加新属性，在需要时添加新对象等.SQLite不那么容易具有可塑性因为你必须改变架构，也许调整查询和索引等，但我过去并没有真正使用SQLite，所以也许有一些功能有助于简化该过程。但是，我还希望快速随机访问数据，以避免在可以帮助的情况下立即将所有内容加载到内存中。例如，当从一个地图移动到另一个地图时，我宁愿只在需要时加载下一个地图而不是将所有内容保存在内存中，这就是SQLite会发光的地方，因为我能够直接查询数据而不是遍历JSON / XML文件以查找可能分散的数据，即我们加载地图，但事件和事件中包含的对象可能不是该地图唯一的，并且可能很容易完全位于文件的其他位置或其他文件中。但是，对SQLite中的数据进行规范化将意味着很多表和相当多的对象的解构/重构。
只有当用户手动保存游戏时才会写入用户数据，因此写入性能不是一个大问题。
我有时会倾向于过度分析并对这样的事情感到困惑。也许这两种情况都不一定是“错误的”，我担心的是无限小的事情。也许还有其他一些我没有考虑过的案例。我已经使用过Hibernate，并且已经考虑过像ORMLite这样的东西来处理大量的数据库细节，但这需要进行大量的改造，可能比我需要为其他选项做的更多。
答案 0 :(得分：0)
我建议你使用SQLite。考虑到您尝试存储的数据量，我认为这是最有意义的。
至于你对它的关注不那么灵活，我会说这一点。只需使用ContentProvider。 ContentProviders可以非常轻松地更新数据库模式和查询，而不会影响您现有的功能。如果您使用ContentProvider，您甚至可以在将来交换持久数据策略，同时使用不同的策略。
http://developer.android.com/guide/topics/providers/content-providers.html