Kotlin变量,懒点呢,还是迟点呢?

在Kotlin中,给我们引入了关于“惰性初始化”(lazy initialization)这一古老概念的两个新特性,比如将一个变量的初始化延迟到之后的某个时刻。这是一个非常便利的特性,因为我们可以不用初始化直到需要使用它,或者仅仅是因为我们还不具备所有的条件去初始化它。
那让我们先从句法上认识它俩吧。

Initialization by Lazy

val myUtil by lazy {
     MyUtil(parameter1, parameter2)
}

上述代码初始化一个MyUtil对象,但这个动作只会在初次使用myUtil时才会进行。

Late initialization

lateinit var myUtil: MyUtil

一个函数里的某个地方

myUtil = MyUtil(parameter1, parameter2)

上述代码延迟啦初始化myUtil的过程直到我们去初始化它的时候

为什么有两个,使用场景是啥?

即便两者有着相同的概念,但还是有本质上的区别的。仅从变量类型上来看,一个为val(不可变),另一个为var(可变)。不言自明吧。以下是一些典型的使用场景。

单例

有时候,我们只需要一个变量实例,其余共享这个变量。

MyUtil getMyUtil() {
    if (myUtil == null) myUtil = new MyUtil(param1, param2);
    return myUtil;
}

这段代码用来写单例相当方便,确保我们对该变量的访问都是同一个对象。同时它也使得我们需要使用它时才去创建此对象。如此场景,Lazy Initialization便有了用武之地。

初始化一个不可为空(Non-nullable)的变量

Kotlin中,我们定义一个变量的时候必须得声明它可否为空。这有助于编译器在编译时识别出潜在的空对象使用,从而避免空指针异常。
所以对于一个不可为空的成员变量,其类创建之时,它必须设为一个非空值。如果在构造此类事,我们具有所有的依赖,这是没问题的。不幸的是,有些依赖只在之后的某个时刻可用(比如上述param1,param2)。我们从而陷入一个死锁的困境,我们既不能一开始将其设为null(Kotlin可不同意),但我们又必须等到我们得到所有的依赖时才可为其赋值。

莫方,lateinit正向你招手,它允许你在声明变量时可以不对其初始化,直到我们得到所需的依赖对象时再去初始化它也可以。

依赖注入变量

如果我们在KotlIn中使用依赖注入框架(比如Dagger2),所声明的变量不能进行初始化。因此lateinit可以保证该变量之后将被初始化。

@Inject
lateinit var myUtil: MyUtil

事实上,lateinit 正是为此被Kotlin引入的。

什么时候使用呢?

上述例子只涉及到了很少的一些场景。你可以将其运用到更多的场景中,只要他们是不可为空的变量。以下是一些简单的规则帮助你决定使用哪一个。
1.如果该变量可变,使用lateinit
2.如果可以通过外部设置(比如传递外部变量去设置它),使用lateinit。也可以通过lazy,但就没那么直接了。
3.如果只需初始化一次并且为其他共享,更多的是通过内部来设置的话,使用lazy。当然你也可以使用lateinit,但是使用lazy能更好滴封装你的初始化代码。
简言之,对于变量的初始化,懒为上,迟次之,声明时最次。最好是懒一点囖。比尔盖茨说过。

I choose a lazy person to do a hard job. Because a lazy person will find an easy way to do it.” ~Bill Gates

翻译自:Kotlin variable, to be Lazy, or to be Late?

    原文作者:塞上牧羊空许约
    原文地址: https://www.jianshu.com/p/8cffbbd4ee09
    本文转自网络文章,转载此文章仅为分享知识,如有侵权,请联系博主进行删除。
点赞