Android IO 框架 Okio 的实现原理，到底哪里 OK？

news2024/11/28 10:59:33

本文已收录到 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 框架中主要的类型：

类型描述
Source输入流
Sink输出流
BufferedSource缓存输入流接口，实现类是 RealBufferedSource
BufferedSink缓冲输出流接口，实现类是 RealBufferedSink
Buffer缓冲区，由 Segment 链表组成
Segment数据片段，多个片段组成逻辑上连续数据
ByteStringString 类
Timeout超时控制

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 著

本文来自互联网用户投稿，该文观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处：http://www.coloradmin.cn/o/335723.html

如若内容造成侵权/违法违规/事实不符，请联系多彩编程网进行投诉反馈，一经查实，立即删除！

相关文章

C4--Vivado添加列表中不存在的FLash器件2023-02-10

C4--Vivado添加列表中不存在的FLash器件2023-02-10

以华邦SPI FLASH W25Q128JVEIQ为例进行说明。&#xff08;其他Flash添加步骤一致&#xff09; 1.本地vivado安装目录D:\Softwares\xlinx_tools\Vivado\2020.2\data\xicom下&#xff0c;找到xicom_cfgmem_part_table.csv文件&#xff0c;这个表与vivado hardware manager中的器…
阅读更多...
pixhawk2.4.8-APM固件-MP地面站配置过程记录

pixhawk2.4.8-APM固件-MP地面站配置过程记录

目录一、硬件准备二、APM固件、MP地面站下载三、地面站配置1 刷固件2 机架选择3 加速度计校准4 指南针校准5 遥控器校准6 飞行模式7 紧急断电&无头模式8 基础参数设置9 电流计校准10 电调校准11 起飞前检查&#xff08;每一项都非常重要&#xff09;12 飞行经验四、遇到的问…
阅读更多...
同步线程

同步线程

↵ 由于这节内容资料比较少&#xff0c;所以以下内容总结自Qt官方文献&#xff0c;在文章最后会给出相应链接。 线程的目的是允许并行运行&#xff0c;但有时线程必须停止等待其他线程。例如&#xff0c;如果两个线程尝试访问同一个变量&#xff0c;这样的话结果是未定义的。强…
阅读更多...
【0基础学爬虫】爬虫基础之爬虫的基本介绍

【0基础学爬虫】爬虫基础之爬虫的基本介绍

大数据时代&#xff0c;各行各业对数据采集的需求日益增多&#xff0c;网络爬虫的运用也更为广泛&#xff0c;越来越多的人开始学习网络爬虫这项技术&#xff0c;K哥爬虫此前已经推出不少爬虫进阶、逆向相关文章&#xff0c;为实现从易到难全方位覆盖&#xff0c;特设【0基础学…
阅读更多...
Jmeter in Linux - 在Linux系统使用Jmeter的坑

Jmeter in Linux - 在Linux系统使用Jmeter的坑

Jmeter in Linux - 在Linux系统使用Jmeter的坑Jmeter in Linux系列目录&#xff1a;o.a.j.JMeter: Error in NonGUIDriver起因错误分析&#xff1a;解决方案&#xff1a;解析日志没有展示请求和响应信息起因解决方案&#xff1a;注意Jmeter in Linux系列目录&#xff1a; 【如…
阅读更多...
ChatGPT 爆火！谷歌、微软、百度纷纷下场？

ChatGPT 爆火！谷歌、微软、百度纷纷下场？

近日&#xff0c;智能聊天机器人ChatGPT的爆火引发了国内外网友的热烈讨论&#xff0c;上线两个月后&#xff0c;用户数量达到1亿。2月8日下午&#xff0c;巨大的访问量让系统一度崩溃。 服务重新开放后&#xff0c;我向ChatGPT询问了如何快速扩容&#xff0c;它显然是知道云端…
阅读更多...
CSS从入门到精通专栏简介

CSS从入门到精通专栏简介

先让我们来欣赏几个精美的网站&#xff1a; Matt Brett - Freelance Web Designer and WordPress Expert ‎2022 Year in Review • Letterboxd NIO蔚来汽车官方网站 小米官网 Silk – Interactive Generative Art 大屏数据可视化 你是否也有过这样的“烦恼”&#xff1a; * …
阅读更多...
（C00034）基于Springboot+html前后端分离技术的宿舍管理系统-有文档

（C00034）基于Springboot+html前后端分离技术的宿舍管理系统-有文档

基于Springboothtml技术的宿舍管理系统-有文档项目简介项目获取开发环境项目技术运行截图项目简介 基于Springboothtml的前后端分离技术的宿舍管理系统项目为了方便对学生宿舍进行管理而设计&#xff0c;分为后勤、宿管、学生三种用户&#xff0c;后勤对整体宿舍进行管理、宿管…
阅读更多...
第九层（16）：STL终章——常用集合算法

第九层（16）：STL终章——常用集合算法

文章目录前情回顾常用集合算法set_intersectionset_unionset_difference最后一座石碑倒下&#xff0c;爬塔结束一点废话&#x1f389;welcome&#x1f389; ✒️博主介绍&#xff1a;一名大一的智能制造专业学生&#xff0c;在学习C/C的路上会越走越远&#xff0c;后面不定期更…
阅读更多...
JY-7A/3DK/220 19-130V静态【电压继电器】

JY-7A/3DK/220 19-130V静态【电压继电器】

系列型号 JY-7A/1DK不带辅助电源电压继电器&#xff1b;JY-7B/1DK不带辅助电源电压继电器&#xff1b; JY-7/1DK/120不带辅助电源电压继电器&#xff1b;JY-7/1DK/120不带辅助电源电压继电器&#xff1b; JY-7A/1DKQ不带辅助电源电压继电器&#xff1b;JY-7B/1DKQ不带辅助电源…
阅读更多...
Python入门之ChatGPT的API调用(Python版)

Python入门之ChatGPT的API调用(Python版)

一、Python环境部署 参考Python 环境搭建 | 菜鸟教程 Python官网&#xff1a;Welcome to Python.org Python文档下载地址&#xff1a;Our Documentation | Python.org 二、Thonny的安装 安装包地址&#xff1a;Thonny, Python IDE for beginners 三、ChatGPT的Key申请 网…
阅读更多...
虚拟机安装CentOS 7（带界面）

虚拟机安装CentOS 7（带界面）

目录 一、虚拟机安装CentOS 7&#xff08;带界面&#xff09; 1、打开下好的VMware&#xff0c;点击创建虚拟机 2、下一步 3、点击下一步 4、选择Linux&#xff0c;ContOS7&#xff0c;点击下一步 5、修改虚拟机名称和路径 6、下一步 7、点击自定义硬件 8、设置虚拟机大…
阅读更多...
《第一行代码》 第三章：UI布局开发

《第一行代码》 第三章：UI布局开发

一&#xff0c;常用控件的使用方法 1&#xff0c;TextView <TextViewandroid:id"id/text_view"android:layout_width"match_parent"android:layout_height"wrap_content"android:gravity"center"android:textSize"24sp"…
阅读更多...
iptables防火墙SNAT和DNAT

iptables防火墙SNAT和DNAT

iptables防火墙SNAT和DNAT一、SNAT原理和应用1、SNAT原理2、SNAT应用环境3、SNAT转换前提条件二、SNAT案列1、实验需求2、实验环境3、实验目的三、DNAT原理和应用1、DNAT原理2、DNAT 应用环境3、DNAT转换的前提条件四、DNAT案列总结一、SNAT原理和应用 1、SNAT原理 SNAT原理:…
阅读更多...
365天深度学习训练营 第P6周：好莱坞明星识别

365天深度学习训练营 第P6周：好莱坞明星识别

&#x1f368; 本文为&#x1f517;365天深度学习训练营 内部限免文章&#xff08;版权归 K同学啊 所有&#xff09;&#x1f366; 参考文章地址&#xff1a; &#x1f517;第P6周&#xff1a;好莱坞明星识别 | 365天深度学习训练营&#x1f356; 作者&#xff1a;K同学啊 | 接…
阅读更多...
扩散模型diffusion model用于图像恢复任务详细原理 (去雨，去雾等皆可)，附实现代码

扩散模型diffusion model用于图像恢复任务详细原理 (去雨，去雾等皆可)，附实现代码

文章目录1. 去噪扩散概率模型2. 前向扩散3. 反向采样3. 图像条件扩散模型4. 可以考虑改进的点5. 实现代码1. 去噪扩散概率模型 扩散模型是一类生成模型, 和生成对抗网络GAN 、变分自动编码器VAE和标准化流模型NFM等生成网络不同的是, 扩散模型在前向扩散过程中对图像逐步施加噪…
阅读更多...
如何为自己的应用选择数据库？有这些考虑因素

如何为自己的应用选择数据库？有这些考虑因素

节选翻译自 Michal Toiba 的博客 微软前不久宣布推出分布式关系数据库 Azure Cosmos DB for PostgreSQL&#xff0c;使 Azure 成为第一个在单一数据库服务中同时支持关系和 NoSQL&#xff08;非关系&#xff09;数据的云平台。这意味着 Azure Cosmos DB 开发者在构建云原生应用…
阅读更多...
只需三步，完成ChatGPT微信机器人搭建

只需三步，完成ChatGPT微信机器人搭建

大家好&#xff0c;我是可乐。 这两天 Chatgpt 又爆火了&#xff0c;去年12月份刚出来的时候&#xff0c;我写了两篇文章&#xff1a; ①、如何注册Chatgpt&#xff1f; ②、如何将 chatgpt接入微信&#xff1f; 然后沉寂了一个月&#xff0c;没想现在到又火了。本篇文章我…
阅读更多...
计算机组成与体系结构 性能设计 William Stallings 第2章 性能问题

计算机组成与体系结构 性能设计 William Stallings 第2章 性能问题

2.1 优化性能设计例如&#xff0c;当前需要微处理器强大功能的桌面应用程序包括&#xff1a;图像处理、三维渲染、语音识别、视频会议、多媒体创作、文件的声音和视频注释、仿真建模从计算机组成与体系结构的角度来看&#xff0c;一方面&#xff0c;现代计算机的基本组成与50多…
阅读更多...
强大的ChatGpt为企业营销推广提供了全方位的加持

强大的ChatGpt为企业营销推广提供了全方位的加持

chatgpt&#xff0c;一个火出圈的“聊天机器人”。从写作文&#xff0c;到写代码&#xff0c;似乎没有什么是它干不了的。 ChatGpt在工业中的应用场景有哪些? 在工业领域&#xff0c;它可以用于提高生产效率&#xff0c;缩短生产周期&#xff0c;并帮助工人解决生产过程中的问…
阅读更多...
推荐文章
最新文章

Copyright @ 2022~2023