我的音乐应用程序正在引用持久存储的数据。所有当前都存储为文本文件：
收藏夹 - 单个文本文件数组。应用程序启动，读取文本文件，存储在内存中。展开 ListView 时检查数组。如果数组更改，则重写文本文件。
Last Played - 单个文本文件数组列表。每 5 秒更新一次。保留播放歌曲的历史记录，以允许用户返回任何专辑并恢复位置。
播放列表 - 当前单独的文本文件，每个列表一个。需要时从文件名生成的播放列表列表。每个播放列表文本文件里面都有数组列表。需要时读写。
大多数播放 - 单个文本文件数组列表。每播放一首歌更新一次。
我想知道这些数据是否需要更改为数据库，或者我是否采取了正确的方法。我不认为需要添加额外的数据，所以这应该是我最需要的。
请指教！
您可以将文本文件存储在 SharedPreference 中，它应该可以正常工作。
如果需要存储大量数据，最好使用数据库。使用数据库比解析字符串更优化。
正确的方法是为您想要表示的每个事物创建一个类，例如收藏夹。每个类都有一个 save() 和 reload() 方法。关键是您可以更改 save() 和 reload() 方法中的底层存储机制，而无需更改其余代码。想象一下，将来您想要启用保存到 Dropbox。您只需更改这些方法，您的应用程序就会正常工作（好吧，您需要添加一些东西来获取 Dropbox 帐户详细信息，但您明白了）。
您可以更进一步并定义用于加载和保存的接口。该接口可以使用一个类，只负责保存和加载。只要任何消费者和提供者类都遵循该接口，您就可以混合和匹配，甚至实现尚未发明的存储方法，而无需重新编码您的应用程序。如果以及何时更改存储方法，您只有一个类可以使用。
class StorageManager(){
enum DataType {Favourites, MostPlayed, PlayList };
...
public save(DataType dataType){
if (dataType == DataType.Favourites){
saveFavouritesToDB();
...
...
}
这种方法为您提供了最大的灵活性、最大的未来验证和更好的可维护性。
我认为最好使用数据库。
数据库应该为您提供一些优化、性能改进，并且基本上您不必重新发明轮子（在磁盘上进行读/写操作，在重写之前使用一些缓冲区等）。
另外，一旦你开始使用这种方式，我认为你会喜欢所有代码的组织方式并分成自己的层。