08 | Android 高级进阶(源码剖析篇) Square 高效易用的 IO 框架 okio（一）

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

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

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

okio 是 Square 开源的一个 Java IO 框架，是对 java.io 和 java.nio 的补充，提供了更灵活易用的接口来处理数据流的输入和输出，最开始它是作为 okhttp 的一个基础组件存在的，后面随着 okhttp 的不断发展逐渐剥离独立出来。我们知道，okio 和 okhttp 并不只局限在 Android 平台中使用，事实上，它们是 Java 平台通用的，在 Java 后端开发中也经常会用到，例如在著名的微服务框架 Spring Cloud 中，就可以通过配置使用 okhttp 来代替默认的 HttpClient，从而支持 HTTP/2。

IO 和 NIO

在正式介绍 okio 之前，我们有必要先来回顾一下 java.io 和 java.nio 的基础知识。I/O(input/output) 是计算机与外部世界之间的接口，也是一个应用与外部系统的接口。在 Java 编程中，I/O 被形象的表述为流的概念。所有的 I/O 操作可以被看作是字节在流中的移动，一次一个字节。流中的 I/O 操作既可以用来与外部系统联系，也可以用于内部实现字节和对象或者对象和字节之间的转换。

java.io（后面以 IO 代之） 和 java.nio（后面以 NIO 代之） 可以从以下三方面作一个对比：

IO 是基于数据流的，而 NIO 是基于数据块的

IO 和 NIO 最重要的区别就是数据的打包和传输方式。IO 是在流中处理数据，NIO 是在块中处理数据。

基于流的 I/O 系统一次处理一个或者多个字节，当输入流生产一个字节信息，输出流就消费一个字节的信息。我们可以很容易的为流数据创建过滤器，并通过把不同的过滤器串联起来从而实现复杂的流处理机制。当然，在流中字节信息是没有缓存的，因此你不能在流中来回的移动数据读取的指针，除非你先把字节信息在某个地方缓存起来。

基于块的 I/O 系统是在块中处理数据的，每一次操作都会生产或者消费一块数据，基于块比基于流的方式处理数据速度更快。你可以在缓冲区（Buffer）中来回移动数据读取或者写入指针，因此灵活性更强。但是我们在往缓冲区中写入更多数据之前需要确保缓冲区中的数据能够及时处理，从而不会造成数据的覆盖。因此，基于块的 I/O 系统相比基于流的 I/O 系统而言显得不怎么优雅和简洁。

IO 是同步的，NIO 是异步的

IO 中各种各样的流都是阻塞或者同步的，这意味着当一个线程调用流的 read() 或者 write() 方法时，在数据处理完之前该线程将始终处于阻塞的状态。而 NIO 是支持异步的，也就是一个线程收到数据的读或者写请求后，可以将数据处理发送给通道（Channel），同时不必等待数据处理完成就可以返回来继续处理其他请求。

API 的差异

为了让大家有个直观的印象，我们就来看看 IO 和 NIO 在读取一个文件时的代码，首先来看下 IO 是如何读取文件的，这里因为是读取一个 txt 文件，因此使用 Reader 类，其中 FileReader 底层是使用 InputStream 来读取文件的：

import java.io.BufferedReader;	
import java.io.FileReader;	
import java.io.IOException;	
	
public class WithoutNIOExample {	
    public static void main(String[] args) {	
        BufferedReader br = null;	
        String sCurrentLine = null;	
        try {	
            br = new BufferedReader(	
                    new FileReader("test.txt"));	
            while ((sCurrentLine = br.readLine()) != null) {	
                System.out.println(sCurrentLine);	
            }	
        } catch (IOException e) {	
            e.printStackTrace();	
        } finally {	
            try {	
                if (br != null)	
                    br.close();	
            } catch (IOException ex) {	
                ex.printStackTrace();	
            }	
        }	
    }	
}

NIO 读取文件时需要结合缓冲区（Buffer）和通道（Channel）一起使用，代码如下所示：

import java.io.IOException;	
import java.io.RandomAccessFile;	
import java.nio.ByteBuffer;	
import java.nio.channels.FileChannel;	
	
public class ReadFileWithFixedSizeBuffer {	
    public static void main(String[] args) throws IOException {	
        RandomAccessFile aFile = new RandomAccessFile	
                ("test.txt", "r");	
        FileChannel inChannel = aFile.getChannel();	
        ByteBuffer buffer = ByteBuffer.allocate(1024);	
        while (inChannel.read(buffer) > 0) {	
            buffer.flip();	
            for (int i = 0; i < buffer.limit(); i++) {	
                System.out.print((char) buffer.get());	
            }	
            buffer.clear();	
        }	
        inChannel.close();	
        aFile.close();	
    }	
}

okio

okio 自身定义了一系列的概念，本文我们先来对其中四个核心的概念进行简单的介绍。

ByteString 和 Buffer

okio 通过定义如下两种类型实现将一系列的功能通过简单的 API 包装起来：

• ByteString：不可变（immutable）的字节序列，简化了使用者对字节数据的操作，这个类能够实现将自身包含的字节数据编码为十六进制，base64 或者 UTF-8，或者反向实现解码操作。

• Buffer：可变（mutable）的字节序列，类似 ArrayList，我们不需要提前给 Buffer 设置大小。可以把 Buffer 当作一个队列，向它的尾部写入数据，从它的头部读取数据，完全不需要自己去管理指针位置，指针的读取范围和容量。

内部实现中，ByteString 和 Buffer 通过一些技巧减少了 CPU 和内存的消耗。例如当我们把一个普通的 String，编码为 UTF-8 的 ByteString 时，ByteString 将会缓存对编码前的 String 的引用，这样当后面要把这个 ByteString 解码为普通的 String 时，直接返回这个引用就行，完全不需要作多余的操作。

Buffer 内部实现是一个 segments 的链表结构，segments 你可以先理解为一块一块的数据，后面会进一步分析。当我们将数据从一个 Buffer 传递到传给另外一个 Buffer 时，底层实现并不是将数据从一个 Buffer 拷贝到另外一个 Buffer，而是直接修改数据所在 segments 的所有权。对于多线程应用场景这个特性尤其有用，例如监听网络请求的线程和具体处理请求的线程就可以通过这种方式传递数据，省去了数据拷贝的耗时。

Sources 和 Sinks

okio 定义了两个全新的概念来表示输入流和输出流：

• Sources：输入流，类似 java.io 中的 InputStream

• Sinks：输出流，类似 java.io 中的 OutputStream

当然，相比之下，Sources 和 Sinks 有以下特点：

... 更多内容请点击阅读原文继续阅读。