一、前言
Kotlin标准库中所有集合操作的函数都是内联的（ inline ），例如：
public inline fun <T> Iterable<T>.forEach(action: (T) -> Unit): Unit {
for (element in this) action(element)
}
public inline fun <T> Iterable<T>.forEachIndexed(action: (index: Int, T) -> Unit): Unit {
var index = 0
for (item in this) action(checkIndexOverflow(index++), item)
}
这个 inline 修饰符有多重要呢？
假设我们有 5000 件商品，我们需要对已购买的商品计算总价，我们可以通过以下方式完成：
products.filter{ it.bought }.sumByDouble { it.price }
在我的机器上，运行上述代码平均需要38毫秒。如果这个函数不是内联的话会是多长时间呢? 不是内联在我的机器上大概平均42毫秒。你们可以自己检查尝试下，这里是完整源码. 这似乎看起来差距不是很大，但每调用一次这个函数对集合进行处理时，你都会注意到这个时间差距大约为10％左右。
当我们修改lambda表达式中的局部变量时，可以发现差距将会更大。对比下面两个函数:
inline fun repeat(times: Int, action: (Int) -> Unit) {
for (index in 0 until times) {
action(index)
}
}
fun noinlineRepeat(times: Int, action: (Int) -> Unit) {
for (index in 0 until times) {
action(index)
}
}
除了函数名不一样之外，唯一的区别就是第一个函数使用inline修饰符，而第二个函数没有。用法也是完全一样的:
var a = 0
repeat(100_000_000) {
a += 1
}
var b = 0
noinlineRepeat(100_000_000) {
b += 1
}
上述代码在执行时间上对比有很大的差异。内联的repeat函数平均运行时间是0.335ns, 而noinlineRepeat函数平均运行时间是153980484.884ns。大概是内联repeat函数运行时间的466000倍! 你们可以自己检查尝试下,这里是完整源码.
为什么这个如此重要呢? 这种性能的提升是否有其他的成本呢? 我们应该什么时候使用内联(inline)修饰符呢？这些都是重点问题，我们将尽力回答这些问题。然而这一切都需要从最基本的问题开始: 内联修饰符到底有什么作用?
二、内联修饰符有什么作用？
我们都知道函数通常是如何被调用的。先执行跳转到函数体，然后执行函数体内所有的语句，最后跳回到最初调用函数的位置。尽管强行对函数使用inline修饰符标记，但是编译器将会以不同的方式来对它进行处理。在代码编译期间，它用它的主体替换这样的函数调用。 print函数是inline函数:
public inline fun print(message: Int) {
System.out.print(message)
}
当我们在main函数中调用它时:
fun main(args: Array<String>) {
print(2)
print(2)
}
编译后，它将变成下面这样:
public static final void main(@NotNull String[] args) {
System.out.print(2)
System.out.print(2)
}
这里有一点不一样的是我们不需要跳回到另一个函数中。虽然这种影响可以忽略不计。
这就是为什么你定义这样的内联函数时会在IDEA IntelliJ中发出以下警告：
Expected performance impact from inline is insignificant. Inlining works best for functions with parameters of functional types
意思就是：内联不会有显著的影响，它比函数要好。
为什么IntelliJ建议我们在含有lambda表达式作为形参的函数中使用内联呢？因为当我们内联函数体时，我们不需要从参数中创建lambda表达式实例，而是可以将它们内联到函数调用中来。这个是上述repeat函数的调用:
repeat(100) { println("A") }
将会编译成这样：
for (index in 0 until 1000) {
println("A")
}
正如你所看见的那样，lambda表达式的主体println("A")替换了内联函数repeat中action(index)的调用。
让我们看另一外个例子。filter函数的用法:
val products2 = products.filter { it.bought }
替换为：
val destination = ArrayList<T>()
for (element in this)
if (predicate(element))
destination.add(element)
val products2 = destination
这是一项非常重要的改进。这是因为JVM天然地不支持lambda表达式。
说清楚lambda表达式是如何被编译的是件很复杂的事。但总的来说，有两种结果:
- 匿名类
- 单独的类
我们来看个例子。我们有以下lambda表达式：
val lambda: ()->Unit = {
// body
}
它变成了JVM中的匿名类:
// Java
Function0 lambda = new Function0() {
public Object invoke() {
// code
}
};
或者它变成了单独的文件中定义的普通类：
// Java
// Additional class in separate file
public class TestInlineKt$lambda implements Function0 {
public Object invoke() {
// code
}
}
// Usage
Function0 lambda = new TestInlineKt$lambda()
第二种效率更高，我们尽可能使用这种。仅仅当我们需要使用局部变量时，第一种才是必要的。
这就是为什么当我们修改局部变量时，repeat和noinlineRepeat之间存在如此之大的运行速度差异的原因：
非内联函数中的Lambda需要编译为匿名类！
这是一个巨大的性能开销，从而导致它们的创建和使用都较慢。
当我们使用内联函数时，我们根本不需要创建任何其他类。
自己检查一下。编译这段代码并把它反编译为Java代码：
fun main(args: Array<String>) {
var a = 0
repeat(100_000_000) {
a += 1
}
var b = 0
noinlineRepeat(100_000_000) {
b += 1
}
}
你会发现一些相似的东西
// Show Kotlin Bytecode
public static final void main(@NotNull String[] args) {
Intrinsics.checkParameterIsNotNull(args, "args");
int a = 0;
int times$iv = 100000000;
int $i$f$repeat = false;
int var4 = 0;
for(int var5 = times$iv; var4 < var5; ++var4) {
int var7 = false;
++a;
}
final IntRef b = new IntRef();
b.element = 0;
noinlineRepeat(100000000, (Function1)(new Function1() {
public Object invoke(Object var1) {
this.invoke(((Number)var1).intValue());
return Unit.INSTANCE;
}
public final void invoke(int it) {
++b.element;
}
}));
}
在filter函数例子中，使用内联函数改进效果不是那么明显，这是因为lambda表达式在非内联函数中是编译成普通的类而非匿名类。所以它的创建和使用效率还算比较高，但仍有性能开销，所以也就证明了最开始那个filter例子为什么只有10%的运行速度差异。
三、集合流处理方式与经典处理方式
内联修饰符是一个非常关键的元素，它能使集合流处理的方式与基于循环的经典处理方式一样高效。它经过一次又一次的测试，在代码可读性和性能方面已经优化到极点了，并且相比之下经典处理方式总是有很大的成本。例如，下面的代码：
return data.filter { filterLoad(it) }.map { mapLoad(it) }
工作原理与下面代码相同并具有相同的执行时间：
val list = ArrayList<String>()
for (it in data) {
if (filterLoad(it)) {
val value = mapLoad(it)
list.add(value)
}
}
return list
基准测量的具体结果（源码在这里）：
Benchmark (size) Mode Cnt Score Error Units
filterAndMap 10 avgt 200 561.249 ± 1 ns/op
filterAndMap 1000 avgt 200 29803.183 ± 127 ns/op
filterAndMap 100000 avgt 200 3859008.234 ± 50022 ns/op
filterAndMapManual 10 avgt 200 526.825 ± 1 ns/op
filterAndMapManual 1000 avgt 200 28420.161 ± 94 ns/op
filterAndMapManual 100000 avgt 200 3831213.798 ± 34858 ns/op
四、内联修饰符的成本
通过上面已经得出，内联函数，实际就是替换掉你原来的代码，改为内联函数中的代码。
因此，内联的优点是代码简洁，可读性强；缺点是编译后的代码体积会变大（变大多少取决于用了多少 inline ）。
五、内联修饰符在不同方面的用法
内联修饰符因为它特殊的语法特性而发生的变化远远超过我们在本篇文章中看到的内容。
它可以实化泛型类型。但是它也有一些局限性。
我们使用内联修饰符时最常见的场景就是：
- 把函数作为另一个函数的参数时(高阶函数)；
- 集合或字符串处理(如filter,map或者joinToString)；
- 一些独立的函数(如repeat)
这就是为什么inline修饰符经常被库开发人员用来做一些重要优化的原因了。他们应该知道它是如何工作的，哪里还需要被改进以及使用成本是什么。当我们使用函数类型作为参数来定义自己的工具类函数时，我们也需要在项目中使用inline修饰符。当我们没有函数类型作为参数，没有reified实化类型参数并且也不需要非本地返回时，那么我们很可能不应该使用inline修饰符了。这就是为什么我们在非上述情况下使用inline修饰符会在Android Studio或IDEA IntelliJ得到一个警告原因。
