不要总是相信 @JvmOverloads

image.png

原文：http://mrw.so/5ghhcs
译者：依然范特稀西

在使用Kotlin编程时，通常可以通过@JvmOverloads注解把多个构造函数合并成一个构造函数，尤其是当通过继承Android View 来自定义View 的时候。大多数情况下，这样写是没问题的，但是有时候它又会出现一些意想不到的问题。

让我们看一下@JvmOverloads的定义：

Instructs the Kotlin compiler to generate overloads for this function that substitute default parameter values.
If a method has N parameters and M of which have default values, M overloads are generated: the first one takes N-1 parameters (all but the last one that takes a default value), the second takes N-2 parameters, and so on.

什么意思呢？解释一下：

告诉Kotlin编译器为@JvmOverloads注解的方法替换默认参数生成重载函数
如果一个方法有N个参数且其中M个有默认值，则会产生M个重载：第一个取N-1个参数（除了最后一个取默认值），第二个取N-2个参数，以此类推。

听来不错，因此我们经常将这些构造函数：

class CustomLinearLayout : LinearLayout {
constructor(context: Context?) : super(context)
constructor(context: Context?, attrs: AttributeSet?) : super(context, attrs)
constructor(context: Context?, attrs: AttributeSet?, defStyleAttr: Int) : super(context, attrs, defStyleAttr)
}

合并成一个构造函数：

class CustomLinearLayout @JvmOverloads constructor(
        context: Context, attrs: AttributeSet? = null, defStyleAttr: Int = 0
) : LinearLayout(context, attrs, defStyleAttr)

第0步： 出现的问题

我们先来看看Design库中的TextInputEditText控件，

在我们自定义类中，如下：

class CustomTextInputEditText : TextInputEditText {
constructor(context: Context) : super(context)
constructor(context: Context, attrs: AttributeSet?) : super(context, attrs)
constructor(context: Context, attrs: AttributeSet?, defStyleAttr: Int) : super(context, attrs, defStyleAttr)
}

上面的代码可以通过一个构造函数来替换：

class CustomTextInputEditText @JvmOverloads constructor(
        context: Context, attrs: AttributeSet? = null, defStyleAttr: Int = 0
) : TextInputEditText(context, attrs, defStyleAttr)

这也是Android Studio 会自动为我们生成的代码

image.png

接下来我们写一个Activity，它有两个CustomTextInputEditText 控件，第一个包含所有三个构造函数，第二个包含 @JvmOverloads注释。

class CustomTextInputEditText1 : TextInputEditText {
    constructor(context: Context) : super(context)
    constructor(context: Context, attrs: AttributeSet?) : super(context, attrs)
    constructor(context: Context, attrs: AttributeSet?, defStyleAttr: Int) : super(context, attrs, defStyleAttr)
}
class CustomTextInputEditText2 @JvmOverloads constructor(
        context: Context, attrs: AttributeSet? = null, defStyleAttr: Int = 0
) : TextInputEditText(context, attrs, defStyleAttr)

它们的表现最终会相同吗？

[图片上传失败...(image-465510-1568899351475)]

正如你所看到的，第二个使用@JvmOverloads注解的控件没有工作。

发生了什么？为什么会有一些样式问题？

image.png

第1步: 理解@JvmOverloads注解

让我们再花1秒钟回看一下JvmOverloads 的定义，我们知道Kotlin编译器会产生两个重载（在我们的例子中N = 3和M = 2）。所以我们最终会得到三个类似的构造函数：

@JvmOverloads
public CustomTextInputEditText(@NotNull Context context, @Nullable AttributeSet attrs, int defStyleAttr) {
   super(context, attrs, defStyleAttr);
}
@JvmOverloads
public CustomTextInputEditText(@NotNull Context context, @Nullable AttributeSet attrs) {
   this(context, attrs, 0);
}
@JvmOverloads
public CustomTextInputEditText(@NotNull Context context) {
   this(context, null, 0);
}

因此在我们的自定义类中，我们总是会调用到CustomTextInputEditText三参数构造函数。

第2步：理解View的构造函数

现在让我们暂时关注到View的构造函数。

当View从XML文件中加载时，会调用其第二个构造函数。然后，此构造函数调用三参数构造函数。

public View(Context context, @Nullable AttributeSet attrs) {
    this(context, attrs, 0);
}

如果通常将0作为第三个参数，为什么这个三参数构造函数要存在呢？答案在文档中。

View的这个构造函数允许子类在加载时使用它们自己的基本样式。

继承自View的类可以传递它们自己的样式来修改所有基本view属性。

简单，现在我们来看看为什么会出错。

第3步：了解到底哪儿出了问题

此时，从第1步开始，我们知道由于@JvmOverloads注解，我们总是调用一个三参数构造函数，而从第2步开始，继承自View的类可以使用这个三参数构造函数来传递它们自己的样式。

让我们回到TextInputEditText的构造函数来看看，特别是第二个：

public TextInputEditText(Context context, AttributeSet attrs) {
    this(context, attrs, attr.editTextStyle);
}

这里正是问题的所在，TextInputEditText的三参数构造函数默认传的是android.support.design.R.attr.editTextStyle样式，当我们使用@JvmOverloads时，默认参数传的是0,因此就丢失了原来的样式。

第4步： 修复问题

从TextInputEditText的实现我们知道 ,android.support.design.R.attr.editTextStyle作为它第三个参数传递，所以我们可以通过将它设置为defStyleAttrparam的默认值来进行修复：

class CustomTextInputEditText @JvmOverloads constructor(
        context: Context, attrs: AttributeSet? = null, defStyleAttr: Int = android.support.design.R.attr.editTextStyle
) : TextInputEditText(context, attrs, defStyleAttr)

现在，一切都正常运行了，除非...... TextInputEditText的构造函数实现将发生变化，例如通过它传递其他样式。

另一个例子，我们正在使用的子类组件本来工作得很好，突然看起来与我们app中的其他部分有点不同，因为它的新版本开始传递样式，我们只在这一个地方继承它。

如何保持安全？

当使用@JvmOverloads 存在风险的时候，就不要使用它了，通过实现所有构造函数来代替，只是在实现所有构造函数时编写一些注释，以便将来可以理解。

一些最后的笔记

本文挑选TextInputEditText作为一个例子，但同样的情况将发生在Button，EditText，RadioButton，Switch，和许多其他组件。

您可以在我的Github仓库中找到展示这些问题的示例实现。

本文的一个重要内容 - 如果你在使用继承View来自定义一些组件遇到显示样式有问题时，那么检查您是否使用@JvmOverloads是值得的。也许就是它导致的错误。