[译]Kotlin中内联类的自动装箱和高性能探索(二)

古城微笑少年丶 2022-04-06 07:51 206阅读 0赞

**翻译说明:**

**原标题: Inline Classes and Autoboxing in Kotlin**

**原文地址: [https://typealias.com/guides/inline-classes-and-autoboxing/][https_typealias.com_guides_inline-classes-and-autoboxing]**

**原文作者: [Dave Leeds][]**

在上一篇文章中，我们知道了Kotlin的实验阶段的新特性内联类是如何让我们"创建需要的数据类型但是不会损失我们需要的性能"。我们了解到:

*  1、内联类包装了基础类型的值
 *  2、当代码被编译的时候，内联类的实例将会被替换成基础类型的值
 *  3、这可以大大提高我们应用程序的性能，特别是当基础类型是一个基本数据类型时。

但是在某些情况下，内联类实际上比传统的普通类执行速度更慢! 在这篇文章中，我们将去探索在不同的场景下使用内联类编译代码中到底会发生什么- 因为如果我们知道如何高效地使用他们，我们才能从中获得更高的性能。  
![1678cd6d8f41d4b0_w_640_h_336_f_png_s_33509][]

请记住-内联类始终还是一个实验性的特性。尽管我一直在写内联类系列的文章，并且内联类也会经历很多的迭代和修改。本文目前基于Kotlin 1.3 Release Candidate 146中实现的内联类。

此外，如果你还没有阅读过有关内联类的文章，那么你首先要阅读上一篇文章 **[\[译\]Kotlin中内联类(inline class)完全解析(一)][Kotlin_inline class]**。那样你就会全身心投入并准备好阅读这篇文章。

好的，让我们现在开始吧!

### 高性能的奥秘 ###

Alan被彻底激怒了！在学习完内联类之后，他决定开始在他正在研究的游戏原型中使用内联类。为了看看内联类比传统的普通类到底有多好，他在他游戏评分系统中写了一些有关内联类的代码:

interface Amount {
         val value: Int }
    inline class Points(override val value: Int) : Amount
    
    private var totalScore = 0L
    
    fun main() {
        
        repeat(1_000_000) {
        
            val points = Points(it)
    
            repeat(10_000) {
        
                addToScore(points)
            }
        }
    }
    
    fun addToScore(amount: Amount) {
        
        totalScore += amount.value
    }

Alan编写了这段代码的测试用例。然后，他删除第二行`inline`关键字，并再次运行这个测试用例。

令他惊讶的是，使用内联修饰符`inline`运行速度实际上明显比没有内联情况慢很多。

“到底发生了什么？”他想知道。

虽然说内联类可以比传统的普通类更高性能运行，但是这一切都取决于我们如何合理使用它们-因为我们如何使用它们决定了值是否在编译代码中真的进行内联操作。

这是正确的 - **内联类的实例并不总是在编译的代码中内联。**

### 什么时候内联类不会被内联 ###

让我们再一起看下Alan的代码，看看我们是否可以弄明白为什么他写的内联类可能没有被内联。

我们先来看下这段代码:

interface Amount {
         val value: Int }
    inline class Points(override val value: Int) : Amount

在这段代码中，内联类`Points`实现了`Amount`接口。当我们调用`addToScore()`函数时，会引发一个有趣的现象，尽管…

fun addToScore(amount: Amount) {
        
        totalScore += amount.value
    }

`addToScore()`函数可以接收任何`Amount`类型的对象。由于`Points`是`Amount`的子类型，所以我们可以传入一个`Points`类型实例对象给这个函数。

这是基本的常识，没问题吧?

但是… 假设我们的`Points`类的实例都是内联的-也就是说，在源码被编译的阶段，它们(`Points`类的实例)会被基础类型(这里是Int整数类型)给替换掉。-可是`addToScore()`函数怎么能接收一个基础类型(这里是Int整数类型)的实参呢?毕竟，基础类型`Int`并没有去实现`Amount`的接口。  
![1678d016c2c4148b_w_480_h_431_f_png_s_14928][]

那么编译后的代码怎么可能会向`addToScore`函数发送一个`Int`类型(更确切的说是Java中的int类型)的实参，因为int类型是不会去实现`Amount`接口的。

答案当然是它不能啊！

![1678d06038c987d8_w_1024_h_414_f_png_s_29790][]

因此，在这种场景下，Kotlin还是继续使用为`Points`类型，而不是在编译代码中使用整数替换。我们将这个`Points`类称为包装类型，而不是基础类型`Int`。  
![1678d09589280dfb_w_1024_h_414_f_png_s_32180][]

最重要的是需要注意，这并不意味这该类永远不会被内联。它只意味着代码中某些地方没有被内联。例如，让我们来看一下Alan中的代码，看看`Points`什么时候是内联的，什么时候不是内联的。

fun main() {
        
        repeat(1_000_000) {
        
            val points = Points(it) // <-- Points is inlined as an Int here(Points类在这是内联的，并被当做Int替换)
    
            repeat(10_000) {
        
                addToScore(points)  // <-- Can't pass Int here, so sends it
                                    //     as an instance of Points instead.(因为这里不能被传入Int，所以这里必须传入Points实例)
            }
        }
    }

编译器将尽可能使用基础类型（例如，Int，编译为int），但是当它不能被当做基础类型使用时，它会自动实例化包装类型的实例（例如，Points）并把它传递出去。可以想象下这是编译后的代码（在Java中）大致如下：

public static void main(String[] arg) {
        
      for(int i = 0; i < 1000000; i++) {
        
         int points = i;                     // <--- Inlined here(此处内联)
    
         for(short k = 0; k < 10000; k++) {
        
            addToScore(new Points(points));  // <--- Automatic instantiation!(自动实例化)
         }
      }
    }

您可以将`Points`类想象为包装基础`Int`值的箱子。  
![1678d118a6b36478_w_800_h_371_f_png_s_35656][]

因为编译器会自动将值放入箱子中，所以我们把这个过程叫做**自动装箱**。

现在我们知道了为什么Alan的代码在使用内联类的时候运行速度会比普通类要慢。**每次调用`addToScore()`函数时，都会自动实例化一个新的`Points`类的实例。所以在内部循环迭代过程中总共发生100亿次堆分配过程，这就是速度减慢的原因。  
(相比之下，使用传统的普通类，而堆分配过程只发生在外层for循环中，总共也只有100万次).**

这种自动装箱过程一般还是很有用的-它是保证类型安全所必需的操作，当然，它同时也带来了性能开销成本，每次创建一个堆上新对象时就会存在这样性能开销。所以这就意味着作为开发者，了解哪种场景下会发生Kotlin进行自动装箱操作是非常重要的，这样我们就可以更明智地决定如何去使用内联类了。

那么，接下来让我们一起来看看自动装箱过程可能会在哪些场景被触发！

#### 引用超类型时会触发自动装箱操作 ####

正如我们所看到的那样，当我们将`Points`对象传递给接收`Amount`类型作为形参的函数式，就触发了自动装箱操作。

即使你的内联类没有去实现接口，但是必须记住一点，内联类和普通类一样，所有内联类都是`Any`的子类型。所以当你将内联类的实例赋值给`Any`类型的变量或者传递给`Any`类型作为形参的函数时，都会触发预期中的自动装箱操作。

例如，假设我们有一个可以记录日志的服务接口:

interface LogService {
        
        fun log(any: Any)
    }

由于这个`log()`函数可以接收一个`Any`类型的实参，一旦你传入一个`Points`的实例给这个函数，那么这个实例就会触发自动装箱操作。

val points = Points(5)
    logService.log(points) // <--- Autoboxing happens here(此处发生自动装箱操作)

总之一句话 - 当你使用内联类的实例（其中需要超类型）时，可能会触发自动装箱。

#### 自动装箱与泛型 ####

当您使用具有泛型的内联类时，也会发生自动装箱。例如:

val points = Points(5)
    
    val scoreAudit = listOf(points)      // <-- Autoboxing here(此处发生自动装箱操作)
    
    fun <T> log(item: T) {
        
        println(item)
    }
    
    log(points)                          // <-- Autoboxing here(此处发生自动装箱操作)

在使用泛型时，Kotlin为我们自动装箱是件好事，否则我们会在编译代码中会遇到类型安全的问题。例如，类似于我们之前的场景，将整数类型的值插入到`MutableList<Amount>`集合类型中是不安全的，因为整数类型并没有去实现`Amount`的接口。

而且，一旦考虑到与Java互操作时，它就会变得更加复杂，例如:

*  如果Java将`List<Points>`保存为`List<Integer>`，它是否应该可以将该类型的集合传递给如下这个Kotlin函数呢?

fun receive(list: List<Int>)

*  Java将它传递给下面这个Kotlin函数又会怎么样呢？

fun receive(list: List<Amount>)

*  Java能否可以构建自己的整数集合并把它传递给下面这个Kotlin函数?

fun receive(list: List<Points>)

相反，Kotlin通过自动装箱的操作来避免了内联类和泛型一起使用时的问题。

我们已经看到超类型和泛型两种场景下如何触发自动装箱操作。其实我们还有一个值得去深究的场景 - 那就是**可空性**的场景！

#### 自动装箱和可空性 ####

当涉及到可空类型的值时，也可能会触发自动装箱操作。这个规则有点不同，主要取决于基础类型是引用类型还是基本数据类型。所以让我们一次性来搞定它们。

##### 引用类型 #####

当我们讨论内联类的可空性时，有两种场景可以为空：

*  1、内联类自己的基础类型存在可空和非空的情况
 *  2、使用内联类的地方存在可空和非空的情况

例如:

// 1. The underlying type itself can be nullable (`String?`)
    // 1. 基础类型自己存在可空
    inline class Nickname(val value: String?)
    
    // 2. The usage can be nullable (`Nickname?`)
    //使用内联类时存在可空
    fun logNickname(nickname: Nickname?) {
        
        // ...
    }

由于我们有两种场景，并且每个场景下又存在非空与可空两种情况，因为总共需要考虑四种情况。所以我们为如下四种场景制作一张真值表!

对于每一种情况，我们将考虑：

*  1、基础类型的可空和非空
 *  2、使用内联类地方的可空和非空
 *  3、以及每种情况编译后的是否触发自动装箱操作  
    ![1678d571cc5a7252_w_1024_h_922_f_png_s_49447][]

好消息的是，当基础类型是引用类型时，大多数的情况下，使用的内联类都将被编译成基础类型。这就意味着基础类型的值可以被使用且不会触发自动装箱操作。

这里只有一种情况会触发自动装箱操作，我们需要注意 - 当基础类型和使用类型都为可空类型时。

为什么在这种情况下会触发自动装箱操作？

因为当这两种场景都存在值可空情况下，你最终得到的将是不同的代码分支，具体取决于这两种场景哪一种是空的。例如，看看这段代码:

inline class Nickname(val value: String?)
    
    fun greet(name: Nickname?) {
        
        if (name == null) {
        
            println("Who's there?")
        } else if (name.value == null) {
        
            println("Hello, there.")
        } else {
        
            println("Greetings, ${
          name.value}")
        }
    }
    
    fun main() {
        
        greet(Nickname("T-Bone"))
        greet(Nickname(null))
        greet(null)
    }

如果name形参是使用了基础类型的值-换句话说，如果编译的代码是`void greet(String name)`\-那么它就不可能出现下面三个判断分支。那就不清楚`name`是否为空是应该打印`Who's There`还是`Hello There`.

相反，函数如果编译成这样`void greet(NickName name)`将是有效的.这意味着只要我们调用该函数，Kotlin就会根据需要自动触发装箱操作来包装基础类型的值。

嗯，这是可以为空的引用类型！但是可以为空的基本数据类型呢？

##### 基本数据类型 #####

当内联类、基本数据类型和可空性这三种因素碰在一起，我们会得到一些有趣的自动装箱的场景。正如我们在上面的引用类型中看到的那样，可空性出现场景取决于基础类型可空或非空以及使用内联类地方的可空或非空。

// 1. The underlying type itself can be nullable (`Int?`)
    // 1. 基础类型自己存在可空
    inline class Anniversary(val value: Int?)
    
    // 2. The usage can be nullable (`Anniversary?`)
    //使用内联类时存在可空
    fun celebrate(anniversary: Anniversary?) {
        
        // ...
    }

让我们构建一个真值表，就像对上面的引用类型一样做出的总结  
![1678dd07d6f31d18_w_1024_h_922_f_png_s_47130][]

正如你所看到的那样，上面表格中对于**基本数据类型**的结果除了场景B不一样，其他的场景都和**引用类型**分析结果一样。但是这里面还是涉及到了其他很多知识，所以让我们花点时间一一分析下每一种情况。

**对于场景A.** 很容易就能分析出来。因为这里根本就没有可空类型(都是非空类型)，所以类型是内联的，正如我们所期望的那样。

**对于场景B.** 这是一种完全不同于上一个真值表中的场景，不知道你是否还记得，JVM上的`int`和`boolean`等其他基本数据类型实际上是不能为`null`的。因此，为了更好兼容`null`,Kotlin在此使用了包装类型(也就触发了自动装箱操作)

**对于场景C.** 这种场景就更有意思了。一般来说，当你有一个类似`Int`可以为空的基本数据类型时，在Kotlin中，这种基本数据类型会在编译的时候转换成Java中的基本数据类型对应的包装器类型-例如`Integer`,它(不像`int`)可以兼容`null`值。对于场景C而言，实际上在使用内联类地方编译时候却使用基础类型，因为它本身恰好是一个Java中基本包装器类型。所以在某种层面上，你可以说基础类型被自动装箱了，但是这种自动装箱操作和内联类根本就没有任何关系。

**对于场景D.** 类似于上面引用类型看到的那样，当基本类型自身为可空以及使用内联类地方为可空时，Kotlin将在编译时使用包装器类型。具体原因和引用类型同理。

### 其他需要牢记的点 ###

我们已经介绍了可能导致自动装箱的主要场景。在使用内联类时，你可能会发现对Kotlin源码编译后的字节码进行反编译，然后根据反编译的Java代码来分析是否出现自动装箱有很大的帮助。

要在IntelliJ或Android Studio中执行此操作，只需转到`Tools` \- > `Kotlin` \- >`Show Kotlin Bytecode`，然后单击`Decompile`按钮。  
![1678ded2ca67f854_w_1024_h_619_f_png_s_20767][]

此外，请记住还有很多其他层面上都有可能影响内联类的性能。即使你对自动装箱有了充分的了解，编译器优化（Kotlin编译器和JIT编译器）之类的东西也会导致与我们的预期性能相差很大。如果需要真正了解编码决策对性能的影响，唯一的办法就是使用基准测试工具(比如JMH)实际运行测试。

### 总结 ###

在本文中，我们探讨了使用内联类会出现一些性能影响，并了解到哪些场景下会进行自动装箱。我们已经看到如何使用内联类并会对其性能产生影响，包括涉及到一些具体的使用场景:

*  超类型
 *  泛型
 *  可空性

现在我们知道这一点，我们可以做出更加明智的选择，来高效使用内联类。

你准备好自己开始使用内联类了吗? 你无需等待-你现在就可以在IDE中尝试使用它!

### 译者有话说 ###

这篇文章可以说得上是我看过最好的一篇有关Kotlin内联类性能优化的文章了，感觉非常不错，作者分析得很全面也很深入。就连官方也没有给出过如此详细介绍。关于译文中有几点我需要补充一下:

*  对于Alan那段糟糕的代码使用inline class和普通class代码比较，粗略算了下时间，对比了真的比较惊人:

![1678dfa0d91d7735_w_665_h_128_f_png_s_19786][]

![1678dfa973083e90_w_659_h_130_f_png_s_19337][]  
可以看到inline class看似是个性能优化操作，但是使用不当性能反而比普通类更加差。

*  有关译文中的**基础类型、基本数据类型、引用类型**做一个对比解释，怕有人发蒙。

**基础类型:** 实际上是针对内联类中包装的那个值的类型，它和基础数据类型不是一个东西。这么说吧，基础类型既可以是基本数据类型也可以是引用类型

**基本数据类型:** 实际上就是常用的`Int、Float、Double、Short、Long`等类型，注意`String`是引用类型

**引用类型:** 实际上就是除了基本数据类型就是引用类型，`String`和我们平时自定义的类的类型都属于引用类型。

*  关于上述基本数据类型中的场景B，可能大家还是有点不能理解。这里给大家具体再分析下。

对于基础数据类型场景B，为什么会出现自动装箱操作?  
这是因为在Kotlin中使用内联类的时候用了可空类型，我们可以用反证法来理解下，假设使用可空类型的内联类地方被编译成Java中的`int`等基本数据类型，在Kotlin中类似如下代码:

inline class Age(val value: Int)
    
    fun howOld(age: Age?) {
        
        if(age == null){
        
            ...
        }
    }

编译成类似如下代码:

void howOld(int age){
        
        if(age == null){
        //这样的代码是会报错的
            ...
        }
    }

![1678e0cf6d01bb45_w_383_h_119_f_png_s_17068][]

所以原假设不成立，Kotlin为了兼容null，不得不把它自动装箱使用包装器类型。

到这里有关内联类的知识文章就完全结束了，由于内联类还是一个实验性的特性，后期正式版本的API可能会有变动，当然我也紧跟官方最新动态，如果变动会尽快以文章形式总结出来。如果你这一期内联类知识掌握了，后面在怎么变动，你都能很快掌握它，并也会得到更多自己的体会。欢迎继续关注~~~

### Kotlin系列文章，欢迎查看: ###

![1635c3fb0ba21ec1_w_430_h_430_f_jpeg_s_39536][]

**欢迎关注Kotlin开发者联盟，这里有最新Kotlin技术文章，每周会不定期翻译一篇Kotlin国外技术文章。如果你也喜欢Kotlin，欢迎加入我们~~~**

### Kotlin系列文章，欢迎查看: ###

> Kotlin邂逅设计模式系列:

*  **[当Kotlin完美邂逅设计模式之单例模式(一)][Kotlin]**

> 数据结构与算法系列:

*  **[每周一算法之二分查找(Kotlin描述)][Kotlin 1]**

> 翻译系列：

*  **[\[译\] Kotlin中关于Companion Object的那些事][Kotlin_Companion Object]**
 *  **[\[译\]记一次Kotlin官方文档翻译的PR(内联类)][Kotlin_PR]**
 *  **[\[译\]Kotlin中内联类的自动装箱和高性能探索(二)][Kotlin 2]**
 *  **[\[译\]Kotlin中内联类(inline class)完全解析(一)][Kotlin_inline class 1]**
 *  **[\[译\]Kotlin的独门秘籍Reified实化类型参数(上篇)][Kotlin_Reified]**
 *  **[\[译\]Kotlin泛型中何时该用类型形参约束?][Kotlin 3]**
 *  **[\[译\] 一个简单方式教你记住Kotlin的形参和实参][_Kotlin]**
 *  **[\[译\]Kotlin中是应该定义函数还是定义属性?][Kotlin 4]**
 *  **[\[译\]如何在你的Kotlin代码中移除所有的!!(非空断言)][Kotlin 5]**
 *  **[\[译\]掌握Kotlin中的标准库函数: run、with、let、also和apply][Kotlin_ run_with_let_also_apply]**
 *  **[\[译\]有关Kotlin类型别名(typealias)你需要知道的一切][Kotlin_typealias]**
 *  **[\[译\]Kotlin中是应该使用序列(Sequences)还是集合(Lists)?][Kotlin_Sequences_Lists]**
 *  **[\[译\]Kotlin中的龟(List)兔(Sequence)赛跑][Kotlin_List_Sequence]**

> 原创系列：

*  **[教你如何完全解析Kotlin中的类型系统][Kotlin 6]**
 *  **[如何让你的回调更具Kotlin风味][Kotlin 7]**
 *  **[Jetbrains开发者日见闻(三)之Kotlin1.3新特性(inline class篇)][Jetbrains_Kotlin1.3_inline class]**
 *  **[JetBrains开发者日见闻(二)之Kotlin1.3的新特性(Contract契约与协程篇)][JetBrains_Kotlin1.3_Contract]**
 *  **[JetBrains开发者日见闻(一)之Kotlin/Native 尝鲜篇][JetBrains_Kotlin_Native]**
 *  **[教你如何攻克Kotlin中泛型型变的难点(实践篇)][Kotlin 8]**
 *  **[教你如何攻克Kotlin中泛型型变的难点(下篇)][Kotlin 9]**
 *  **[教你如何攻克Kotlin中泛型型变的难点(上篇)][Kotlin 10]**
 *  **[Kotlin的独门秘籍Reified实化类型参数(下篇)][Kotlin_Reified 1]**
 *  **[有关Kotlin属性代理你需要知道的一切][Kotlin 11]**
 *  **[浅谈Kotlin中的Sequences源码解析][Kotlin_Sequences]**
 *  **[浅谈Kotlin中集合和函数式API完全解析-上篇][Kotlin_API_-]**
 *  **[浅谈Kotlin语法篇之lambda编译成字节码过程完全解析][Kotlin_lambda]**
 *  **[浅谈Kotlin语法篇之Lambda表达式完全解析][Kotlin_Lambda]**
 *  **[浅谈Kotlin语法篇之扩展函数][Kotlin 12]**
 *  **[浅谈Kotlin语法篇之顶层函数、中缀调用、解构声明][Kotlin 13]**
 *  **[浅谈Kotlin语法篇之如何让函数更好地调用][Kotlin 14]**
 *  **[浅谈Kotlin语法篇之变量和常量][Kotlin 15]**
 *  **[浅谈Kotlin语法篇之基础语法][Kotlin 16]**

> Effective Kotlin翻译系列

*  **[\[译\]Effective Kotlin系列之考虑使用原始类型的数组优化性能(五)][Effective Kotlin]**
 *  **[\[译\]Effective Kotlin系列之使用Sequence来优化集合的操作(四)][Effective Kotlin_Sequence]**
 *  **[\[译\]Effective Kotlin系列之探索高阶函数中inline修饰符(三)][Effective Kotlin_inline]**
 *  **[\[译\]Effective Kotlin系列之遇到多个构造器参数要考虑使用构建器(二)][Effective Kotlin 1]**
 *  **[\[译\]Effective Kotlin系列之考虑使用静态工厂方法替代构造器(一)][Effective Kotlin 2]**

> 实战系列:

*  **[用Kotlin撸一个图片压缩插件ImageSlimming-导学篇(一)][Kotlin_ImageSlimming-]**
 *  **[用Kotlin撸一个图片压缩插件-插件基础篇(二)][Kotlin_-]**
 *  **[用Kotlin撸一个图片压缩插件-实战篇(三)][Kotlin_- 1]**
 *  **[浅谈Kotlin实战篇之自定义View图片圆角简单应用][Kotlin_View]**

[https_typealias.com_guides_inline-classes-and-autoboxing]: https://typealias.com/guides/inline-classes-and-autoboxing/
[Dave Leeds]: https://twitter.com/djleeds
[1678cd6d8f41d4b0_w_640_h_336_f_png_s_33509]: https://user-gold-cdn.xitu.io/2018/12/8/1678cd6d8f41d4b0?w=640&h=336&f=png&s=33509
[Kotlin_inline class]: https://juejin.im/post/5c0928766fb9a049d131eff3
[1678d016c2c4148b_w_480_h_431_f_png_s_14928]: https://user-gold-cdn.xitu.io/2018/12/8/1678d016c2c4148b?w=480&h=431&f=png&s=14928
[1678d06038c987d8_w_1024_h_414_f_png_s_29790]: https://user-gold-cdn.xitu.io/2018/12/8/1678d06038c987d8?w=1024&h=414&f=png&s=29790
[1678d09589280dfb_w_1024_h_414_f_png_s_32180]: https://user-gold-cdn.xitu.io/2018/12/8/1678d09589280dfb?w=1024&h=414&f=png&s=32180
[1678d118a6b36478_w_800_h_371_f_png_s_35656]: https://user-gold-cdn.xitu.io/2018/12/8/1678d118a6b36478?w=800&h=371&f=png&s=35656
[1678d571cc5a7252_w_1024_h_922_f_png_s_49447]: https://user-gold-cdn.xitu.io/2018/12/8/1678d571cc5a7252?w=1024&h=922&f=png&s=49447
[1678dd07d6f31d18_w_1024_h_922_f_png_s_47130]: https://user-gold-cdn.xitu.io/2018/12/8/1678dd07d6f31d18?w=1024&h=922&f=png&s=47130
[1678ded2ca67f854_w_1024_h_619_f_png_s_20767]: https://user-gold-cdn.xitu.io/2018/12/8/1678ded2ca67f854?w=1024&h=619&f=png&s=20767
[1678dfa0d91d7735_w_665_h_128_f_png_s_19786]: https://user-gold-cdn.xitu.io/2018/12/8/1678dfa0d91d7735?w=665&h=128&f=png&s=19786
[1678dfa973083e90_w_659_h_130_f_png_s_19337]: https://user-gold-cdn.xitu.io/2018/12/8/1678dfa973083e90?w=659&h=130&f=png&s=19337
[1678e0cf6d01bb45_w_383_h_119_f_png_s_17068]: https://user-gold-cdn.xitu.io/2018/12/8/1678e0cf6d01bb45?w=383&h=119&f=png&s=17068
[1635c3fb0ba21ec1_w_430_h_430_f_jpeg_s_39536]: https://user-gold-cdn.xitu.io/2018/5/14/1635c3fb0ba21ec1?w=430&h=430&f=jpeg&s=39536
[Kotlin]: https://blog.csdn.net/u013064109/article/details/89078666
[Kotlin 1]: https://blog.csdn.net/u013064109/article/details/89023937
[Kotlin_Companion Object]: https://blog.csdn.net/u013064109/article/details/89199478
[Kotlin_PR]: https://blog.csdn.net/u013064109/article/details/85180755
[Kotlin 2]: https://blog.csdn.net/u013064109/article/details/84899657
[Kotlin_inline class 1]: https://blog.csdn.net/u013064109/article/details/84866092
[Kotlin_Reified]: https://blog.csdn.net/u013064109/article/details/83388976
[Kotlin 3]: https://blog.csdn.net/u013064109/article/details/83120352
[_Kotlin]: https://blog.csdn.net/u013064109/article/details/83099581
[Kotlin 4]: https://blog.csdn.net/u013064109/article/details/80344848
[Kotlin 5]: https://blog.csdn.net/u013064109/article/details/80358822
[Kotlin_ run_with_let_also_apply]: https://blog.csdn.net/u013064109/article/details/80387322
[Kotlin_typealias]: https://blog.csdn.net/u013064109/article/details/80444565
[Kotlin_Sequences_Lists]: https://blog.csdn.net/u013064109/article/details/80562009
[Kotlin_List_Sequence]: https://blog.csdn.net/u013064109/article/details/80740230
[Kotlin 6]: https://blog.csdn.net/u013064109/article/details/88985474
[Kotlin 7]: https://blog.csdn.net/u013064109/article/details/86695094
[Jetbrains_Kotlin1.3_inline class]: https://blog.csdn.net/u013064109/article/details/84837918
[JetBrains_Kotlin1.3_Contract]: https://blog.csdn.net/u013064109/article/details/84782206
[JetBrains_Kotlin_Native]: https://blog.csdn.net/u013064109/article/details/84729814
[Kotlin 8]: https://blog.csdn.net/u013064109/article/details/84504847
[Kotlin 9]: https://blog.csdn.net/u013064109/article/details/84060626
[Kotlin 10]: https://blog.csdn.net/u013064109/article/details/83869716
[Kotlin_Reified 1]: https://blog.csdn.net/u013064109/article/details/83507076
[Kotlin 11]: https://blog.csdn.net/u013064109/article/details/82794410
[Kotlin_Sequences]: https://blog.csdn.net/u013064109/article/details/80588034
[Kotlin_API_-]: https://blog.csdn.net/u013064109/article/details/80275942
[Kotlin_lambda]: https://blog.csdn.net/u013064109/article/details/80139556
[Kotlin_Lambda]: https://blog.csdn.net/u013064109/article/details/80088158
[Kotlin 12]: https://blog.csdn.net/u013064109/article/details/79968846
[Kotlin 13]: https://blog.csdn.net/u013064109/article/details/79887528
[Kotlin 14]: https://blog.csdn.net/u013064109/article/details/79503709
[Kotlin 15]: https://blog.csdn.net/u013064109/article/details/79296502
[Kotlin 16]: https://blog.csdn.net/u013064109/article/details/77843579
[Effective Kotlin]: https://blog.csdn.net/u013064109/article/details/84996951
[Effective Kotlin_Sequence]: https://blog.csdn.net/u013064109/article/details/84981570
[Effective Kotlin_inline]: https://blog.csdn.net/u013064109/article/details/84948769
[Effective Kotlin 1]: https://blog.csdn.net/u013064109/article/details/82121020
[Effective Kotlin 2]: https://blog.csdn.net/u013064109/article/details/81916446
[Kotlin_ImageSlimming-]: https://blog.csdn.net/u013064109/article/details/80850992
[Kotlin_-]: https://blog.csdn.net/u013064109/article/details/80879296
[Kotlin_- 1]: https://blog.csdn.net/u013064109/article/details/81814643
[Kotlin_View]: https://blog.csdn.net/u013064109/article/details/80102036