先说说它到底解决了什么问题。我们都知道，在Kotlin里高阶函数是个好东西，可以让代码更优雅。比如下面这个很常见的工具函数：
看着挺清爽是吧？但在底层，每个传入的lambda表达式都会被编译成一个Function对象。如果你在循环里频繁调用这个方法，就会产生大量的临时对象。这些对象虽然很快会被GC回收，但在性能敏感的场合，这种内存分配压力还是会带来不小的开销。
这时候inline函数就派上用场了。我们只需要在函数前面加个inline关键字：
编译时，编译器会把函数体直接"复制"到调用处。换句话说，下面这段代码：
实际上会被编译成：
看到了吗？中间的processList函数调用完全消失了，连带着那个lambda表达式也不再需要创建额外的Function对象。这种优化对于频繁调用的工具函数特别有效，尤其是在循环体内或者需要高性能的场景。
不过这里有个细节需要注意。如果inline函数里包含多个lambda参数，但你在函数体内并没有直接调用某个lambda，编译器会提示你把它标记为noinline：
noinline告诉编译器这个参数不用内联，保持常规的函数对象形式。而crossinline则用于那些需要在另一个执行上下文（比如lambda或者局部对象）中调用的内联参数。
另一个很实用的特性是内联函数配合reified类型参数。我们都知道在Java里泛型是有类型擦除的，运行时拿不到具体的类型信息。但在Kotlin里可以这样写：
因为函数是内联的，所以在编译时T的实际类型是已知的，T::class.java就能拿到具体的Class对象。这个特性在写框架代码时特别有用，能省去很多传递Class参数的麻烦。
但是，内联函数也不是万能的。首先，内联会导致生成的字节码体积增大，因为函数体会被复制到每一个调用处。如果一个内联函数很大，而且被频繁调用，可能会显著增加APK的大小。所以通常只建议对那些小而频繁调用的函数使用inline。
其次，递归函数不能内联，这很好理解------如果无限递归的函数也要内联，代码体积会爆炸。另外，在Java代码中无法调用Kotlin的inline函数，因为Java没有对应的概念。
实际项目中，我一般在以下场景使用inline：
工具函数，特别是集合操作相关的
需要reified类型参数的泛型函数
高阶函数，且会被频繁调用的
最后分享一个实际案例。我们项目中原来有个数据处理的工具类，里面包含多个处理数据列表的高阶函数。在性能分析时发现，在滚动列表时这些函数产生了大量的临时对象。后来给其中几个关键函数加上了inline关键字，内存分配次数直接降了一个数量级，列表滚动的卡顿感也明显减轻了。
总之，inline是个好东西，但要用对地方。理解它的工作原理，结合具体场景灵活运用，才能写出既优雅又高效的Kotlin代码。