这篇文章给大家分享的是有关Kotlin中空处理怎么用的内容。小编觉得挺实用的，因此分享给大家做个参考，一起跟随小编过来看看吧。
一、上手的确容易
先扯一扯 Kotlin 学习本身。
之前各种听人说上手容易，但真要切换到另一门语言，难免还是会踌躇是否有这个必要。现在因为工作关系直接上手 Kotlin，感受是 真香（上手的确容易） 。
首先在代码阅读层面，对于有 Java 基础的程序员来说阅读 Kotlin 代码基本无障碍，除去一些操作符、一些顺序上的变化，整体上可以直接阅读。
其次在代码编写层面，仅需要改变一些编码习惯。主要是：语句不要写分号、变量需要用 var 或 val 声明、类型写在变量之后、实例化一个对象时不用 “new” …… 习惯层面的改变只需要多写代码，自然而然就适应了。
最后在学习方式层面，由于 Kotlin 最终都会被编译成字节码跑在 JVM 上，所以初入手时完全可以用 Java 作为对比。比如你可能不知道 Kotlin 里 companion object 是什么意思，但你知道既然 Kotlin 最终会转成 jvm 可以跑的字节码，那 Java 里必然可以找到与之对应的东西。
Android Studio 也提供了很方便的工具。选择菜单 Tools -> Kotlin -> Show Kotlin Bytecode 即可看到 Kotlin 编译成的字节码，点击窗口上方的 “Decompile” 即可看到这份字节码对应的 Java 代码。—— 这个工具特别重要，假如一段 Kotlin 代码让你看得云里雾里，看一下它对应的 Java 代码你就能知道它的含义。
当然这里仅仅是说上手或入门（仅入门的话可以忽略诸如协程等高级特性），真正熟练应用乃至完全掌握肯定需要一定时间。
二、针对 NPE 的强规则
有些文章说 Kotlin 帮开发者解决了 NPE（NullPointerException），这个说法是不对的。 在我看来，Kotlin 没有帮开发者解决了 NPE （Kotlin: 臣妾真的做不到啊），而是通过在语言层面增加各种强规则，强制开发者去自己处理可能的空指针问题，达到尽量减少（只能减少而无法完全避免）出现 NPE 的目的。
那么 Kotlin 具体是怎么做的呢？别着急，我们可以先回顾一下在 Java 中我们是怎么处理空指针问题的。
Java 中对于空指针的处理总体来说可以分为“防御式编程”和“契约式编程”两种方案。
“防御式编程”大家应该不陌生，核心思想是不信任任何“外部”输入 —— 不管是真实的用户输入还是其他模块传入的实参，具体点就是 各种判空 。创建一个方法需要判空，创建一个逻辑块需要判空，甚至自己的代码内部也需要判空（防止对象的回收之类的）。示例如下：
重庆分公司
重庆分公司
public void showToast(Activity activity) {
if (activity == null) {
return;
}
......
}另一种是“契约式编程”，各个模块之间约定好一种规则，大家按照规则来办事，出了问题找没有遵守规则的人负责，这样可以避免大量的判空逻辑。Android 提供了相关的注解以及最基础的检查来协助开发者，示例如下：
public void showToast(@NonNull Activity activity) {
......
}在示例中我们给 Activity 增加了 @NonNull 的注解，就是向所有调用这个方法的人声明了一个约定，调用方应该保证传入的 activity 非空。当然聪明的你应该知道，这是一个很弱的限制，调用方没注意或者不理会这个注解的话，程序就依然还有 NPE 导致的 crash 的风险。
回过头来， 对于 Kotlin，我觉得就是一种把契约式编程和防御式编程相结合且提升到语言层面的处理方式。 （听起来似乎比 Java 中各种判空或注解更麻烦？继续看下去，你会发现的确是更麻烦……）
在 Kotlin 中，有以下几方面约束：
在声明阶段，变量需要决定自己是否可为空，比如 var time: Long? 可接受 null，而 var time: Long 则不能接受 null。
在变量传递阶段，必须保持“可空性”一致，比如形参声明是不为空的，那么实参必须本身是非空或者转为非空才能正常传递。示例如下：
fun main() {
......
// test(isOpen) 直接这样调用，编译不通过
// 可以是在空检查之内传递，证明自己非空
isOpen?.apply {
test(this)
}
// 也可以是强制转成非空类型
test(isOpen!!)
}
private fun test(open: Boolean) {
......
}在使用阶段，需要严格判空：
var time: Long? = 1000 //尽管你才赋值了非空的值，但在使用过程中，你无法这样： //time.toInt() //必须判空 time?.toInt()
总的来说 Kotlin 为了解决 NPE 做了大量语言层级的强限制，的确可以做到减少 NPE 的发生。但这种既“契约式”（判空）又“防御式”（声明空与非空）的方案会让开发者做更多的工作，会更“麻烦”一点。
当然，Kotlin 为了减少麻烦，用 “?” 简化了判空逻辑 —— “?” 的实质还是判空，我们可以通过工具查看 time?.toInt() 的 Java 等价代码是：
if (time != null) {
int var10000 = (int)time;
}这种简化在数据层级很深需要写大量判空语句时会特别方便，这也是为什么 虽然逻辑上 Kotlin 让开发者做了更多工作，但写代码过程中却并没有感觉到更麻烦。
三、强规则之下的 NPE 问题
在 Kotlin 这么严密的防御之下，NPE 问题是否已经被终结了呢？答案当然是否定的。在实践过程中我们发现主要有以下几种容易导致 NPE 的场景：
1. data class（含义对应 Java 中的 model）声明了非空
例如从后端拿 json 数据的场景，后端的哪个字段可能会传空是客户端无法控制的，这种情况下我们的预期 必须是 每个字段都可能为空，这样转成 json object 时才不会有问题：
data class User( var id: Long?, var gender: Long?, var avatar: String?)
假如有一个字段忘了加上”?”，后端没传该值就会抛出空指针异常。
2. 过分依赖 Kotlin 的空值检查
private lateinit var mUser: User
...
private fun initView() {
mUser = intent.getParcelableExtra("key_user")
} 在 Kotlin 的体系中久了会过分依赖于 Android Studio 的空值检查，在代码提示中 Intent 的 getParcelableExtra 方法返回的是非空，因此这里你直接用方法结果赋值不会有任何警告。但点击进 getParcelableExtra 方法内部你会发现它的实现是这样的：
