通过专栏前面我讲的I/O优化基础知识，相信你肯定了解了文件系统和磁盘的一些机制，以及不同I/O方式的使用场景以及优缺点，并且可以掌握如何在线上监控I/O操作。

万丈高楼平地起，在理解并掌握这些基础知识的同时，你肯定还想知道如何利用这些知识指导我们写出更好的代码。

今天我来结合Android系统的一些特性，讲讲开发过程中常见存储方法的优缺点，希望可以帮你在日常工作中如何做出更好的选择。

Android的存储基础

在讲具体的存储方法之前，我们应该对Android系统存储相关的一些基础知识有所了解。

1. Android分区

I/O优化中讲到的大部分知识更侧重Linux系统，对于Android来说，我们首先应该对Android分区的架构和作用有所了解。在我们熟悉的Windows世界中，我们一般都把系统安装在C盘，然后还会有几个用来存放应用程序和数据的分区。

Android系统可以通过/proc/partitions或者df命令来查看的各个分区情况，下图是Nexus 6中df命令的运行结果。

什么是分区呢？分区简单来说就是将设备中的存储划分为一些互不重叠的部分，每个部分都可以单独格式化，用作不同的目的。这样系统就可以灵活的针对单独分区做不同的操作，例如在系统还原（recovery）过程，我们不希望会影响到用户存储的数据。

从上面的表中你可以看到，每个分区非常独立，不同的分区可以使用的不同的文件系统。其中比较重要的有：

2. Android存储安全

除了数据的分区隔离，存储安全也是Android系统非常重要的一部分，存储安全首先考虑的是权限控制。

第一，权限控制

Android的每个应用都在自己的应用沙盒内运行，在 Android 4.3之前的版本中，这些沙盒使用了标准Linux的保护机制，通过为每个应用创建独一无二的Linux UID来定义。简单来说，我们需要保证微信不能访问淘宝的数据，并且在没有权限的情况下也不能访问系统的一些保护文件。

在Android 4.3引入了SELinux（Security Enhanced Linux）机制进一步定义Android应用沙盒的边界。那它有什么特别的呢？它的作用是即使我们进程有root权限也不能为所欲为，如果想在SELinux系统中干任何事情，都必须先在专门的安全策略配置文件中赋予权限。

第二，数据加密

除了权限的控制，用户还会担心在手机丢失或者被盗导致个人隐私数据泄露。加密或许是一个不错的选择，它可以保护丢失或被盗设备上的数据。

Android有两种设备加密方法：全盘加密和文件级加密。全盘加密是在Android 4.4中引入的，并在Android 5.0中默认打开。它会将/data分区的用户数据操作加密/解密，对性能会有一定的影响，但是新版本的芯片都会在硬件中提供直接支持。

我们知道，基于文件系统的加密，如果设备被解锁了，加密也就没有用了。所以Android 7.0增加了基于文件的加密。在这种加密模式下，将会给每个文件都分配一个必须用用户的passcode推导出来的密钥。特定的文件被屏幕锁屏之后，直到用户下一次解锁屏幕期间都不能访问。

可能有些同学会问了，Android的这两种设备加密方法跟应用的加密有什么不同，我们在应用存储还需要单独的给敏感文件加密吗？

我想说的是，设备加密方法对应用程序来说是透明的，它保证我们读取到的是解密后的数据。对于应用程序特别敏感的数据，我们也需要采用RSA、AES、chacha20等常用方式做进一步的存储加密。

常见的数据存储方法

Android为我们提供了很多种持久化存储的方案，在具体介绍它们之前，你需要先问一下自己，什么是存储？

每个人可能都会有自己的答案，在我看来，存储就是把特定的数据结构转化成可以被记录和还原的格式，这个数据格式可以是二进制的，也可以是XML、JSON、Protocol Buffer这些格式。

对于闪存来说，一切归根到底还是二进制的，XML、JSON它们只是提供了一套通用的二进制编解码格式规范。既然有那么多存储的方案，那我们在选择数据存储方法时，一般需要考虑哪些关键要素呢？

1. 关键要素

在选择数据存储方法时，我一般会想到下面这几点，我把它们总结给你。

那上面这些要素哪个最重要呢？数据存储方法不能脱离场景来考虑，我们不可能把这六个要素都做成最完美。

我来解释一下这句话。如果首要考虑的是正确性，那我们可能需要采用冗余、双写等方案，那就要容忍对时间开销产生的额外影响。同样如果非常在意安全，加解密环节的开销也必不可小。如果想针对启动场景，我们希望选择在初始化时间和读取时间更有优势的方案。

2. 存储选项

总的来说，我们需要结合应用场景选择合适的数据存储方法。那Android为应用开发者提供了哪些存储数据的方法呢？你可以参考存储选项，综合来看，有下面几种方法。

今天我先来讲SharedPreferences和ContentProvider这两个存储方法，文件和数据库将放到“存储优化”后面两期来讲。

第一，SharedPreferences的使用。

SharedPreferences是Android中比较常用的存储方法，它可以用来存储一些比较小的键值对集合。

虽然SharedPreferences使用非常简便，但也是我们诟病比较多的存储方法。它的性能问题比较多，我可以轻松地说出它的“七宗罪”。

讲到这里，如果你对SharedPreferences机制还不熟悉的话，可以参考《彻底搞懂SharedPreferences》。

坦白来讲，系统提供的SharedPreferences的应用场景是用来存储一些非常简单、轻量的数据。我们不要使用它来存储过于复杂的数据，例如HTML、JSON等。而且SharedPreference的文件存储性能与文件大小相关，每个SP文件不能过大，我们不要将毫无关联的配置项保存在同一个文件中，同时考虑将频繁修改的条目单独隔离出来。

我们也可以替换通过复写Application的getSharedPreferences方法替换系统默认实现，比如优化卡顿、合并多次apply操作、支持跨进程操作等。具体如何替换呢？在今天的Sample中我也提供了一个简单替换实现。

public class MyApplication extends Application {
  @Override
  public SharedPreferences getSharedPreferences(String name, int mode)        
  {
     return SharedPreferencesImpl.getSharedPreferences(name, mode);
  }
}

对系统提供的SharedPreferences的小修小补虽然性能有所提升，但是依然不能彻底解决问题。基本每个大公司都会自研一套替代的存储方案，比如微信最近就开源了MMKV。

下面是MMKV对于SharedPreferences的“六要素”对比。

你可以参考MMKV的实现原理和性能测试报告，里面有一些非常不错的思路。例如利用文件锁保证跨进程的安全、使用mmap保证数据不会丢失、选用性能和存储空间更好的Protocol Buffer代替XML、支持增量更新等。

根据I/O优化的分析，对于频繁修改的配置使用mmap的确非常合适，使用者不用去理解apply()和commit()的差别，也不用担心数据的丢失。同时，我们也不需要每次都提交整个文件，整体性能会有很大提升。

第二，ContentProvider的使用。

为什么Android系统不把SharedPreferences设计成跨进程安全的呢？那是因为Android系统更希望我们在这个场景选择使用ContentProvider作为存储方式。ContentProvider作为Android四大组件中的一种，为我们提供了不同进程甚至是不同应用程序之间共享数据的机制。

Android系统中比如相册、日历、音频、视频、通讯录等模块都提供了ContentProvider的访问支持。它的使用十分简单，你可以参考官方文档。

当然，在使用过程也有下面几点需要注意。

ContentProvider的生命周期默认在Application onCreate()之前，而且都是在主线程创建的。我们自定义的ContentProvider类的构造函数、静态代码块、onCreate函数都尽量不要做耗时的操作，会拖慢启动速度。

可能很多同学都不知道ContentProvider还有一个多进程模式，它可以和AndroidManifest中的multiprocess属性结合使用。这样调用进程会直接在自己进程里创建一个push进程的Provider实例，就不需要跨进程调用了。需要注意的是，这样也会带来Provider的多实例问题。

ContentProvider在进行跨进程数据传递时，利用了Android的Binder和匿名共享内存机制。简单来说，就是通过Binder传递CursorWindow对象内部的匿名共享内存的文件描述符。这样在跨进程传输中，结果数据并不需要跨进程传输，而是在不同进程中通过传输的匿名共享内存文件描述符来操作同一块匿名内存，这样来实现不同进程访问相同数据的目的。

正如我前面I/O优化所讲的，基于mmap的匿名共享内存机制也是有代价的。当传输的数据量非常小的时候，可能不一定划算。所以ContentProvider提供了一种call函数，它会直接通过Binder来传输数据。

Android的Binder传输是有大小限制的，一般来说限制是1~2MB。ContentProvider的接口调用参数和call函数调用并没有使用匿名共享机制，比如要批量插入很多数据，那么就会出现一个插入数据的数组，如果这个数组太大了，那么这个操作就可能会出现数据超大异常。

虽然ContentProvider为应用程序之间的数据共享提供了很好的安全机制，但是如果ContentProvider是exported，当支持执行SQL语句时就需要注意SQL注入的问题。另外如果我们传入的参数是一个文件路径，然后返回文件的内容，这个时候也要校验合法性，不然整个应用的私有数据都有可能被别人拿到，在intent传递参数的时候可能经常会犯这个错误。

最后我给你总结一下ContentProvider的“六要素”优缺点。

总的来说，ContentProvider这套方案实现相对比较笨重，适合传输大的数据。

总结

虽然SharedPreferences和ContentProvider都是我们日常经常使用的存储方法，但是里面的确会有大大小小的暗坑。所以我们需要充分了解它们的优缺点，这样在工作中可以更好地使用和优化。

如何在合适的场景选择合适的存储方法是存储优化的必修课，你应该学会通过正确性、时间开销、空间开销、安全、开发成本以及兼容性这六大关键要素来分解某个存储方法。

在设计某个存储方案的时候也是同样的道理，我们无法同时把所有的要素都做得最好，因此要学会取舍和选择，在存储的世界里不存在全局最优解，我们要找的是局部的最优解。这个时候更应明确自己的诉求，大胆牺牲部分关键点的指标，将自己场景最关心的要素点做到最好。

课后作业

下面是MMKV给出的性能测试报告，你可以看到跟系统的SharedPreferences相比，主要差距在于写的速度。

没有实践就没有发言权，今天我们一起来尝试测试对比MMKV与系统SharedPreferences的性能差异。请将你的测试结果和分析体会，写在留言区跟同学们分享交流吧。

今天的练习Sample是通过复写Application的getSharedPreferences方法替换系统默认实现，这种方式虽然不是最好的方法，不过它主要的优点在于代码的侵入性比较低，无需修改太多的代码。

欢迎你点击“请朋友读”，把今天的内容分享给好友，邀请他一起学习。最后别忘了在评论区提交今天的作业，我也为认真完成作业的同学准备了丰厚的“学习加油礼包”，期待与你一起切磋进步哦。

评论