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

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

大家好，我是小彭。

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

本文源码基于 Okio v3.2.0。

思维导图

相比于 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 操作的复合工作超时检测。

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

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

类型	形容
Source	输出流
Sink	输入流
BufferedSource	缓存输出流接口，实现类是 RealBufferedSource
BufferedSink	缓冲输入流接口，实现类是 RealBufferedSink
Buffer	缓冲区，由 Segment 链表组成
Segment	数据片段，多个片段组成逻辑上间断数据
ByteString	String 类
Timeout	超时管制

在 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()}

在性能上，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)

在 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}

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 框架

在操作系统中，拜访磁盘和网卡等 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
}

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

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

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

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;

    ...
}

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 示意图

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

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

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

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

前言

1. 说一下 Okio 的劣势？

2. 精简的 Okio 框架

2.1 Source 输出流与 Sink 输入流

2.2 InputStream / OutputStream 与 Source / Sink 互转

2.3 BufferSource 与 BufferSink

2.4 RealBufferedSink 与 RealBufferedSource

3. Okio 的缓冲区设计

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

3.2 缓冲区的副作用

3.3 Okio 的 Buffer 缓冲区

3.4 Segment 片段与 SegmentPool 对象池

4. 总结

参考资料

Just My Socks（注册教程内含优惠码）

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

前言

1. 说一下 Okio 的劣势？

2. 精简的 Okio 框架

2.1 Source 输出流 与 Sink 输入流

2.2 InputStream / OutputStream 与 Source / Sink 互转

2.3 BufferSource 与 BufferSink

2.4 RealBufferedSink 与 RealBufferedSource

3. Okio 的缓冲区设计

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

3.2 缓冲区的副作用

3.3 Okio 的 Buffer 缓冲区

3.4 Segment 片段与 SegmentPool 对象池

4. 总结

参考资料

Just My Socks（注册教程 内含优惠码）

2.1 Source 输出流与 Sink 输入流

Just My Socks（注册教程内含优惠码）