1. 标准函数
Kotlin的标准函数指的是Standard.kt文件中定义的函数，任何Kotlin代码都可以自由地调用所有的标准函数. 前面用到的let函数就算一个标准函数，它的主要作用就是配合?.操作符来进行辅助判空处理.
1.1 with函数
with函数接收两个参数：第一个参数可以是一个任意类型的对象，第二个参数是一个Lambda表达式。with函数会在Lambda表达式中提供第一个参数对象的上下文，并使用Lambda表达式中的最后一行代码作为返回值返回。示例代码如下：
val result = with(obj) {
// 这里是obj的上下文
"value" // with函数的返回值
}
with函数可以在连续调用同一个对象的多个方法时让代码变得更加精简，下面我们来看一个具体的例子:
val list = listOf("Apple", "Banana", "Orange", "Pear", "Grape")
val builder = StringBuilder()
builder.append("Start eating fruits.\n")
for (fruit in list) {
builder.append(fruit).append("\n")
}
builder.append("Ate all fruits.")
val result = builder.toString()
println(result)
我们连续调用了很多次builder对象的方法。其实这个时候就可以考虑使用with函数来让代码变得更加精简，如下所示：
val list = listOf("Apple", "Banana", "Orange", "Pear", "Grape")
val result = with(StringBuilder()) {
append("Start eating fruits.\n")
for (fruit in list) {
append(fruit).append("\n")
}
append("Ate all fruits.")
toString()
}
println(result)
首先我们给with函数的第一个参数传入了一个StringBuilder对象，那么接下来整个Lambda表达式的上下文就会是这个StringBuilder对象。于是我们在Lambda表达式中就不用再像刚才那样调用
builder.append()和builder.toString()方法了，而是可以直接调用append()和toString()方法。
1.2 run函数
run函数的用法和使用场景其实和with函数是非常类似的，只是稍微做了一些语法改动而已。首先run函数通常不会直接调用，而是要在某个对象的基础上调用；其次run函数只接收一个Lambda参数，并且会在Lambda表达式中提供调用对象的上下文。其他方面和with函数是一样的，包括也会使用Lambda表达式中的最后一行代码作为返回值返回。示例代码如下：
val result = obj.run {
// 这里是obj的上下文
"value" // run函数的返回值
}
1.3 apply函数
apply函数和run函数也是极其类似的，都要在某个对象上调用，并且只接收一个Lambda参数，也会在Lambda表达式中提供调用对象的上下文，但是apply函数无法指定返回值，而是会自动返回调用对象本身。示例代码如下：
val result = obj.apply {
// 这里是obj的上下文
}
// result == obj
那么现在我们再使用apply函数来修改一下吃水果的这段代码，如下所示：
val list = listOf("Apple", "Banana", "Orange", "Pear", "Grape")
val result = StringBuilder().apply {
append("Start eating fruits.\n")
for (fruit in list) {
append(fruit).append("\n")
}
append("Ate all fruits.")
}
println(result.toString())
注意这里的代码变化，由于apply函数无法指定返回值，只能返回调用对象本身，因此这里的
result实际上是一个StringBuilder对象，所以我们在最后打印的时候还要再调用它的toString()方法才行
2. 静态方法
和绝大多数主流编程语言不同的是，Kotlin却极度弱化了静态方法这个概念.因为Kotlin提供了比静态方法更好用的语法特性，那就是单例类.
像工具类这种功能，在Kotlin中就非常推荐使用单例类的方式来实现，比如上述的Util工具
类，如果使用Kotlin来实现的话就可以这样写：
object Util {
fun doAction() {
println("do action")
}
}
虽然这里的doAction()方法并不是静态方法，但是我们仍然可以使用Util.doAction()的
方式来调用，这就是单例类所带来的便利性。
不过，使用单例类的写法会将整个类中的所有方法全部变成类似于静态方法的调用方式，而如
果我们只是希望让类中的某一个方法变成静态方法的调用方式该怎么办呢？这个时候就可以使用companion object了，示例如下：
class Util {
fun doAction1() {
println("do action1")
}
companion object {
fun doAction2() {
println("do action2")
}
}
}
这里首先我们将Util从单例类改成了一个普通类，然后在类中直接定义了一个doAction1()
方法，又在companion object中定义了一个doAction2()方法。现在这两个方法就有了本质的区别，因为doAction1()方法是一定要先创建Util类的实例才能调用的，而doAction2()方法可以直接使用Util.doAction2()的方式调用。
不过，doAction2()方法其实也并不是静态方法，companion object这个关键字实际上会在Util类的内部创建一个伴生类，而doAction2()方法就是定义在这个伴生类里面的实例方法。只是Kotlin会保证Util类始终只会存在一个伴生类对象，因此调用Util.doAction2()方法实际上就是调用了Util类中伴生对象的doAction2()方法。
由此可以看出，Kotlin确实没有直接定义静态方法的关键字，但是提供了一些语法特性来支持类
似于静态方法调用的写法，这些语法特性基本可以满足我们平时的开发需求了。
如果你确确实实需要定义真正的静态方法， Kotlin仍然提供了两种实现方式：注解和顶层
方法
2.1 注解
先来看注解，前面使用的单例类和companion object都只是在语法的形式上模仿了静态方法
的调用方式，实际上它们都不是真正的静态方法。因此如果你在Java代码中以静态方法的形式
去调用的话，你会发现这些方法并不存在。而如果我们给单例类或companion object中的方
法加上@JvmStatic注解，那么Kotlin编译器就会将这些方法编译成真正的静态方法，如下所
示：
class Util {
fun doAction1() {
println("do action1")
}
companion object {
@JvmStatic
fun doAction2() {
println("do action2")
}
}
}
注意，@JvmStatic注解只能加在单例类或companion object中的方法上，如果你尝试加在
一个普通方法上，会直接提示语法错误。
由于doAction2()方法已经成为了真正的静态方法，那么现在不管是在Kotlin中还是在Java
中，都可以使用Util.doAction2()的写法来调用了。
2.2 顶层方法
顶层方法指的是那些没有定义在任何类中的方法，比如我们编写的main()方法。Kotlin编译器会将所有的顶层方法全部编译成静态方法，因此只要你定义了一个顶层方法，那么它就一定是静态方法。
想要定义一个顶层方法，首先需要创建一个Kotlin文件。对着任意包名右击 → New → Kotlin
File/Class，在弹出的对话框中输入文件名Helper即可。注意创建类型要选择File.
现在我们在这个文件中定义的任何方法都会是顶层方法，比如这里我就定义一个doSomething()方法吧，如下所示：
fun doSomething() {
println("do something")
}
在Kotlin代码中调用的话，那就很简单了，所有的顶层方法都可以在任何位置被直接调用，不用管包名路径，也不用创建实例，直接键入doSomething()即可.
如果是在Java代码中调用，你会发现是找不到doSomething()这个方法的，因为Java中没有顶层方法这个概念，所有的方法必须定义在类中。那么这个doSomething()方法被藏在了哪里呢？我们刚才创建的Kotlin文件名叫作Helper.kt，于是Kotlin编译器会自动创建一个叫作HelperKt的Java类，doSomething()方法就是以静态方法的形式定义在HelperKt类里面的，因此在Java中使用HelperKt.doSomething()的写法来调用就可以了.
3. 延迟初始化
3.1 lateinit关键字
Kotlin语言的许多特性，包括变量不可变，变量不可为空，等等。这些特性都是为了尽可能地保证程序安全而设计的，但是有些时候这些特性也会在编码时给我们带来不少的麻烦。
class MainActivity : AppCompatActivity(), View.OnClickListener {
private var adapter: MsgAdapter? = null
override fun onCreate(savedInstanceState: Bundle?) {
...
adapter = MsgAdapter(msgList)
...
}
override fun onClick(v: View?) {
...
adapter?.notifyItemInserted(msgList.size - 1)
...
}
}
这里我们将adapter设置为了全局变量，但是它的初始化工作是在onCreate()方法中进行的，因此不得不先将adapter赋值为null，同时把它的类型声明成MsgAdapter?。
虽然我们会在onCreate()方法中对adapter进行初始化，同时能确保onClick()方法必然在onCreate()方法之后才会调用，但是我们在onClick()方法中调用adapter的任何方法时仍然要进行判空处理才行，否则编译肯定无法通过。
而当你的代码中有了越来越多的全局变量实例时，这个问题就会变得越来越明显，到时候你可
能必须编写大量额外的判空处理代码，只是为了满足Kotlin编译器的要求。
幸运的是，这个问题其实是有解决办法的，而且非常简单，那就是对全局变量进行延迟初始
化。
延迟初始化使用的是lateinit关键字，它可以告诉Kotlin编译器，我会在晚些时候对这个变量
进行初始化，这样就不用在一开始的时候将它赋值为null了。
接下来我们就使用延迟初始化的方式对上述代码进行优化，如下所示：
class MainActivity : AppCompatActivity(), View.OnClickListener {
private lateinit var adapter: MsgAdapter
override fun onCreate(savedInstanceState: Bundle?) {
...
adapter = MsgAdapter(msgList)
...
}
override fun onClick(v: View?) {
...
adapter.notifyItemInserted(msgList.size - 1)
...
}
}
当然，使用lateinit关键字也不是没有任何风险，如果我们在adapter变量还没有初始化的情况下就直接使用它，那么程序就一定会崩溃，并且抛出一个UninitializedPropertyAccessException异常.
3.2 ::object.isInitialized 方法
另外，我们还可以通过代码来判断一个全局变量是否已经完成了初始化，这样在某些时候能够
有效地避免重复对某一个变量进行初始化操作，示例代码如下：
class MainActivity : AppCompatActivity(), View.OnClickListener {
private lateinit var adapter: MsgAdapter
override fun onCreate(savedInstanceState: Bundle?) {
...
if (!::adapter.isInitialized) {
adapter = MsgAdapter(msgList)
}
...
}
}
具体语法就是这样，::adapter.isInitialized 可用于判断adapter变量是否已经初始
化。虽然语法看上去有点奇怪，但这是固定的写法。然后我们再对结果进行取反，如果还没有
初始化，那么就立即对adapter变量进行初始化，否则什么都不用做。
4. 密封类
4.1 密封类的使用场景
新建一个Kotlin文件，文件名就叫Result.kt好了，然后在这个文件中编写如下代码：
interface Result
class Success(val msg: String) : Result
class Failure(val error: Exception) : Result
接下来再定义一个getResultMsg()方法，用于获取最终执行结果的信息，代码如下所示：
fun getResultMsg(result: Result) = when (result) {
is Success -> result.msg
is Failure -> result.error.message
else -> throw IllegalArgumentException()
}
比较让人讨厌的是，接下来我们不得不再编写一个else条件，否则Kotlin编译器会认为这里缺少条件分支，代码将无法编译通过。但实际上Result的执行结果只可能是Success或者Failure，这个else条件是永远走不到的，所以我们在这里直接抛出了一个异常，只是为了满足Kotlin编译器的语法检查而已。
另外，编写else条件还有一个潜在的风险。如果我们现在新增了一个Unknown类并实现Result接口，用于表示未知的执行结果，但是忘记在getResultMsg()方法中添加相应的条件分支，编译器在这种情况下是不会提醒我们的，而是会在运行的时候进入else条件里面，从而抛出异常并导致程序崩溃.
不过好消息是，Kotlin的密封类可以很好地解决这个问题.
密封类的关键字是sealed class，它的用法同样非常简单，我们可以轻松地将Result接口改造成密封类的写法：
sealed class Result
class Success(val msg: String) : Result()
class Failure(val error: Exception) : Result()
可以看到，代码并没有什么太大的变化，只是将interface关键字改成了sealed class。另外，由于密封类是一个可继承的类，因此在继承它的时候需要在后面加上一对括号
那么改成密封类之后有什么好处呢？你会发现现在getResultMsg()方法中的else条件已经不
再需要了，如下所示：
fun getResultMsg(result: Result) = when (result) {
is Success -> result.msg
is Failure -> "Error is ${result.error.message}"
}
这是因为当在when语句中传入一个密封类变量作为条件时，Kotlin编译器会自动检查该密封类有哪些子类，并强制要求你将每一个子类所对应的条件全部处理。这样就可以保证，即使没有编写else条件，也不可能会出现漏写条件分支的情况。而如果我们现在新增一个Unknown类，并也让它继承自Result，此时getResultMsg()方法就一定会报错，必须增加一个Unknown的条件分支才能让代码编译通过。
这就是密封类主要的作用和使用方法了。另外再多说一句，密封类及其所有子类只能定义在同一个文件的顶层位置，不能嵌套在其他类中，这是被密封类底层的实现机制所限制的。