Activity的保存数据库主要指Android系统中的SharedPreferences（轻量级键值对）和SQLite（关系型数据库），选择哪种取决于数据结构的复杂度和读写频率需求。
在Android应用开发中，Activity作为用户交互的核心组件，其生命周期管理至关重要，当屏幕旋转、配置变更或用户切换应用时，Activity可能会被销毁并重新创建，如果此时不妥善保存状态，用户输入的数据、界面状态或临时业务逻辑就会丢失，导致糟糕的用户体验，理解并正确实现Activity的状态持久化,是每一位开发者必须掌握的基础技能。
为什么Activity需要保存状态？
很多初学者会问，为什么不能只靠内存变量？这是因为Android系统的内存管理机制比较严格，当系统资源紧张时，后台的Activity可能被回收，即使没有被回收,屏幕方向改变等配置变更也会触发Activity的重建。
业内专家指出，状态保存的核心目的是确保“数据不丢失”和“体验连续性”。
- 配置变更场景：比如用户将手机从竖屏转为横屏，Activity会重新调用
onCreate方法，如果没有保存之前的输入框内容，用户需要重新填写,这非常令人沮丧。 - 进程杀后台景：当用户按下Home键，应用进入后台，如果系统内存不足，杀死后台进程以释放资源给前台应用，当用户再次打开应用时，Activity恢复,之前的状态应当完好无损。
- 复杂业务状态：对于游戏或视频播放类应用，进度条位置、游戏分数、当前关卡等状态，必须持久化存储,否则用户重新进入时无法继续。
SharedPreferences：轻量级数据的首选方案
对于简单的键值对数据，如用户设置、登录状态、开关选项等，SharedPreferences是最常用的方案，它底层基于XML文件存储，操作简单,适合小规模数据。
如何正确使用SharedPreferences
使用SharedPreferences保存数据通常分为三个步骤：获取编辑器、写入数据、提交保存。
- 获取Editor对象：通过
getSharedPreferences方法获取实例，并调用edit()方法获取编辑器。 - 写入数据：使用
putString、putInt等方法将数据存入内存中的编辑器对象。 - 提交更改：调用
apply()或commit()方法将数据写入磁盘文件。
SharedPreferences prefs = getSharedPreferences("MyPrefs", MODE_PRIVATE);
SharedPreferences.Editor editor = prefs.edit();
editor.putString("username", "admin");
editor.putInt("age", 25);
editor.apply(); // 推荐使用apply，异步写入，性能更好 apply与commit的区别
- apply：异步写入，立即返回，不返回结果，适合大多数场景,性能更优。
- commit：同步写入，返回布尔值表示成功与否，适用于需要立即知道写入结果的场景,但会阻塞主线程。
SharedPreferences的局限性
尽管方便,但SharedPreferences不适合存储大量数据或复杂结构数据。
- 性能瓶颈：每次读写都会涉及文件IO操作,数据量大时会影响UI线程流畅度。
- 类型限制：仅支持基本数据类型，不支持对象、集合等复杂结构。
- 并发问题：多线程同时写入可能导致数据覆盖或丢失,需自行处理同步问题。
SQLite数据库：复杂数据结构的存储利器
当需要存储大量结构化数据，如用户列表、订单记录、日志信息等，SQLite是更合适的选择，它是Android内置的关系型数据库，无需额外配置,轻量且高效。
SQLite的基本操作流程
使用SQLite数据库通常涉及创建数据库、定义表结构、插入/查询/更新/删除数据等操作。
- 创建数据库：继承
SQLiteOpenHelper类，重写onCreate和onUpgrade方法。 - 定义表结构：在
onCreate中执行CREATE TABLE语句。 - 执行SQL操作：通过
getWritableDatabase()或getReadableDatabase()获取数据库实例,执行SQL语句或使用ContentValues辅助插入。
public class MyDatabaseHelper extends SQLiteOpenHelper { public MyDatabaseHelper(Context context) { super(context, "MyDB.db", null, 1); } @Override public void onCreate(SQLiteDatabase db) { db.execSQL("CREATE TABLE user (_id INTEGER PRIMARY KEY AUTOINCREMENT, name TEXT, age INTEGER)"); } @Override public void onUpgrade(SQLiteDatabase db, int oldVersion, int newVersion) { db.execSQL("DROP TABLE IF EXISTS user"); onCreate(db); } }
使用ContentValues简化插入操作
相比直接拼接SQL字符串，使用ContentValues更安全、更易读。
SQLiteDatabase db = helper.getWritableDatabase();
ContentValues values = new ContentValues();
values.put("name", "Alice");
values.put("age", 30);
db.insert("user", null, values); SQLite的性能优化建议
- 批量操作：使用
beginTransaction()和setTransactionSuccessful()开启事务，批量插入数据,避免频繁IO。 - 索引优化：对频繁查询的字段建立索引,提升查询速度。
- 避免主线程阻塞：数据库操作应在子线程中进行,或使用Room等ORM框架简化操作。
Activity状态保存的最佳实践对比
为了更直观地展示不同方案的适用场景,我们对比一下SharedPreferences和SQLite在Activity状态保存中的表现。
| 特性 | SharedPreferences | SQLite |
|---|---|---|
| 数据类型 | 基本数据类型（String, Int, Boolean等） | 结构化数据（表、行、列） |
| 数据量 | 少量数据（KB级别） | 大量数据（MB至GB级别） |
| 查询复杂度 | 简单键值查找 | 支持SQL复杂查询、关联、聚合 |
| 性能 | 读写速度快，适合小数据 | 大数据量下性能优异，需优化 |
| 适用场景 | 用户设置、登录状态、开关 | 用户列表、订单记录、日志 |
| 学习曲线 | 低，API简单 | 中高，需掌握SQL和ORM |
如何选择？
- 如果数据是简单的配置项，如是否开启通知、主题颜色、上次登录时间,首选SharedPreferences。
- 如果数据是结构化的列表或记录，如购物车商品、聊天记录、用户档案,应选择SQLite。
- 如果数据量极大或需要复杂查询，可考虑使用Room数据库，它是Google官方推荐的SQLite抽象层，简化了数据库操作,提供了编译时检查SQL错误的能力。
常见问题解答（FAQ）
Activity保存数据库与ViewModel有什么区别？
SharedPreferences和SQLite用于持久化存储，数据保存在磁盘上，应用重启后依然存在，而ViewModel用于在配置变更（如屏幕旋转）期间保存内存中的数据，应用完全退出后数据丢失，两者互补，ViewModel适合短期状态,持久化数据库适合长期数据。
如何安全地保存用户密码？
绝对不要明文保存密码，应使用加密算法（如AES）对密码进行加密后存储，或使用Android提供的Keystore系统管理密钥，对于登录状态，通常保存Token而非密码,并设置合理的过期时间。
Activity保存数据库在Android 11及以上版本有哪些限制？
Android 11引入了分区存储（Scoped Storage），限制了应用对公共存储区域的直接访问，但SharedPreferences和SQLite文件位于应用私有目录（/data/data/<package_name>/），不受分区存储限制，开发者仍可正常使用，若需访问外部存储中的数据库文件,需申请相应权限并遵循新规范。
【版权声明】：本站所有内容均来自网络，若无意侵犯到您的权利，请及时与我们联系将尽快删除相关内容!
发表回复