Android中Serializable对象收藏列表（≤100条）的持久化存储方案选型

咱们结合你的使用场景——偶尔保存/删除收藏列表里最多100个Serializable类型的X对象，来逐个拆解这几个持久化方案的优劣势：

1. SharedPreferences 以JSON字符串存储整个列表 #

• 优点：实现起来超级省心，几行代码就能完成列表到JSON的序列化和反序列化，完全不用处理复杂的数据库逻辑。100个对象的规模，加上你只是偶尔操作，全量读写的性能开销几乎可以忽略不计。
• 缺点：每次修改（比如删一个收藏）都得把整个列表从SP里读出来、转成对象列表，修改后再重新序列化写回去。但这个缺点在你的场景里根本不算问题，毕竟操作频率低，数据量也小。
• 适配性：完美匹配你的需求，开发效率拉满。

2. SQLite数据库逐条存储（BLOB/JSON字符串） #

• 优点：支持单条对象的独立操作，删某个收藏直接执行DELETE语句就行，不用折腾整个列表。如果以后需求升级（比如要按对象属性筛选收藏、统计收藏数量），SQLite的灵活性会很有用。用BLOB存Serializable对象更直接，用JSON存的话，数据库内容可读性更好。
• 缺点：需要写一堆数据库增删改查的代码，还要处理版本迁移、Cursor操作这些细节，开发成本比SP高太多。对于你这种“最多100个对象+偶尔操作”的场景，属于过度设计了。
• 适配性：功能过剩，没必要为了当前需求增加这么多复杂度。

3. 自定义文件存储 #

• 虽然你没给出完整内容，但常规的自定义文件存储要么是全量序列化整个列表（思路和SP类似，但得自己处理文件IO、异常捕获、文件锁，比SP麻烦多了），要么是逐条写入（得自己定义文件格式、解析规则，维护成本极高）。这个方案既没有SP的简洁，也没有SQLite的灵活，完全不适合你的场景。

最终结论 #

优先选SharedPreferences以JSON字符串存储整个列表。它的开发成本最低，完全能覆盖你当前的需求。如果以后收藏功能变得复杂（比如操作频繁、需要多条件查询），再迁移到SQLite也很容易。

内容的提问来源于stack exchange，提问作者CesarPim