07 | Android 高级进阶(源码剖析篇) Twitter 的高性能序列化框架 Serial（三）

作者简介：ASCE1885， 《Android 高级进阶》作者。

本文由于潜在的商业目的，未经授权不开放全文转载许可，谢谢！

本文分析的源码版本已经 fork 到我的 Github。

本文开始我们就来探讨下 Serial 序列化的奥秘，也就是数据流的处理，首先看下 Serial 流处理核心的类层次结构：

其中抽象类 SerializerStream 用于定义数据流（无论是输入流还是输出流）操作的通用逻辑，目前只有一个方法 isPeekSupported，用来判断当前流是否支持“窥探”操作，主要指的是输入流是否支持在不消费流数据的前提下可以对输入流作某些操作，例如读取流中指定位置（Position）的某些字节信息。相信读者还记得第一篇文章中介绍过的 SerializerInput.peekType()，如果当前输入流 isPeekSupported 为 true，那么我们就可以调用输入流的 peekType 方法来判断流中接下来要读取数据类型是什么，从而执行相应的业务逻辑操作。

抽象类 SerializerInput 和 SerializerOutput 分别定义了输入流和输出流的规范，主要是各种数据类型的读取和写入方法，涉及基本数据类型，String 类型，字节数组 byte[]，对象 Object，以及标识对象开始和结束的标记。这些我们在介绍它们的子类时会详细介绍，从上图中可以看到有两种类型的子类：

• LegacySerializerInput/Output：读数据使用 java.io.ObjectInput，写数据使用 java.io.ObjectOutput，属于较传统的读写方式，第一篇文章介绍过的 Java 传统序列化方式 Serializable 和 Externalizable 底层就是基于这种方式实现对象在磁盘的读写。

• ByteBufferSerializerInput/Output：读写数据都使用 java.nio.ByteBuffer，Serial 大多数情况都推荐使用这种方式。

下面我们分别来介绍这两种方式的具体实现。

LegacySerializerInput/Output

先有序列化把对象写入到磁盘，才会有反序列化从数据从磁盘还原成对象，因此，我们先来看序列化相关的方法。由于基本数据类型的读写直接调用 ObjectInput 和 ObjectOutput 的相应方法就可以，因此我们不做过多的介绍，这里以读写 int 类型为例看下代码即可，序列化和反序列化是成对的操作，后面我们分析时代码会放在一块进行对比：

1. // LegacySerializerInput.java

2. @Override

3. public int readInt() throws IOException {

4.    return mInput.readInt();

5. }

6. // LegacySerializerOutput.java

7. @Override

8. @NotNull

9. public LegacySerializerOutput writeInt(int val) throws IOException {

10.    mOutput.writeInt(val);

11.    return this; // 链式调用

12. }

String 类型和字节数组 byte[] 的读写也类似，都需要增加对 null 的处理，我们来看下 String 类型的代码逻辑就行。序列化时首先判断传入的字符串是否为 null，是的话就写入一个字节的 NULLOBJECT 标识位；不为空时则先写入一个字节的 NOTNULL_OBJECT 标识位，然后才写入真正的字符串数据：

1. // LegacySerializerDefs.java

2. protected static final byte NULL_OBJECT = 0;

3. protected static final byte NOT_NULL_OBJECT = 1;

4. // LegacySerializerOutput.java

5. @Override

6. @NotNull

7. public LegacySerializerOutput writeString(@Nullable String val) throws IOException {

8.    if (val == null) {

9.        writeByte(LegacySerializerDefs.NULL_OBJECT);

10.    } else {

11.        writeByte(LegacySerializerDefs.NOT_NULL_OBJECT);

12.        mOutput.writeUTF(val);

13.    }

14.    return this;

15. }

反序列化时首先从输入流中读取一个字节的数据，然后判断是否等于 NULL_OBJECT，是的话说明序列化时写入的是一个 null 值，否则读取真正的字符串信息，代码如下所示：

1. @Override

2. @Nullable

3. public String readString() throws IOException {

4.    final byte nullIndicator = readByte();

5.    if (nullIndicator == LegacySerializerDefs.NULL_OBJECT) {

6.        return null;

7.    }

8.    return mInput.readUTF();

9. }

接下来我们再来看看对象开始和结束的标记位的读写，可以看到，在这个实现中，只是写入了版本号信息而已，没有其他操作。

1. // LegacySerializerOutput.java

2. @Override

3. @NotNull

4. public LegacySerializerOutput writeObjectStart(int versionNumber) throws IOException {

5.    if (mUseVersionNumbers) {

6.        writeInt(versionNumber);

7.    }

8.    return this;

9. }

10. @NotNull

11. @Override

12. public LegacySerializerOutput writeObjectStart(int versionNumber, @NotNull String className) throws IOException {

13.    return writeObjectStart(versionNumber);

14. }

15. @Override

16. @NotNull

17. public LegacySerializerOutput writeObjectEnd() {

18.    return this;

19. }

20. // LegacySerializerInput.java

21. @Override

22. public int readObjectStart() throws IOException {

23.    if (mUseVersionNumbers) {

24.        return mInput.readInt();

25.    }

26.    return 0;

27. }

ByteBufferSerializerInput/Output

基本数据类型的序列化和反序列化过程是类似的，我们以 float 为例进行说明，首先需要注意，在每次写入数据到 ByteBuffer 之前，都需要判断当前 ByteBuffer 实例是否有足够的空间，空间不足时需要进行双倍的扩容，完成后再递归判断扩容后空间是否足够，代码如下所示：

1. private void ensureCapacity(int sizeNeeded) {

2.    if (mByteBuffer.remaining() < sizeNeeded) {

3.        // 获取当前写入的位置

4.        final int position = mByteBuffer.position();

5.        final byte[] bufferContents = mByteBuffer.array();

6.        // 双倍扩容

7.        final byte[] newBufferContents = new byte[2 * mByteBuffer.capacity()];

8.        // 将原来数组中的数据拷贝到扩容后的数组中

9.        System.arraycopy(bufferContents, 0, newBufferContents, 0, position);

10.        final ByteBuffer newBuffer = ByteBuffer.wrap(newBufferContents);

11.        newBuffer.position(position);

12.        mByteBuffer = newBuffer;

13.        // 递归判断扩容后空间是否足够

14.        ensureCapacity(sizeNeeded);

15.    }

16. }

float 数据序列化时，如果它的值为 0f，那么直接记录一个 HEADERFLOATZERO 标记即可，这样可以节省存储空间；如果不为 0f，那么先记录一个 HEADER_FLOAT 标记，然后记录真实的 float 值即可。

1. // ByteBufferSerializerDefs.java

2. public static final byte HEADER_FLOAT_ZERO = makeHeader(TYPE_FLOAT, SUBTYPE_DEFAULT);

3. // ByteBufferSerializerOutput.java

4. public ByteBufferSerializerOutput writeFloat(float val) {

5.    if (val == 0f) {

6.        writeHeader(ByteBufferSerializerDefs.HEADER_FLOAT_ZERO);

7.    } else {

8.        writeHeader(ByteBufferSerializerDefs.HEADER_FLOAT);

9.        ensureCapacity(ByteBufferSerializerDefs.SIZE_FLOAT);

10.        mByteBuffer.putFloat(val);

11.    }

12.    return this;

13. }

反序列化时，顺序反过来即可，先读取一个字节的头部标记，如果等于值为 0f 的标记，就返回 0f，否则读取真实的 float 值。

1. public float readFloat() throws IOException {

2.    try {

3.        final byte subtype = readHeader(SerializerDefs.TYPE_FLOAT);

4.        if (subtype == ByteBufferSerializerDefs.SUBTYPE_DEFAULT) {

5.            return 0f;

6.        }

7.        return mByteBuffer.getFloat();

8.    } catch (BufferUnderflowException ignore) {

9.        throw new EOFException();

10.    }

11. }

在 LegacySerializerInput/Output 中使用的 ObjectInput 和 ObjectOutput 支持 String 类型的读写，因此处理起 String 类型时很简单，到了 ByteBufferSerializerInput/Output，由于使用的 ByteBuffer 只提供对基本数据类型的读写，不直接支持 String 类型的读写，因此，就需要我们自己来处理了，这涉及到 Unicode 字符集和 UTF 编码相关问题。

我们知道，Unicode 是字符集，而 UTF-8/UTF-16/UTF-32是编码方案。Unicode 字符集的标准编码方案是 UTF-16，它使用 2 字节表示一个 Unicode 字符，JVM 规范明确规定 Java 内部的字符（char 类型）使用 UTF-16 编码的。UTF-32 使用 4 个字节表示一个 Unicode 字符，UTF-8 是一种不定长的 Unicode 编码方式，一个字符可能占用 1 个字节，也有可能占用 2，3，4 个字节。

Unicode 的编码空间是 U+0000～U+10FFFF（1114112 个码位），根据是否可以用来映射 Unicode 字符，可以分为两部分：

• 其中有 1112064 个码位可以用来映射 Unicode 字符

• 其中有 2048 个码位是永久保留的，不进行 Unicode 字符的映射，这个码位区间是 U+D800～U+DFFF。

• 说明一下，码位（Code Point）就是字符的数字表现形式

Unicode 编码空间可以划分为 17 个平面（plane），每个平面包含 2^16（65536）个码位，其中第一个平面习惯称为基本多语言平面（Basic Multilingual Plane，BMP），也称为平面零（Plane 0）；其他平面统一称为辅助平面（Supplementary Planes）。前面说到的从 U+D800～U+DFFF 总共 2048 个保留码位就位于基本多语言平面内，UTF-16 利用这些保留位对辅助平面中的字符的码位进行编码。 ... 更多内容请点击阅读原文继续阅读。