Android --- SharePreference 存储与数据库存储的效率分析(1)

原文链接：https://blog.csdn.net/MacaoPark/article/details/114680449

前言

---

最近到了一家公司，跟一个同事做项目，比如常规的一些操作用SharedPreferences就很好搞定，他跟我说SharedPreferences 会影响性能说了一堆… 难道别的存储方式就不耗费性能吗？不消耗内存吗？

有关Android存储

---

Android中的数据存储方案主要有：共享首选项（SharedPreferences）、内部存储（Internal Storage）、外部存储（External Storage）、SQLite数据库、 网络存储 静态变量等

SharedPreferences 共享首选项

---

先说一下SharedPreferences 简称SP ， SharedPreferences类提供了一个通用框架，使开发者能够以键值对的方式，永久性的保存一些原始数据类型的数据，包括：布尔值，浮点值，整型值，长整型和字符串，被保存的数据可以跨多个用户会话永久保留（即使应用已经终止）。

为什么使用 SP 它的优点是什么？ 使用SP 为Android开发者提供了更为便利的存储方式，但是相对的他也是有一些缺点的。

当我们首次创建 SharedPreferences 对象时，会根据文件名将文件下内容一次性加载到 mMap（SharedPreferencesImpl 成员） 容器中，每当我们 edit 都会创建一个新的 EditorImpl 对象，当修改或者添加数据时会将数据添加到 mModifiled （EditorImpl 成员）容器中，然后 commit 或 apply 操作比较 mMap 与 mModifiled 数据修正 mMap 中最后一次提交数据，然后写入到文件中。而 get 直接从 mMap 中读取。试想如果此时你存储了一些大型 key 或 value 它们会一直存储在内存中得不到释放。

(1) 不要存放大的 key 和 value 在 SharedPreferences 中，否则会一直存储在内存中得不到释放，内存使用过高会频发引发GC，导致界面丢帧甚至ANR

(2) 不相关的配置选项最好不要放在一起，单个文件越大读取速度则越慢。

(3) 读取频繁的 key 和不频繁的 key 尽量不要放在一起（如果整个文件本身就较小则忽略，为了这点性能添加维护得不偿失）。

(4) 尽量不要存放 JSON 和 HTML，这种可以直接文件缓存。Json/HTML 文件较小忽略不计！

(5) 不要指望这货能够跨进程通信 Context.PROCESS

静态变量存储方式

写在最后

本次我的分享也接近尾声了，感谢你们在百忙中花上一下午来这里聆听我的宣讲，希望在接下来的日子，我们共同成长，一起进步！！！

最后放上一个大概的Android学习方向及思路（详细的内容太多了~），提供给大家：

对于程序员来说，要学习的知识内容、技术有太多太多，这里就先放上一部分，其他的内容有机会在后面的文章向大家呈现出来，不过我自己所有的学习资料都整理成了一个文档，一直在不断学习，希望能帮助到大家，也节省大家在网上搜索资料的时间来学习，也可以分享动态给身边好友一起学习！

为什么某些人会一直比你优秀，是因为他本身就很优秀还一直在持续努力变得更优秀，而你是不是还在满足于现状内心在窃喜！希望读到这的您能点个小赞和关注下我，以后还会更新技术干货，谢谢您的支持！

Android架构师之路很漫长，一起共勉吧！

如果你觉得文章写得不错就给个赞呗？如果你觉得那里值得改进的，请给我留言，一定会认真查询，修正不足，谢谢。

网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。

需要这份系统化学习资料的朋友，可以戳这里获取

一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！

远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！**