从 Butter Knife 到 Kotter Knife 再到 Kotlin Android Extensions

Butter Knife

Butter Knife 是安卓开发中常用的一种 View 绑定框架,主要用来减少 View 的获取&强转的样板代码。

原生的安卓 Java 代码中,控件需要自己手动获取和强制转换。

ListView simpleListView;
          @Override
          protected void onCreate(@Nullable Bundle savedInstanceState) {
              // ...
              View view = findViewById(R.id.simple_list);
              simpleListView = (ListView) view;
              simpleListView.setAdapter(adapter);
          }
          

如上面代码所示,至少要经历三个步骤:

  1. 声明 View 变量,包含 View 的具体类型(simpleListView 对象,ListView 类型)
  2. 调用 findViewById 方法获取资源的 View 对象
  3. 将 View 对象强制转换成对应类型的 VIew(ListView)

虽然 2-3 步可以简化成一行代码,但是经历的步骤一定是分明的。

但是通过 View 绑定,这个步骤可以简化到一步:


          @BindView(R.id.simple_list) ListView simpleListView;
          @Override
          protected void onCreate(@Nullable Bundle savedInstanceState) {
              // ...
              simpleListView.setAdapter(adapter);
          }
          

没有 simpleListView 的赋值过程,当然更不会有类型转换代码。因为这之间的步骤 Butter Knife 框架帮你做了。你只用告诉它资源 ID 和接收对象即可,也就是 BindView 注解的作用。

Kotlin 是怎么做的

var simpleListView: ListView? = null
          simpleListView = findViewById(R.id.simple_list) as ListView
          simpleListView?.adapter = adapter
          

在 Kotlin 中也逃不过这三个步骤,但是相比 Java 的优点是强制转换只需要 as 关键字,手敲几乎没不方便的地方。用 Java 的情况下,大家几乎都是在等号右边直接调用 findViewById 然后按 <Ctrl + Enter> 快捷键让 IDE 自动纠正代码这种方式。。。

所以面对这种问题,即便是语法灵活得多的 Kotlin 也没有太大优势,类型的强制转换总是非常令人厌恶的。而且 Kotlin 原生并不支持 Butter Knife 。

让 Kotlin 也用上 View 绑定

让 Kotlin 用上方便的 View 绑定功能主要是两种方式,它们都挺简单:

  1. 让 Butter Knife 在 Kotlin 上正常工作
  2. 选择原生 Kotlin 所支持的 View 绑定框架

第一种方式:

@BindView(R.id.simple_list) @JvmField var simpleListView: ListView? = null
          

JvmField 注解让 Kotlin 实例的字段具有与底层相同的可见性,即对 Java 是可见的,当然它的前提必须是非私有属性。这点对于需要属性注入的情况是必须的,同时也是 Kotter Knife 原生不能支持 Kotlin 的原因。

例如 Kotlin 中并没有 “静态变量” 这个元素,但是提供了 companion object 来模拟静态的调用方式。但是 companion object 在底层仍然不是静态的,这对于 Java 而言企图通过静态调用 Kotlin 的 companion object 里边的内容是不行的。
想让 Kotlin 在底层产生静态实例,需要这样做:

class Key(val value: Int) {
              companion object {
                  @JvmField
                  val COMPARATOR: Comparator<Key> = compareBy<Key> { it.value }
              }
          }
          

此时的 Key.COMPARATOR 对于 Java(或者其它 JVM 语言)都是是静态的,它们在底层采样同样的方式储存。第一种方式之所以能解决也是类似的道理。

第二种方式:

Kotter Knife 是为 Kotlin 语言所写的 View 绑定框架,它这样来使用:

val impleListView: ListView by bindView(R.id.simple_list)
          

从形式上来看,就是把给属性加注解换成了对属性访问进行委托,委托给 bind* 函数。如果你不了解什么是委托,请看这里
注意:Kotlin 中的 by 关键字只是省略了委托中的样板代码,和委托设计模式的思想是一模一样的。此处的属性委托背后的实现也非常简单,属性会被延迟计算,第一次访问时进行 View 的查找和转换,如果没有找到则会抛出异常,异常实例是:

IllegalStateException("View ID $id for '${desc.name}' not found.")
          

究竟应不应该因为一个注解问题放弃 Butter Knife?
首先你要明白,毕竟 @JvmField 也是 Kotlin 语言重要部分的元素之一,这个重要的部分就是:和 Java 的交互调用。所以 Kotlin 并不算是不支持 Butter Knife,在需要它的时候不用多虑,毫无疑问可以当做完全兼容的 Java 类库使用。

Kotlin Android Extensions

然而说到这里,本文的主角还未介绍过… 因为介绍它的时候就是抛弃上述所有东西的时候。你可以将它当做 Kotlin 官方对安卓开发提供的加强支持:它包括了 View 绑定,并且是一种更方便的新形式。它就是: Kotlin Android Extensions

给项目模块的 build.gradle 添加配置:

apply plugin: 'kotlin-android-extensions'
          
          buildscript {
              repositories {
                  jcenter()
              }
              dependencies {
                  classpath "org.jetbrains.kotlin:kotlin-android-extensions:$kotlin_version"
              }
          }
          

然后,就可以直接使用生成的对象了:

// 不可少的 import
          import kotlinx.android.synthetic.main.fragment_main.*
          // 省略其它 import
          class MyFragment : Fragment {
              override fun onViewCreated(view: View?, savedInstanceState: Bundle?) {
                  super.onViewCreated(view, savedInstanceState)
                  // 直接使用 ListView 对象
                  simple_list.adapter = adapter
              }
              // ...
          }
          

注意:我没有声明任何的 ListView 对象,更没有相应的赋值操作,simple_list 是资源 ID。也就是说:我直接将资源 ID 名 simple_list 当做该 ListView 的对象实例使用。

当然,上面的 import 是不能少的,import 的规则是:

import kotlinx.android.synthetic.main.<layout>.*
          

即 import 了相应的 layout ,就能直接使用里边具有 id 属性的 View 实例,将 1-2-3 个步骤全部省略,可谓是最方便的形式。

最后

虽然 Butter Knife 非常优秀,但是既然我能更优雅的解决问题,还能减少依赖,何乐不为。所以:既然你用上了 Kotlin,那么请丢弃所有的 View 注入框架。