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

原文链接：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

静态变量存储方式

因为这种方式我与我一个同事有了一些意见不一的地方，他喜欢使用静态变量。现在的开发是针对于设备开发，而并非手机app的开发，如果app开发他的那种搞法非得出现问题不可。
因为Activity初始化的静态变量也会被置空，因此它的生命周期是不稳定的。也就是说，在Android中静态变量可能随时被系统置空，变为null，其它地方在使用的时候就会产生空指针现象

在Android开发中不提倡过多使用static类型的变量（除了 static final）因为静态变量生命周期较长，而且不易被系统回收，因此如果不能合理地使用静态变量，就会适得其反，造成大量的内存浪费，所谓过犹不及。
经过我的多方查证 建议在具备下列全部条件的情况下，尽量使用静态变量：
(1) 变量所包含的对象体积较大，占用内存较多。
(2) 变量所包含的对象生命周期较长。
(3) 变量所包含的对象数据稳定。
(4) 该类的对象实例有对该变量所包含的对象的共享需求。
如果变量不具备上述特点建议你不要轻易地使用静态变量，以免弄巧成拙。
对于全局变量使用Android提供了 Application 其生命周期与应用程序共存亡。所以对于全局变量可以写在 Application。

到底使用哪一种存储方式?

(1) 如果是简单的数据结构，首选 SharedPreferences
(2) 如果是数据量大处理复杂的话，首选是sql数据库 对于结构化的数据，一定要使用数据库，虽然会显得比较麻烦，但是后续的使用中会获益无穷
(3) 普通文件就是指文本文件，二进制文件，多媒体文件，还有频繁的读取要是用二进制文件。
(4) 使用网络存储时要避免传输大数据量数据，应注意对网络传输方式的优化（减少请求次数等）。