读书笔记5-数据存储篇

本系列博文 基因而前微信高级工程师张绍文专栏 《Android开发高手课》的读书笔记。

文章所写内容是本人读完的感悟,须要原文的朋友请自行购买。

存储优化篇

Android分区

分区简单来讲就是将设备中的存储划分为一些互不重叠的部分，每一个部分均可以单独格式化，用做不一样的目的。

• /system: 操做系统预留,用来存储系统文件和框架的,系统升级和恢复时会擦除这一整块分区
• /data: 用来存储用户数据的地方,手机上恢复出厂设置的那个操做就只会擦除这部分数据
• /cache: 系统升级或者恢复时的备用分区
• /vendor: 用来存放手机厂商对Android系统的修改
• /storge: 内置或者外置的sdcard

数据存储须要考虑哪些要素

数据存储就是把特定的数据结构转化成能够被记录和还原的格式，这个数据格式能够是二进制的，也能够是 XML、JSON、Protocol Buffer 这些格式。

在选择数据存储的时候须要考虑的要素

数据存储的选项

• SharedPreferences
• ContentProvider
• 文件
• 数据库

SharedPreferences

使用场景

用于存储一些很是简单,轻量的数据。

优势

• 系统支持,使用简单
• 兼容性强

缺点

• 跨进程不安全
• 加载缓慢。SharedPreferences 文件的加载使用了异步线程，并且加载线程并无设置线程优先级，若是这个时候主线程读取数据就须要等待文件加载线程的结束
• 全量写入。不管是调用 commit() 仍是 apply()，即便咱们只改动其中的一个条目，都会把整个内容所有写到文件。并且即便咱们屡次写入同一个文件，SP 也没有将屡次修改合并为一次，这也是性能差的重要缘由之一。

基于以上缘由,各大公司都会有对应的一个替代的存储方案,好比微信的MMKV

ContentProvider

使用场景

跨进程,跨应用程序之间的大数据量交互,整体来讲ContentProvider的总体框架仍是不错的,目前市面上好像也没有什么自研的架构替代。

须要注意的点

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

对象的序列化

Serializable

java原生的序列化机制,其自己是经过 ObjectInputStream 和 ObjectOutputStream 来实现的,因为在序列化过程当中使用了大量的反射和临时变量使得性能降低,文件体积变大。

须要注意的点

• 不被序列化的字段。类的 static 变量以及被声明为 transient 的字段，默认的序列化机制都会忽略该字段，不会进行序列化存储。固然咱们也可使用进阶的 writeReplace 和 readResolve 方法作自定义的序列化存储。
• serialVersionUID。在类实现了 Serializable 接口后，咱们须要添加一个 Serial Version ID，它至关于类的版本号。这个 ID 咱们能够显式声明也可让编译器本身计算。一般我建议显式声明会更加稳妥，由于隐式声明假如类发生了一点点变化，进行反序列化都会因为 serialVersionUID 改变而致使 InvalidClassException 异常。
• 构造方法。Serializable 的反序列默认是不会执行构造函数的，它是根据数据流中对 Object 的描述信息建立对象的。若是一些逻辑依赖构造函数，就可能会出现问题，例如一个静态变量只在构造函数中赋值，固然咱们也能够经过进阶方法作自定义的反序列化修改。

Parcelable

主要解决Serializable性能低下的问题。

使用Parcelable比Serializable须要多添加一些自定义代码，正是由于这些代码,使得Parcelable在序列化的时候不须要采用大量反射这种耗时的行为,从而提升性能。

须要注意的点

使用Parcelable进行永久存储的话,会存在一些问题。

• 系统版本的兼容性。因为 Parcelable 设计本意是在内存中使用的，咱们没法保证全部 Android 版本的Parcel.cpp实现都彻底一致。若是不一样系统版本实现有所差别，或者有厂商修改了实现，可能会存在问题。
• 数据先后兼容性。Parcelable 并无版本管理的设计，若是咱们类的版本出现升级，写入的顺序及字段类型的兼容都须要格外注意，这也带来了很大的维护成本。

通常来讲，若是须要持久化存储的话，通常仍是不得不选择性能更差的 Serializable 方案。

Serial

Twitter开源的Serial保留了Serializable和Parcelable的大部分优势

数据的序列化

Serial 性能看起来还不错，可是对象的序列化要记录的信息仍是比较多，在操做比较频繁的时候，对应用的影响仍是很多的，这个时候咱们能够选择使用数据的序列化。

JSON

优势

• 相比对象序列化方案，速度更快，体积更小。
• 相比二进制的序列化方案，结果可读，易于排查问题。
• 使用方便，支持跨平台、跨语言，支持嵌套引用。

市面上可用的框架有Android自带的JSON库,Google的Gson,阿里的FastJson,美团的MSON

总的来讲Gson的兼容性最好,数据量极大时,FastJson的性能最佳。

Protocol Buffers

二进制序列化方案,数据量庞大的时候性能优于JSON,

数据库优化

推荐使用自带的SQLite,Realm或者Google的LevelDB。

这部份内容在张老师文中提到的可能是线程并发,索引优化,page和缓存处理等。比较深,这里就不提了。