SickWorm的博客

1. Java 和 Kotlin 构造器代码对比

Java 的构造器声明和方法声明没有太大区别，也支持重载，唯一的限制是：必须调用父类构造器（如果父类只有一个构造器而且是无参的，编译器会帮你自动加上，这是特例）。我们使用 Java 多年，构造器很少会给我们带来不便，也不曾听人吐槽 Java 的构造器声明的不合理，便是无功无过，规规矩矩。但现代编程语言还是从构造器身上找到了优化空间，Scala–Kotlin 是其中之一。

我们不妨直接上代码对比 Kotlin 和 Java 的构造器声明的区别。现在我们有这样一个 android.view.View 的子类，它的 Java 实现：

public class RecordingBottomView extends ConstraintLayout implements View.OnClickListener {

    private static final String TAG = "RecordingBottomView";
    private static final int DEFAULT_VALUE = 100;
    private EffectBarDialog effectBarDialog = new EffectBarDialog(getContext());

    private TextView channelButton;
    public TextView effectButton;
    private TextView restartButton;
    private TextView finishBtn;

    private RecordPlayButton playButton;
    private TextView switchCameraButton;
    private TextView filterButton;
    private TextView resumeTips;

    private int defaultValue = DEFAULT_VALUE;

    public RecordingBottomView(Context context) {
        super(context);
        init(context, null, 0);
    }

    public RecordingBottomView(Context context, AttributeSet attrs) {
        super(context, attrs);
        init(context, attrs, 0);
    }

    public RecordingBottomView(Context context, AttributeSet attrs, int defStyleAttr) {
        super(context, attrs, defStyleAttr);
        init(context, attrs, defStyleAttr);
    }

    private void init(Context context, AttributeSet attrs, int defStyleAttr) {
        LayoutInflater.from(context).inflate(R.layout.recording_bootom_panel, this, true);
        findViewById(R.id.recording_channel_switch_btn).setOnClickListener(this);
        channelButton = findViewById(R.id.recording_channel_switch_btn);
        effectButton = findViewById(R.id.recording_effect_btn);
        effectButton.setOnClickListener(this);


        restartButton = findViewById(R.id.recording_restart_btn);
        restartButton.setOnClickListener(this);
        finishBtn = findViewById(R.id.recording_finish_btn);
        finishBtn.setOnClickListener(this);

        switchCameraButton = findViewById(R.id.song_record_camera_switch);
        switchCameraButton.setOnClickListener(this);
        filterButton = findViewById(R.id.song_record_filter);
        filterButton.setOnClickListener(this);
        playButton = findViewById(R.id.recording_play_button);
        playButton.setOnClickListener(this);
        resumeTips = findViewById(R.id.song_record_resume_tip_btn);

        effectBarDialog.setSoundSelectListener(reverbId -> {
            LogUtil.i(TAG, "soundSelect");
            return Unit.INSTANCE;
        });
        effectBarDialog.setToneChangeListener((isUp, toneValue) -> {
            LogUtil.i(TAG, "toneChange");
            return Unit.INSTANCE;
        });
        effectBarDialog.setVolumeChangeListener(volume -> {
            LogUtil.i(TAG, "volumeChange");
            return Unit.INSTANCE;
        });

        if (attrs != null) {
            TypedArray ta = context.obtainStyledAttributes(attrs, R.styleable.RecordingBottomView);
            defaultValue = ta.getInt(R.styleable.RecordingBottomView_default_value, DEFAULT_VALUE);
        }
    }

    @Override
    public void onClick(View v) {
        // handle click
    }
}

非常经典的代码，在构造器中初始化所有的子 View 成员变量以及 View 参数。

对应的，Kotlin 风格的实现如下：

class RecordingBottomView(context: Context, attrs: AttributeSet?, defStyleAttr: Int):
        ConstraintLayout(context, attrs, defStyleAttr),
        View.OnClickListener {

    constructor(context: Context): this(context, null, 0)

    constructor(context: Context, attrs: AttributeSet?): this(context, attrs, 0)

    init {
        LayoutInflater.from(context).inflate(R.layout.recording_bootom_panel, this, true)
        findViewById(R.id.recording_channel_switch_btn).setOnClickListener(this)
    }

    private val effectBarDialog = EffectBarDialog(context).also {
        it.soundSelectListener = { reverbId: Int? ->
            LogUtil.i(TAG, "soundSelect")
        }
        it.toneChangeListener = { isUp: Boolean?, toneValue: Int? ->
            LogUtil.i(TAG, "toneChange")
        }
        it.volumeChangeListener = { volume: Float? ->
            LogUtil.i(TAG, "volumeChange")
        }
    }

    private val channelButton = findViewById(R.id.recording_channel_switch_btn).also {
        it.setOnClickListener(this)
    }

    var effectButton = findViewById(R.id.recording_effect_btn).also {
        it.setOnClickListener(this)
    }

    private val restartButton = findViewById(R.id.recording_restart_btn).also {
        it.setOnClickListener(this)
    }

    private val finishBtn = findViewById(R.id.recording_finish_btn).also {
        it.setOnClickListener(this)
    }

    private val playButton: RecordPlayButton? = null
    private val switchCameraButton = findViewById(R.id.recording_finish_btn).also {
        it.setOnClickListener(this)
    }

    private val filterButton = findViewById(R.id.recording_finish_btn).also {
        it.setOnClickListener(this)
    }

    private val resumeTips = findViewById(R.id.song_record_resume_tip_btn)

    private val defaultValue: Int = let {
        attrs?: DEFAULT_VALUE

        val ta = context.obtainStyledAttributes(attrs, R.styleable.RecordingBottomView)
        val value = ta.getInt(R.styleable.RecordingBottomView_default_value, DEFAULT_VALUE)
        ta.recycle()
        value
    }

    override fun onClick(v: View) {}

    companion object {
        private const val TAG = "RecordingBottomView"
        private const val DEFAULT_VALUE = 100
    }
}

这里暂且不展开谈 默认参数，view binding，also let 闭包的知识点，这些知识点会在其他文章单独介绍。

对我而言，在我接触 Kotlin 这种构造器声明之前，我没有想过 Java 的构造器声明有什么缺点。但当我接触之后，我开始思考 Kotlin 为什么要这样设计构造器声明，以及 Java 构造器声明的不足之处：

1. **Java 构造器成员变量如果依赖构造参数，它们的声明和最终赋值是分离的，同一个成员变量的代码是低内聚的。**而且像```defaultValue```这个参数，虽然他有初始值，但在一定条件下，他可能会被重新赋值。这些问题都会增加阅读者的心智负担；

2. 所有的初始化代码都在一个函数中，很容易出现“超级函数”。**不同成员变量的初始化代码大部分互相没有联系，但是却以先后顺序的形式耦合在同一个函数中，这是高耦合的。**

3. Java 构造器允许重载，虽然设计规范提倡重载函数应最终调用同一个实现，以得到清晰的逻辑表达。但这不是强制性的。这意味着你可能会遇到多个构造器各自拥有自己的实现，这会加重问题 1，2 的严重性。

对应的，Kotlin 采用了如下对策来一一解决这些问题：

1. property 声明初始化时允许使用主构造器参数，变量声明和初始化代码都写在同一个地方，代码是高内聚的；

2. 使用 let 闭包后，成员变量的所有的初始化代码都可以写在闭包内。不同的成员变量初始化代码相互独立，代码是低耦合的；

3. 仅允许一个主构造器，其他构造器为从构造器，并约定从构造器必须调用主构造器，让主构造器去调用父构造器。

如果 Kotlin 类没有声明主构造器，全部都是从构造器，则退化为 Java 构造器风格，没有调用主构造器的约束。这样的设计一是为了 Java 转 Kotlin 代码时能兼容旧代码结构，不用重构也能直接转换为 Kotlin 代码；二也方便了 Java 转 Kotlin 自动化工具的实现。但 property 的初始化无法引用从构造器的入参，因为从构造器是可以有多个的，从调用上无法保证每个从构造器的每个参数都存在。

2. Kotlin 构造器实现分析

上面我们简单的过了一遍 Kotlin 对 Java 构造器的优化，但 Java 采用这样的设计，是因为它忠实的反映了 JVM 的构造器实现。而 Kotlin 的构造器设计，并不符合 JVM 的实现。Kotlin 要最终在 JVM 上运行，必须在编译期处理，最终变回类似 Java 构造器的实现。

我们直接看一下 Kotlin 编译再反编译后的字节码：

public RecordingBottomView(@NotNull Context context, @Nullable AttributeSet attrs, int defStyleAttr) {
        Intrinsics.checkParameterIsNotNull(context, "context");
        super(context, attrs, defStyleAttr);
        TypedArray ta = context.obtainStyledAttributes(attrs, R.styleable.RecordingBottomView);
        int value = ta.getInt(R.styleable.RecordingBottomView_default_value, 100);
        ta.recycle();
        this.defaultValue = value;
        LayoutInflater.from(context).inflate(R.layout.recording_bootom_panel, (ViewGroup) this, true);
        findViewById(R.id.recording_channel_switch_btn).setOnClickListener(this);
        EffectBarDialog it = new EffectBarDialog(context);
        it.setSoundSelectListener(RecordingBottomView$effectBarDialog$1$1.INSTANCE);
        it.setToneChangeListener(RecordingBottomView$effectBarDialog$1$2.INSTANCE);
        it.setVolumeChangeListener(RecordingBottomView$effectBarDialog$1$3.INSTANCE);
        this.effectBarDialog = it;
        View findViewById = findViewById(R.id.recording_channel_switch_btn);
        ((TextView) findViewById).setOnClickListener(this);
        this.channelButton = (TextView) findViewById;
        View findViewById2 = findViewById(R.id.recording_effect_btn);
        ((TextView) findViewById2).setOnClickListener(this);
        this.effectButton = (TextView) findViewById2;
        View findViewById3 = findViewById(R.id.recording_restart_btn);
        ((TextView) findViewById3).setOnClickListener(this);
        this.restartButton = (TextView) findViewById3;
        View findViewById4 = findViewById(R.id.recording_finish_btn);
        ((TextView) findViewById4).setOnClickListener(this);
        this.finishBtn = (TextView) findViewById4;
        View findViewById5 = findViewById(R.id.recording_finish_btn);
        ((TextView) findViewById5).setOnClickListener(this);
        this.switchCameraButton = (TextView) findViewById5;
        View findViewById6 = findViewById(R.id.recording_finish_btn);
        ((TextView) findViewById6).setOnClickListener(this);
        this.filterButton = (TextView) findViewById6;
        this.resumeTips = (TextView) findViewById(R.id.song_record_resume_tip_btn);
        RecordingBottomView recordingBottomView = this;
        if (attrs == null) {
            Integer.valueOf(100);
        }
    }

public RecordingBottomView(@NotNull Context context) {
    Intrinsics.checkParameterIsNotNull(context, "context");
    this(context, null, 0);
}

public RecordingBottomView(@NotNull Context context, @Nullable AttributeSet attrs) {
    Intrinsics.checkParameterIsNotNull(context, "context");
    this(context, attrs, 0);
}

可以看到，property 和 init 块的初始化代码会被顺序的放入主构造器中，也就是说代码是从上往下按顺序执行的。因此 Kotlin 的初始化代码不仅可以使用主构造器的参数，还可以使用比自己先初始化的 property 和 init 块。

版权所有，转载请注明出处：
https://sickworm.com/?p=1810

1. Java 的函数重载和烦恼

在 Java 中，当我们要实现同一种功能，但函数入参出参不一样的函数的时候，我们可以用到 Java 的函数重载功能。在 Android framework 中同样也存在大量的重载函数，以方便开发者调用。重载函数深入人心，得到大家的认可。

东西确实是好东西，但当重载函数过多的时候，代码就显得臃肿了，比如这里有一个 Toast 显示的工具类，在经过不断的功能扩展后，发展成一个拥有海量重载方法的类：

// ...

public static void show(CharSequence msg) {
    show(Toast.LENGTH_SHORT, msg, Gravity.CENTER_HORIZONTAL | Gravity.BOTTOM);
}

public static void showLong(CharSequence msg) {
    show(Toast.LENGTH_LONG, msg, Gravity.CENTER_HORIZONTAL | Gravity.BOTTOM);
}

public static void show(Activity activity, int resId) {
    show(activity, resId, Gravity.CENTER_HORIZONTAL | Gravity.BOTTOM);
}

public static void show(Activity activity, CharSequence msg) {
    show(Toast.LENGTH_SHORT, activity, msg, Gravity.CENTER_HORIZONTAL | Gravity.BOTTOM);
}

/**
 * 当msg0不为空时展示msg0，忽略msg1；否则显示msg1
 */
public static void show(Activity activity, CharSequence msg0, CharSequence msg1) {
    if (!TextUtils.isEmpty(msg0)) {
        show(Toast.LENGTH_SHORT, activity, msg0, Gravity.CENTER_HORIZONTAL | Gravity.BOTTOM);
    } else if (!TextUtils.isEmpty(msg1)) {
        show(Toast.LENGTH_SHORT, activity, msg1, Gravity.CENTER_HORIZONTAL | Gravity.BOTTOM);
    }
}

public static void show(Activity activity, int resId, int gravity) {
    show(Toast.LENGTH_SHORT, activity, resId == 0 ? null : getString(resId), gravity);
}

public static void show(int duration, Activity activity, int resId) {
    show(duration, activity, resId == 0 ? null : getString(resId), Gravity.CENTER_HORIZONTAL | Gravity.BOTTOM);
}

public static void show(int duration, Activity activity, CharSequence msg) {
    show(duration, activity, msg, Gravity.CENTER_HORIZONTAL | Gravity.BOTTOM);
}

public static void show(final int duration, Activity activity, final CharSequence msg, final int gravity) {
    // 具体实现
}

// ...

和 get/set 方法一样，这是典型的信息密度低的代码。那么有什么办法能够更精简的表达同样的功能，不同的入参的特性呢？有的，就是默认参数特性。

2. 重载函数的替代者，默认参数

Kotlin 拥有默认参数的特性，如果用 Kotlin 实现上述 Java 代码，可以简化为：

fun show(msg: CharSequence,
        msg2: CharSequence? = null,
        context: Context = Global.getApplicationContext(),
        gravity: Int = Gravity.CENTER_HORIZONTAL | Gravity.BOTTOM,
        duration: Int = Toast.LENGTH_SHORT) {
    // 具体实现
}

我们看到，声明默认参数的方法很简单，只需要把可以使用默认参数的入参用“=“号给他赋值一个默认值即可。一般来说，我们会把必须提供的参数写在前面，有默认参数的入参排在后面。因为你在调用的时候，函数的入参默认是按顺序映射的，按上面的顺序排列的话，你只需要填完必须的参数即可；而如果还想提供可选参数，就继续按顺序填写。

那如果我只想提供部分可选参数，比如上面的show函数我只想提供duration参数，跳过其他可选参数呢？Kotlin 提供了这样的调用办法：

show("this is a toast");
show("this is a toast, duration = Toast.LENGTH_LONG);
show(msg = "this is a toast, duration = Toast.LENGTH_LONG);
show(duration = Toast.LENGTH_LONG, msg = "this is a toast);

我们发现，Kotlin 方法调用时，可以显式的指明对象和入参的映射关系，无需按顺序传递。注意，这个特性不分必须参数和可选参数，所有的参数都可以用这种形式指定映射。

但一般来说，我们只在可选参数时用到。还有一种应用场景是，当你觉得必须参数的值让人迷惑，想显式的告诉阅读者这个值所对应的入参时。

大家可能已经发现，很早以前，Android Studio 对没有提供名字的函数参数，已经默认显示这个参数对应的名字。

Flutter 的 Dart 语言也有默认参数特性，而且 Flutter 组件对默认参数的使用可谓是淋漓尽致。它会把一个控件所有可配置的参数都提供在构造函数中，而且把必须参数和可选参数分开。这样开发者可以很方便的看到它必须配置和可以配置的所有参数，不用再去慢慢找这个控件提供了什么设置方法。

3. 默认参数和函数重载对比

默认参数和重载函数对比，重载函数可以改变入参和出参（返回值），默认参数只可以改变入参。不过改变出参的场景实在很少，一般我们都会用不同的函数名来区分不同的返回值，比如 covertToFloat，covertToInt。

其次，每一个重载函数都是一个方法，会记录在方法表，占用 Dex 的最大方法数。默认参数会生成 2 个方法，一个是全参数的方法 A，另一个方法 B 也是全参数，但比全参数方法多出来了 flag 参数，该 flag 参数用来记录哪些参数是可选参数。外部调用的时候调用的是方法 B，没有指定的可选参数将会被赋值 0 或 false 或 null，指定了的可选参数会被赋值，且对应个 flag 位会被标记。到了方法 B 内部，没有被 flag 标记的参数，会被设置为默认值，最后方法 B 调用 方法 A。Kotlin 通过这种方式，减少了重载函数可能带来过多的方法数。

Kotlin 也支持函数重载。

4. 函数声明的特性发展

如果是一开始接触的都是高级语言的同学，可能会觉得函数重载是个比较奇怪的特性：为什么这也算是一种特性？他们除了方法名是一样的，入参不一样，出参不一样，为什么要单独拿出来说呢？这是因为在 C 语言时代，方法的识别只通过函数名，所以无法做到函数重载。后来大家感受到同名函数不同参数存在的必要性，像 C++，就把方法的入参和出参都写到了符号表里。Java 的方法签名，也是包含入参和出参的。这样的语言，就具备识别重载函数的能力，所以函数重载就成为了一种新特性。

但函数重载，是一个个不同的函数，只是名字一致而已。在语义精简和代码规范有一定的缺陷。语义精简就是“更少的代码表达相同的意图”；而代码规范，因为函数重载的功能基本是相同的，更推荐的做法是函数重载只有一份实现代码，其他函数重载都补全参数，然后调用这个完整的实现代码，就像开头的 Toast 工具类代码一样。但实际上由于缺少实际约束，有些开发者会复制多份实现，填入到不同的重载函数中。可以说函数重载容易写出，“smelly”的代码。

而默认参数特性，避免了函数重载的语义精简和代码规范缺陷。

版权所有，转载请注明出处：
https://sickworm.com/?p=1794