Large amounts of same structured data should be stored in a SQLite database as databases are designed for this kind of data. As the data is structured and managed by the database, it can be queried to get a sub set of the data which matches certain criteria using a query language like SQL. This makes it possible to search in the data. Of course managing and searching large sets of data influences the performance so reading data from a database can be slower than reading data from SharedPreferences.
SharedPreferences
SharedPreferences is a key/value store where you can save a data under certain key. To read the data from the store you have to know the key of the data. This makes reading the data very easy. But as easy as it is to store a small amount of data as difficult it is to store and read large structured data as you need to define key for every single data, furthermore you cannot really search within the data except you have a certain concept for naming the keys.
This question has an accepted answer, but I think there is more to said on the topic - regarding speed.
An application's SharedPreferences and Sqlite DB are both just files, stored in the application's directories on the device's file system. If the amount of data is not too big, the Sqlite option will involve a larger and more complicated file with more processing overhead for simple access.
So, if the nature of the data does not dictate your choice (as explained in accepted answer), and speed matters, then you are probably better to use SharedPreferences.
And reading some data is often on the critical path to displaying the main activty so I think speed is often very important.
One final thought regarding speed and efficiency - if you need to use an Sqlite database for some structured data then it is probably more efficient to also store user preferences in the database so you are not opening a second file. This is a fairly minor consideration - probably worth consideration only if you need to access both the structured data and preferences before you can display the main activity.
使用 Preferences 的最大诱惑是当您想要使用它来将扁平化的 POJO（序列化的 JSON 对象）存储为 String 时。有这样的需求其实就是使用Sqlite的标志。为什么 ？因为复杂的数据最终需要复杂的操作。想象一下检索可以通过简单的“SELECT ... WHERE id = 1”来处理的特定条目。在 Preferences 路径中，从反序列化到迭代结果将是一个漫长的过程。
My take is, it is not about speed or size but the kinds of operation you want to do to your data.
If you plan to do join, sort, and other DB operations on your data then go for Sqlite. An example is sorting data by date.
If you want to map simple values (like int, boolean, String) then use Preferences. DB operations won't work here and needless to say you need to have all the keys. An example is user password or app configuration.
The big temptation to embrace Preferences is when you want to use it to store a flattened POJO (a serialized JSON object) as String. Having such need is actually the sign to use Sqlite. Why ? Because complex data will eventually need complex oprations. Imagine retrieving a specific entry which could be handled by a simple "SELECT ... WHERE id = 1". In Preferences path, this will be a long process from deserializing to iterating the results.
For storing huge amount of data, go for SQLite database system. This will allow the user to search for data as well.
On the other hand, for storing small amount of data, go for Shared Preferences. In this case, a huge database system is unnecessary. This will allow user to simply save data and load them.
Forget SQLLite forget SharedPreferences, use Realm. A single solution for all your local storage. You can use plain old Java Objects as RealmObjects and store your data there. You can convert selcted queries into JSON files. No need to parse the entire data base. Check this link: https://realm.io/news/introducing-realm/
发布评论
评论（5）
这实际上取决于您要存储的数据。
SQLite
大量相同结构化的数据应该存储在 SQLite 数据库中，因为数据库就是为此类数据设计的。由于数据是由数据库构建和管理的，因此可以使用 SQL 等查询语言对其进行查询以获得符合特定条件的数据子集。这使得在数据中搜索成为可能。当然，管理和搜索大量数据会影响性能，因此从数据库读取数据可能比从 SharedPreferences 读取数据慢。
SharedPreferences
SharedPreferences 是一个键/值存储，您可以在其中保存特定键下的数据。要从商店读取数据，您必须知道数据的密钥。这使得读取数据变得非常容易。但是，存储少量数据很容易，存储和读取大型结构化数据也很困难，因为您需要为每个数据定义键，此外，除非您有一定的概念，否则您无法真正在数据中进行搜索命名键。
It really depends on the data you want to store.
SQLite
Large amounts of same structured data should be stored in a SQLite database as databases are designed for this kind of data. As the data is structured and managed by the database, it can be queried to get a sub set of the data which matches certain criteria using a query language like SQL. This makes it possible to search in the data. Of course managing and searching large sets of data influences the performance so reading data from a database can be slower than reading data from SharedPreferences.
SharedPreferences
SharedPreferences is a key/value store where you can save a data under certain key. To read the data from the store you have to know the key of the data. This makes reading the data very easy. But as easy as it is to store a small amount of data as difficult it is to store and read large structured data as you need to define key for every single data, furthermore you cannot really search within the data except you have a certain concept for naming the keys.
这个问题有一个公认的答案，但我认为关于这个话题还有更多要说的——关于速度。
应用程序的 SharedPreferences 和 Sqlite DB 都只是文件，存储在设备文件系统上的应用程序目录中。如果数据量不太大，Sqlite选项将涉及更大、更复杂的文件，对于简单访问来说，处理开销更大。
因此，如果数据的性质并不决定您的选择（如接受的答案中所述），并且速度很重要，那么您可能最好使用 SharedPreferences。
读取一些数据通常是显示主要活动的关键路径，因此我认为速度通常非常重要。
关于速度和效率的最后一个想法 - 如果您需要使用 Sqlite 数据库来存储某些结构化数据，那么在数据库中存储用户首选项可能会更有效，这样您就不会打开第二个文件。这是一个相当次要的考虑因素 - 仅当您需要在显示主要活动之前访问结构化数据和首选项时才可能值得考虑。
This question has an accepted answer, but I think there is more to said on the topic - regarding speed.
An application's SharedPreferences and Sqlite DB are both just files, stored in the application's directories on the device's file system. If the amount of data is not too big, the Sqlite option will involve a larger and more complicated file with more processing overhead for simple access.
So, if the nature of the data does not dictate your choice (as explained in accepted answer), and speed matters, then you are probably better to use SharedPreferences.
And reading some data is often on the critical path to displaying the main activty so I think speed is often very important.
One final thought regarding speed and efficiency - if you need to use an Sqlite database for some structured data then it is probably more efficient to also store user preferences in the database so you are not opening a second file. This is a fairly minor consideration - probably worth consideration only if you need to access both the structured data and preferences before you can display the main activity.
我的看法是，这与速度或大小无关，而是与您想要对数据执行的操作类型有关。
如果您打算对数据进行连接、排序、和其他数据库操作，那么请选择Sqlite。一个示例是按日期对数据进行排序。
如果您想映射简单值（如 int、boolean、String），请使用首选项。数据库操作在这里不起作用，不用说您需要拥有所有密钥。一个示例是用户密码或应用程序配置。
使用 Preferences 的最大诱惑是当您想要使用它来将扁平化的 POJO（序列化的 JSON 对象）存储为 String 时。有这样的需求其实就是使用Sqlite的标志。为什么 ？因为复杂的数据最终需要复杂的操作。想象一下检索可以通过简单的“SELECT ... WHERE id = 1”来处理的特定条目。在 Preferences 路径中，从反序列化到迭代结果将是一个漫长的过程。
My take is, it is not about speed or size but the kinds of operation you want to do to your data.
If you plan to do join, sort, and other DB operations on your data then go for Sqlite. An example is sorting data by date.
If you want to map simple values (like int, boolean, String) then use Preferences. DB operations won't work here and needless to say you need to have all the keys. An example is user password or app configuration.
The big temptation to embrace Preferences is when you want to use it to store a flattened POJO (a serialized JSON object) as String. Having such need is actually the sign to use Sqlite. Why ? Because complex data will eventually need complex oprations. Imagine retrieving a specific entry which could be handled by a simple "SELECT ... WHERE id = 1". In Preferences path, this will be a long process from deserializing to iterating the results.
要存储大量数据，请选择 SQLite 数据库系统。这
也将允许用户搜索数据。
另一方面，为了存储少量数据，请选择共享
偏好。在这种情况下，不需要庞大的数据库系统。
这将允许用户简单地保存数据并加载它们。
For storing huge amount of data, go for SQLite database system. This
will allow the user to search for data as well.
On the other hand, for storing small amount of data, go for Shared
Preferences. In this case, a huge database system is unnecessary.
This will allow user to simply save data and load them.
忘记 SQLLite 忘记 SharedPreferences，使用 Realm。适用于所有本地存储的单一解决方案。您可以使用普通的旧 Java 对象作为 RealmObjects 并将数据存储在那里。您可以将选定的查询转换为 JSON 文件。无需解析整个数据库。
检查此链接：
https://realm.io/news/introducing-realm/
Forget SQLLite forget SharedPreferences, use Realm. A single solution for all your local storage. You can use plain old Java Objects as RealmObjects and store your data there. You can convert selcted queries into JSON files. No need to parse the entire data base.
Check this link:
https://realm.io/news/introducing-realm/