我有一个应用程序一直在后台运行(仅在屏幕打开时),并且定期(1-10分钟)记录间隔时间有多长以及是好还是坏间隔。在每天结束时,我将这些好的和坏的间隔计数并记录到csv文件中。
For visual people like me:
<--------------------------THE DAY --------------------->
minutes: 2m 1m 5m 3m 3m 3m 3m 1m 2m 1m 1m
|----|---|-------|-----|-----|-----|-----|--|----|---|---|
rec rec rec rec rec rec rec rec rec rec rec
Record
目前我使用SharedPreferences来存储一天中的好/坏计数,并在一天结束时将其写入文件,但我越来越担心SharedPrefs数据的持久性(我已经有了我认为操作系统清理我的应用程序缓存的一些情况随机擦除了
我试图决定在文件中记录这些临时计数与完全迁移到SQLite数据库结构并在一整天内进行一致的写入和读取调用。
从电池性能的角度来看,这是每天多次写入和阅读电话的成本最低(约500-5000次)和为什么?
答案 0 :(得分:1)
SQLite数据库==基于文件的数据存储
SQLite数据库只是存储在磁盘上的一个文件,性能差异很小,SQLite数据库唯一能做的就是在CPU上执行更多指令以最终获取数据。
我不选择SQLite数据库的唯一原因是因为你可能只是在设置方面有点过分,因为你只是在编写数字。您可以做的是将文件自己写入存储/ SD卡,并将数字附加到由换行符或其他CSV格式分隔的文件中。
答案 1 :(得分:0)
看起来基于文件的方法会比sqlite更好,但这取决于你如何处理文件
SQLite本身将数据存储在db文件中。它将拥有自己的数据库 管理成本,但非常小
每次app插入或获取数据时,都必须打开db,这个 将是一个成本本身。如果应用程序保持打开,那也是昂贵的
直接更新文件的android API层将比sq lite
除了所有这些事实之外,测试这样的场景应该不是问题。我将编写一个像这样的测试用例
具有恒定的电池电量,即100%完全充电
继续运行一些电池密集型活动,即播放视频,下载,运行连续写入文件的程序(当前日期时间秒)
将规则间隔减少到10秒(从1-10分钟)
每5分钟更新一次文件中的数据
2小时后检查电池电量
重复测试但在第3点更新db而不是文件
可能会有双重工作,因为您必须使用这两种方法实现,但我相信db中的更新将不会有太多编码工作
很少有人可能不喜欢10秒间隔,因为在此持续时间内不会发生重大变化,但此处的目标是尽可能多地进行迭代,在文件或数据库中更新它们并获取电池级别比较的统计数据。