关于android:Android-IO-框架-Okio-的实现原理到底哪里-OK

本文已收录到 AndroidFamily，技术和职场问题，请关注公众号 [彭旭锐] 发问。

前言

大家好，我是小彭。

明天，咱们来探讨一个 Square 开源的 I/O 框架 Okio，咱们最开始接触到 Okio 框架还是源于 Square 家的 OkHttp 网络框架。那么，OkHttp 为什么要应用 Okio，它相比于 Java 原生 IO 有什么区别和劣势？明天咱们就围绕这些问题开展。

本文源码基于 Okio v3.2.0。

思维导图

1. 说一下 Okio 的劣势？

相比于 Java 原生 IO 框架，我认为 Okio 的劣势次要体现在 3 个方面：

• 1、精简且全面的 API： 原生 IO 应用装璜模式，例如应用 BufferedInputStream 装璜 FileInputStream 文件输出流，能够加强流的缓冲性能。然而原生 IO 的装璜器过于宏大，须要辨别字节、字符流、字节数组、字符数组、缓冲等多种装璜器，而这些恰好又是最罕用的根底装璜器。相较之下，Okio 间接在 BufferedSource 和 BufferedSink 中聚合了原生 IO 中所有根底的装璜器，使得框架更加精简；
• 2、基于共享的缓冲区设计： 因为 IO 零碎调用存在上下文切换的性能损耗，为了缩小零碎调用次数，应用层往往会采纳缓冲区策略。然而缓冲区又会存在副作用，当数据从一个缓冲区转移到另一个缓冲区时须要拷贝数据，这种内存中的拷贝显得没有必要。而 Okio 采纳了基于共享的缓冲区设计，在缓冲区间转移数据只是共享 Segment 的援用，而缩小了内存拷贝。同时 Segment 也采纳了对象池设计，缩小了内存调配和回收的开销；
• 3、超时机制： Okio 补救了局部 IO 操作不反对超时检测的缺点，而且 Okio 不仅反对单次 IO 操作的超时检测，还反对蕴含屡次 IO 操作的复合工作超时检测。

上面，咱们将从这三个劣势开展剖析：

2. 精简的 Okio 框架

先用一个表格总结 Okio 框架中次要的类型：

2.1 Source 输出流 与 Sink 输入流

在 Java 原生 IO 中有四个根底接口，别离是：

• 字节流： InputStream 输出流和 OutputStream 输入流；
• 字符流： Reader 输出流和 Writer 输入流。

而在 Okio 更加精简，只有两个根底接口，别离是：

• 流： Source 输出流和 Sink 输入流。

Source.kt

interface Source : Closeable {// 从输出流读取数据到 Buffer 中（Buffer 等价于 byte[] 字节数组）// 返回值：-1：输出内容完结
    @Throws(IOException::class)
    fun read(sink: Buffer, byteCount: Long): Long

    // 超时管制（详细分析见后续文章）fun timeout(): Timeout

    // 敞开流
    @Throws(IOException::class)
    override fun close()}

Sink.java

actual interface Sink : Closeable, Flushable {// 将 Buffer 的数据写入到输入流中（Buffer 等价于 byte[] 字节数组）@Throws(IOException::class)
    actual fun write(source: Buffer, byteCount: Long)

    // 清空输入缓冲区
    @Throws(IOException::class)
    actual override fun flush()

    // 超时管制（详细分析见后续文章）actual fun timeout(): Timeout

    // 敞开流
    @Throws(IOException::class)
    actual override fun close()}

2.2 InputStream / OutputStream 与 Source / Sink 互转

在性能上，InputStream – Source 和 OutputStream – Sink 别离是等价的，而且是互相兼容的。联合 Kotlin 扩大函数，两种接口之间的转换会十分不便：

• source()： InputStream 转 Source，实现类是 InputStreamSource；
• sink()： OutputStream 转 Sink，实现类是 OutputStreamSink；

比拟不了解的是： Okio 没有提供 InputStreamSource 和 OutputStreamSink 转回 InputStream 和 OutputStream 的办法，而是须要先转换为 BufferSource 与 BufferSink，再转回 InputStream 和 OutputStream。

• buffer()： Source 转 BufferedSource，Sink 转 BufferedSink，实现类别离是 RealBufferedSource 和 RealBufferedSink。

示例代码

// 原生 IO -> Okio
val source = FileInputStream(File("")).source()
val bufferSource = FileInputStream(File("")).source().buffer()

val sink = FileOutputStream(File("")).sink()
val bufferSink = FileOutputStream(File("")).sink().buffer()

// Okio -> 原生 IO
val inputStream = bufferSource.inputStream()
val outputStream = bufferSink.outputStream()

JvmOkio.kt

// InputStream -> Source
fun InputStream.source(): Source = InputStreamSource(this, Timeout())

// OutputStream -> Sink
fun OutputStream.sink(): Sink = OutputStreamSink(this, Timeout())

private class InputStreamSource(
    private val input: InputStream,
    private val timeout: Timeout
) : Source {override fun read(sink: Buffer, byteCount: Long): Long {if (byteCount == 0L) return 0
        require(byteCount >= 0) {"byteCount < 0: $byteCount"}
        try {
            // 同步超时监控（详细分析见后续文章）timeout.throwIfReached()
            // 读入 Buffer
            val tail = sink.writableSegment(1)
            val maxToCopy = minOf(byteCount, Segment.SIZE - tail.limit).toInt()
            val bytesRead = input.read(tail.data, tail.limit, maxToCopy)
            if (bytesRead == -1) {if (tail.pos == tail.limit) {
                    // We allocated a tail segment, but didn't end up needing it. Recycle!
                    sink.head = tail.pop()
                    SegmentPool.recycle(tail)
                }
                return -1
            }
            tail.limit += bytesRead
            sink.size += bytesRead
            return bytesRead.toLong()} catch (e: AssertionError) {if (e.isAndroidGetsocknameError) throw IOException(e)
            throw e
        }
  }

  override fun close() = input.close()

  override fun timeout() = timeout

  override fun toString() = "source($input)"
}

private class OutputStreamSink(
    private val out: OutputStream,
    private val timeout: Timeout
) : Sink {override fun write(source: Buffer, byteCount: Long) {checkOffsetAndCount(source.size, 0, byteCount)
        var remaining = byteCount
        // 写出 Buffer
        while (remaining > 0) {
            // 同步超时监控（详细分析见后续文章）timeout.throwIfReached()
            // 取无效数据量和残余输出量的较小值
            val head = source.head!!
            val toCopy = minOf(remaining, head.limit - head.pos).toInt()
            out.write(head.data, head.pos, toCopy)

            head.pos += toCopy
            remaining -= toCopy
            source.size -= toCopy

            // 指向下一个 Segment
            if (head.pos == head.limit) {source.head = head.pop()
                SegmentPool.recycle(head)
            }
        }
    }

    override fun flush() = out.flush()

    override fun close() = out.close()

    override fun timeout() = timeout

    override fun toString() = "sink($out)"
}

Okio.kt

// Source -> BufferedSource
fun Source.buffer(): BufferedSource = RealBufferedSource(this)

// Sink -> BufferedSink
fun Sink.buffer(): BufferedSink = RealBufferedSink(this)

2.3 BufferSource 与 BufferSink

在 Java 原生 IO 中，为了缩小零碎调用次数，咱们个别不会间接调用 InputStream 和 OutputStream，而是会应用 BufferedInputStream 和 BufferedOutputStream 包装类减少缓冲性能。

例如，咱们心愿采纳带缓冲的形式读取字符格局的文件，则须要先将文件输出流包装为字符流，再包装为缓冲流：

Java 原生 IO 示例

// 第一层包装
FileInputStream fis = new FileInputStream(file);
// 第二层包装
InputStreamReader isr = new InputStreamReader(new FileInputStream(file), "UTF-8");
// 第三层包装
BufferedReader br = new BufferedReader(isr);
String line;
while ((line = br.readLine()) != null) {...}
// 省略 close

同理，咱们在 Okio 中个别也不会间接调用 Source 和 Sink，而是会应用 BufferedSource 和 BufferedSink 包装类减少缓冲性能：

Okio 示例

val bufferedSource = file.source()/* 第一层包装 */.buffer()/* 第二层包装 */
while (!bufferedSource.exhausted()) {val line = bufferedSource.readUtf8Line();
    ...
}
// 省略 close

网上有材料说 Okio 没有应用装璜器模式，所以类构造更简略。 这么说其实不太精确，装璜器模式自身并不是毛病，而且从 BufferedSource 和 BufferSink 能够看出 Okio 也应用了装璜器模式。 严格来说是原生 IO 的装璜器过于宏大，而 Okio 的装璜器更加精简。

比方原生 IO 罕用的流就有这么多：

• 原始流： FileInputStream / FileOutputStream 与 SocketInputStream / SocketOutputStream；
• 根底接口（辨别字节流和字符流）： InputStream / OutputStream 与 Reader / Writer；
• 缓存流： BufferedInputStream / BufferedOutputStream 与 BufferedReader / BufferedWriter；
• 根本类型： DataInputStream / DataOutputStream；
• 字节数组和字符数组： ByteArrayInputStream / ByteArrayOutputStream 与 CharArrayReader / CharArrayWriter；
• 此处省略一万个字。

原生 IO 框架

而这么多种流在 Okio 里还剩下多少呢？

• 原始流： FileInputStream / FileOutputStream 与 SocketInputStream / SocketOutputStream；
• 根底接口： Source / Sink；
• 缓存流： BufferedSource / BufferedSink。

Okio 框架

就问你服不服？

而且你看哈，这些都是平时业务开发中最常见的根本类型，原生 IO 把它们都拆离开了，让问题复杂化了。反观 Okio 间接在 BufferedSource 和 BufferedSink 中聚合了原生 IO 中根本的性能，而不再须要辨别字节、字符、字节数组、字符数组、根底类型等等装璜器，的确让框架更加精简。

BufferedSource.kt

actual interface BufferedSource : Source, ReadableByteChannel {

    actual val buffer: Buffer

    // 读取 Int
    @Throws(IOException::class)
    actual fun readInt(): Int

    // 读取 String
    @Throws(IOException::class)
    fun readString(charset: Charset): String

    ...

    fun inputStream(): InputStream}

BufferedSink.kt

actual interface BufferedSink : Sink, WritableByteChannel {

    actual val buffer: Buffer

    // 写入 Int
    @Throws(IOException::class)
    actual fun writeInt(i: Int): BufferedSink

    // 写入 String
    @Throws(IOException::class)
    fun writeString(string: String, charset: Charset): BufferedSink

    ...

    fun outputStream(): OutputStream}

2.4 RealBufferedSink 与 RealBufferedSource

BufferedSource 和 BufferedSink 还是接口，它们的真正的实现类是 RealBufferedSource 和 RealBufferedSink。能够看到，在实现类中会创立一个 Buffer 缓冲区，在输出和输入的时候，都会借助 “Buffer 缓冲区” 缩小零碎调用次数。

RealBufferedSource.kt

internal actual class RealBufferedSource actual constructor(
    // 装璜器模式
    @JvmField actual val source: Source
) : BufferedSource {

    // 创立输出缓冲区
    @JvmField val bufferField = Buffer()

    // 带缓冲地读取（全副数据）override fun readString(charset: Charset): String {buffer.writeAll(source)
        return buffer.readString(charset)
    }

    // 带缓冲地读取（byteCount）override fun readString(byteCount: Long, charset: Charset): String {require(byteCount)
        return buffer.readString(byteCount, charset)
    }
}

RealBufferedSink.kt

internal actual class RealBufferedSink actual constructor(
    // 装璜器模式
    @JvmField actual val sink: Sink
) : BufferedSink {

    // 创立输入缓冲区
    @JvmField val bufferField = Buffer()

    // 带缓冲地写入（全副数据）override fun writeString(string: String, charset: Charset): BufferedSink {buffer.writeString(string, charset)
        return emitCompleteSegments()}

    // 带缓冲地写入（beginIndex - endIndex)
    override fun writeString(
        string: String,
        beginIndex: Int,
        endIndex: Int,
        charset: Charset
    ): BufferedSink {buffer.writeString(string, beginIndex, endIndex, charset)
        return emitCompleteSegments()}
}

至此，Okio 根本框架剖析完结，用一张图总结：

Okio 框架

3. Okio 的缓冲区设计

3.1 应用缓冲区缩小零碎调用次数

在操作系统中，拜访磁盘和网卡等 IO 操作须要通过零碎调用来执行。零碎调用实质上是一种软中断，过程会从用户态陷入内核态执行中断处理程序，实现 IO 操作后再从内核态切换回用户态。

能够看到，零碎调用存在上下文切换的性能损耗。为了缩小零碎调用次数，应用层往往会采纳缓冲区策略：

以 Java 原生 IO BufferedInputStream 为例，会通过一个 byte[] 数组作为数据源的输出缓冲，每次读取数据时会读取更多数据到缓冲区中：

• 如果缓冲区中存在无效数据，则间接从缓冲区数据读取；
• 如果缓冲区不存在无效数据，则先执行零碎调用填充缓冲区（fill），再从缓冲区读取数据；
• 如果要读取的数据量大于缓冲区容量，就会跳过缓冲区间接执行零碎调用。

输入流 BufferedOutputStream 也相似，输入数据时会优先写到缓冲区，当缓冲区满或者手动调用 flush() 时，再执行零碎调用写出数据。

伪代码

// 1. 输出
fun read(byte[] dst, int len) : Int {
    // 缓冲区无效数据量
    int avail = count - pos
    if(avail <= 0) {if(len >= 缓冲区容量) {
            // 间接从输出流读取
            read(输出流 in, dst, len)
        }
        // 填充缓冲区
        fill(数据源 in, 缓冲区)
    }
    // 本次读取数据量，不超过可用容量
    int cnt = (avail < len) ? avail : len?
    read(缓冲区, dst, cnt)
    // 更新缓冲区索引
    pos += cnt
    return cnt
}

// 2. 输入
fun write(byte[] src, len) {if(len > 缓冲区容量) {
        // 先将缓冲区写出
        flush(缓冲区)
        // 间接写出数据
        write(输入流 out, src, len)
    }
    // 缓冲区残余容量
    int left = 缓冲区容量 - count
    if(len > 缓冲区残余容量) {
        // 先将缓冲区写出
        flush(缓冲区)
    }
    // 将数据写入缓冲区
    write(缓冲区, src, len)
    // 更新缓冲区已增加数据容量
    count += len
}

3.2 缓冲区的副作用

确实，缓冲区策略能无效地缩小零碎调用次数，不至于读取一个字节都须要执行一次零碎调用，大多数状况下体现良好。但思考一种“双流操作”场景，即从一个输出流读取，再写入到一个输入流。回顾方才讲的缓存策略，此时的数据转移过程为：

• 1、从输出流读取到缓冲区；
• 2、从输出流缓冲区拷贝到 byte[]（拷贝）
• 3、将 byte[] copy 到输入流缓冲区（拷贝）；
• 4、将输入流缓冲区写入到输入流。

如果这两个流都应用了缓冲区设计，那么数据在这两个内存缓冲区之间互相拷贝，就显得没有必要。

3.3 Okio 的 Buffer 缓冲区

Okio 当然也有缓冲区策略，如果没有就会存在频繁零碎调用的问题。

Buffer 是 RealBufferedSource 和 RealBufferedSink 的数据缓冲区。尽管在实现上与原生 BufferedInputStream 和 BufferedOutputStream 不一样，但在性能上是一样的。区别在于：

• 1、BufferedInputStream 中的缓冲区是 “一个固定长度的字节数组”，数据从一个缓冲区转移到另一个缓冲区须要拷贝；
• 2、Buffer 中的缓冲区是 “一个 Segment 双向循环链表”，每个 Segment 对象是一小段字节数组，依附 Segment 链表的程序组成逻辑上的间断数据。这个 Segment 片段是 Okio 高效的要害。

Buffer.kt

actual class Buffer : BufferedSource, BufferedSink, Cloneable, ByteChannel {

    // 缓冲区（Segment 双向链表）@JvmField internal actual var head: Segment? = null

    // 缓冲区数据量
    @get:JvmName("size")
    actual var size: Long = 0L
        internal set

    override fun buffer() = this

    actual override val buffer get() = this}

比照 BufferedInputStream：

BufferedInputStream.java

public class BufferedInputStream extends FilterInputStream {

    // 缓冲区的默认大小（8KB）private static int DEFAULT_BUFFER_SIZE = 8192;

    // 输出缓冲区（固定长度的数组）protected volatile byte buf[];

    // 无效数据起始位，也是读数据的起始位
    protected int pos;

    // 无效数据量，pos + count 是写数据的起始位
    protected int count;

    ...
}

3.4 Segment 片段与 SegmentPool 对象池

Segment 中的字节数组是能够 “共享” 的，当数据从一个缓冲区转移到另一个缓冲区时，能够共享数据援用，而不肯定须要拷贝数据。

Segment.kt

internal class Segment {

    companion object {
        // 片段的默认大小（8KB）const val SIZE = 8192
        // 最小共享阈值，超过 1KB 的数据才会共享
        const val SHARE_MINIMUM = 1024
    }

    // 底层数组
    @JvmField val data: ByteArra
    // 无效数据的起始位，也是读数据的起始位
    @JvmField var pos: Int = 0
    // 无效数据的结束位，也是写数据的起始位
    @JvmField var limit: Int = 0
    // 共享标记位
    @JvmField var shared: Boolean = false
    // 宿主标记位
    @JvmField var owner: Boolean = false
    // 后续指针
    @JvmField var next: Segment? = null
    // 前驱指针
    @JvmField var prev: Segment? = null

    constructor() {
        // 默认结构 8KB 数组（为什么默认长度是 8KB）this.data = ByteArray(SIZE)
        // 宿主标记位
        this.owner = true
        // 共享标记位
        this.shared = false
    }
}

另外，Segment 还应用了对象池设计，被回收的 Segment 对象会缓存在 SegmentPool 中。SegmentPool 外部保护了一个被回收的 Segment 对象单链表，缓存容量的最大值是 MAX_SIZE = 64 * 1024，也就相当于 8 个默认 Segment 的长度：

SegmentPool.kt

// object：全局单例
internal actual object SegmentPool {

    // 缓存容量
    actual val MAX_SIZE = 64 * 1024

    // 头节点
    private val LOCK = Segment(ByteArray(0), pos = 0, limit = 0, shared = false, owner = false)

    ...
}

Segment 示意图

4. 总结

• 1、Okio 将原生 IO 多种根底装璜器聚合在 BufferedSource 和 BufferedSink，使得框架更加精简；
• 2、为了缩小零碎调用次数的同时，应用层 IO 框架会应用缓存区设计。而 Okio 应用了基于共享 Segment 的缓冲区设计，缩小了在缓冲区间转移数据的内存拷贝；
• 3、Okio 补救了局部 IO 操作不反对超时检测的缺点，而且 Okio 不仅反对单次 IO 操作的超时检测，还反对蕴含屡次 IO 操作的复合工作超时检测。

对于 Okio 超时机制的详细分析，咱们在 下一篇文章 里探讨。请关注。

参考资料

• Github · Okio
• Okio 官网
• Okio 源码学习剖析 —— 川峰 著
• Okio 好在哪？—— MxsQ 著