在安卓应用开发中,数据持久化是一项至关重要的基础功能，尤其在单机应用场景下，所有数据都需要存储在用户设备本地，以便在应用关闭后下次启动时能够恢复状态或提供历史记录，安卓系统为开发者提供了多种本地数据存储方案，以满足不同复杂度的数据需求，本文将详细介绍几种主流的单机数据库存储方式，并分析其适用场景与优劣。
轻量级存储：SharedPreferences
SharedPreferences是安卓平台上最轻量级的数据存储方案,它以键值对的形式将数据保存在XML文件中，这种方式非常适合存储应用配置信息、用户偏好设置等少量、非结构化的简单数据。
核心特点：
- 数据类型：支持基本数据类型，如
String,int,boolean,float,long以及Set<String>。 - 存储位置：应用的私有数据目录（
/data/data/包名/shared_prefs/），其他应用无法访问。 - 使用方式：通过
Context.getSharedPreferences()方法获取实例，然后通过edit()方法获取Editor对象进行数据的增、删、改操作，最后通过apply()或commit()提交更改。
示例代码：
// 获取SharedPreferences实例
SharedPreferences prefs = context.getSharedPreferences("user_prefs", Context.MODE_PRIVATE);
// 存储数据
SharedPreferences.Editor editor = prefs.edit();
editor.putString("username", "Alice");
editor.putInt("level", 5);
editor.apply(); // apply()是异步操作，推荐使用
// 读取数据
String username = prefs.getString("username", "default_user");
int level = prefs.getInt("level", 1);
适用场景：保存“记住密码”选项、主题设置（日间/夜间模式）、应用首次启动标记等，它的优势在于简单高效，但缺点也十分明显，不适用于存储大量或结构复杂的数据。
传统关系型数据库：SQLite
SQLite是安卓系统内置的一个轻量级、关系型数据库引擎，它支持标准的SQL语法，功能强大，能够处理结构复杂、数据量较大的信息，如联系人列表、订单记录等。
核心特点：
- 结构化存储：通过创建表来组织数据，支持定义主键、外键、索引等。
- 功能强大：支持复杂的查询、事务处理，保证了数据的一致性和完整性。
- 原生支持：安卓系统直接提供API，无需额外依赖库。
要操作SQLite,通常需要创建一个继承自SQLiteOpenHelper的帮助类，这个类负责数据库的创建和版本管理，通过它，我们可以获取SQLiteDatabase对象，进而执行execSQL()、insert(), query(), delete(), update()等操作。
使用SQLite的挑战：
直接使用SQLite的API需要编写大量的模板代码,例如定义表结构的SQL语句、创建ContentValues对象来封装数据、使用Cursor来遍历查询结果等，这不仅繁琐，而且容易出错，特别是在SQL语句的编写上，编译时无法发现错误。
现代化持久化方案：Room
为了简化SQLite的使用,Google推出了Room持久化库，它是在SQLite之上的一层抽象封装，极大地减少了开发者的工作量，并提供了诸多便利，Room是目前Google官方推荐的首选数据库方案。
Room的三大核心组件：
- Entity（实体）：使用
@Entity注解的类，定义了数据库中的表结构，类的字段对应表的列。 - DAO（Data Access Object）：使用
@Dao注解的接口或抽象类，定义了访问数据库的方法，Room会自动为这些方法生成实现。 - Database：使用
@Database注解的抽象类，负责创建数据库实例并作为应用与数据库交互的主要入口点。
示例代码：
// 1. 定义Entity
@Entity(tableName = "users")
data class User(
@PrimaryKey val id: Int,
val name: String,
val age: Int
)
// 2. 定义DAO
@Dao
interface UserDao {
@Insert
fun insertUser(user: User)
@Query("SELECT * FROM users WHERE age > :minAge")
fun getUsersOlderThan(minAge: Int): List<User>
}
// 3. 定义Database
@Database(entities = [User::class], version = 1)
abstract class AppDatabase : RoomDatabase() {
abstract fun userDao(): UserDao
}
Room的优势：
- 减少模板代码：无需再手写
SQLiteOpenHelper和繁琐的SQL拼接。 - 编译时SQL验证：Room会在编译时检查
@Query注解中的SQL语句是否有语法错误，提前发现问题。 - 与架构组件集成：可以轻松与
LiveData、Flow等响应式编程组件结合，实现数据变化时的UI自动更新。
方案对比与选择
为了更直观地选择合适的存储方案,可以参考下表：
| 特性 / 方案 | SharedPreferences | SQLite | Room |
|---|---|---|---|
| 数据类型 | 键值对（基本类型） | 结构化表（任何类型） | 结构化表（任何类型） |
| 适用场景 | 用户设置、简单标记 | 复杂关系、大量数据 | 所有需要SQLite的场景 |
| 实现复杂度 | 非常简单 | 较高，模板代码多 | 简单，注解驱动 |
| 编译时检查 | 无 | 无 | 有（SQL语句验证） |
| 推荐指数 | ★★☆☆☆ | ★★★☆☆ | ★★★★★ |
对于安卓单机应用的数据存储,选择应基于数据本身的特性，如果只是保存几个简单的设置项，SharedPreferences绰绰有余，当需要处理大量、具有关联关系的数据时，就应该考虑使用数据库，在SQLite和Room之间，除非有特殊限制，否则Room凭借其安全、高效、易用的优势，无疑是现代安卓开发中的最佳选择。
相关问答 (FAQs)
Q1：SharedPreferences和SQLite数据库在底层存储文件上有什么不同？
A1： SharedPreferences本质上是在应用的私有目录下创建了一个XML文件，所有的键值对都以标签的形式保存在这个文件中，读写过程是对XML文件的解析和序列化，而SQLite则创建了一个单一的二进制数据库文件（通常是.db后缀），数据以B-tree等高效的数据结构形式存储在该文件中，通过SQL语句进行操作，SQLite在处理大量数据时，性能远高于SharedPreferences。
Q2：为什么说Room能够“减少模板代码”？具体体现在哪些方面？
A2： “减少模板代码”主要体现在Room将数据库操作的通用逻辑自动化了。
- 无需编写
SQLiteOpenHelper：你只需在@Database注解中声明实体和版本号，Room会自动处理数据库的创建和升级。 - 自动生成SQL实现：你只需在DAO接口中用
@Insert,@Delete,@Query等注解声明方法，Room会在编译时自动生成具体的实现代码，无需手动拼接SQL语句或操作ContentValues和Cursor。 - 类型安全：DAO方法的参数和返回值直接使用你的
Entity对象或其集合，避免了从Cursor中手动取出每一列数据并封装成对象的繁琐过程，这些自动化处理使得开发者能更专注于业务逻辑本身，而非底层的数据库细节。