ButterKnife 写给一知半解的同学

ButterKnife GitHub 2019 年已经更新到 10.1.0 版本了，经过几天的学习和网上搜索资料，发现之前版本的一些疑难杂症已经不存在或者有些改善。刚开始用是非常爽的，如果真的要应用在项目中，有如下建议：

1. 一个 module 撸到底的项目，直接用吧，没啥坑，都挺好。
2. 大项目组件化的项目，可以尝试。低版本据搜索有很多坑，我在 10.1.0 版本实验了一下，配置得当没有问题。但我这个组件化写得很简单，如果你的项目更加复杂，就要动手试试了，需要试两个地方：一个看能不能编译通过；另一个看运行期间绑定的是否正确。

配置步骤

这个步骤按照 github 页面上的说明设置就行，这里用列表记录一下步骤：

给 application 模块配置：

1. 设置为 Java8，介个 10.1.0 船新版本得用 8 了。

android {
  ...
  // Butterknife requires Java 8.
  compileOptions {
    sourceCompatibility JavaVersion.VERSION_1_8
    targetCompatibility JavaVersion.VERSION_1_8
  }
}

2. 添加依赖：库 + 注解处理

dependencies {
  implementation 'com.jakewharton:butterknife:10.1.0'
  annotationProcessor 'com.jakewharton:butterknife-compiler:10.1.0'
}

给 library 模块设置：

1. 先按照 application 模块的方法设置一遍
2. 在 project level 的 gradle 文件中添加 buildscript 依赖

buildscript {
  repositories {
    google()
    jcenter()
   }
  dependencies {
    classpath 'com.android.tools.build:gradle:3.4.0'
    classpath 'com.jakewharton:butterknife-gradle-plugin:10.1.0' //  这里
  }
}

3. 在 library 模块的 gradle 文件中 apply，写在 android library 插件的下面

apply plugin: 'com.android.library'
apply plugin: 'com.jakewharton.butterknife' //  这里

基本使用

举个例子

@BindView(R.id.clock_view) //  找到资源
View mClockView;           //  找到变量

@Override
protected void onCreate(Bundle savedInstanceState) {
    super.onCreate(savedInstanceState);
    setContentView(R.layout.activity_lib_main);
    ButterKnife.bind(this); //  绑定
}

ButterKnife 的主要目的是简化资源和代码之间的绑定，使用起来很简单，主要有以下（看起来像废话一样的）几个步骤：

1. 找到资源：R.id.clock_view
   • 如果是 application 模块，通过 R.id.xxx, R.string.xxx 等找到资源。
   • 如果是 library 模块，需要使用 ButterKnife 生成的 R2 来替代 R。原因如下：

因为注解中的 ElementValue 值（写在括号内的 R.id.xxx）必须是常量，而 R 在 library 中的 id 值都是变量。

为什么注解中的 ElementValue 必须是常量？因为使用注解时产生的所有信息在编译期间必须确定下来，直接写入注解内部的数据结构中。即使是 @Retention(RetentionPolicy.RUNTIME) 修饰的注解，也不可能在运行时动态运行一段字节码来计算，这样会徒增复杂度而且没有什么好处。

在 application 模块中，R 类中的标识符都是 final 的，也就是常量，是在编译期就能确定值的。而在 library 模块中，R 类中的标识符不是 final 的，在编译期无法确定。library 中不用常量的理由是 R 中的各种 id 值在一个 app 内必须是互不相同的，如果 library 模块在编译期就将这些 id 确定为常量的话，那么必须要考虑所有编译模块，会降低编译速度；而且 library 模块是共享的，如果使用了固定的 id 值，分发给其他项目使用难免会产生冲突。具体分析可以参考这个官方页面：Non-constant Fields in Case Labels

2. 找到变量：View mClockView;
   • 不能声明成 private，因为要通过 ButterKnife 生成的类访问，而 private 修饰的成员只有自己才能访问。ButterKnife 生成的类与绑定的类在同一个包内，直接什么都不写用包访问权限就可以了。
   • 一旦写好变量和修饰它的注解，ButterKnife 就可以生成绑定的代码了，注意只是生成了绑定的代码，如果不调用这个生成的代码，也是没有完成绑定的。绑定的代码很简单，就是将找到的资源和变量关联起来。
3. 绑定：ButterKnife.bind(this);

   • 这个步骤就是调用 ButterKnife 生成的绑定代码。在调用绑定代码之前，应该设置好 layout 文件，以便能通过资源 id 找到资源；在调用绑定代码之后，成员变量才绑定到资源上，这时才能访问成员变量。

   • 根据绑定变量所在的类的类型，bind 方法还有几个版本，比如绑定 Fragment 中的变量要用 bind(this, view)，完整代码：

     @Override
     public View onCreateView(LayoutInflater inflater, ViewGroup container,
                                Bundle savedInstanceState) {
         View view = inflater.inflate(R.layout.fragment_first, container, false);
         unbinder = ButterKnife.bind(this, view);
         return view;
     }
     

   • bind 方法的参数 target 必须是绑定的成员所在的类的对象。

   • bind 方法会返回一个 Unbinder 对象，可以用来解除绑定。但几乎所有情况都不需要手动调用，只有在 Fragment 中绑定才需要在 onDestroyView() 中手动解除。

原理简要分析

说白了 ButterKnife 就是替我们写了一些重复度很高的代码，我们只用关注绑定关系本身，重复的绑定代码都由 ButterKnife 生成。

那么凭什么 ButterKnife 能替我们写代码呢，就要借助注解（Annotation）和注解处理工具（APT）了。

简单说一下注解，注解就是带 @ 符号开头的修饰类、方法、变量等等的一些看起来不像代码的东西。Java 语言本身有一些内置的注解，最常见的要数 @Override 了。可以把注解当做给 Java 中的类、方法、字段等语法元素添加属性，再通过各种工具进行处理，来达到一定的目的。对 ButterKnife 来说，目的就是将资源和变量关联起来，不用再手动调用绑定的代码。ButterKnife 利用注解给成员赋予了资源 id 的属性，再经过 ButterKnife 的处理就可以将两者关联在一起。

那么是怎么关联的呢？这就要提一下注解的两种主要使用形式：反射和生成代码。ButterKnife 早期的版本就是用的反射来实现绑定，后来发现效率不如生成代码的实现方式，于是就改成了生成代码的方式。

生成代码的过程使用了注解处理工具（APT），它是一个运行在构建流程中的一个工具，可以读取到注解和被注解元素的信息，再通过自定义的处理器（也就是 gradle 依赖中的annotationProcessor 'com.jakewharton:butterknife-compiler:10.1.0'）输出 Java 源代码，并将其纳入构建过程。

接下来从代码角度分析原理：

1. 对于绑定的成员所在的类，ButterKnife 会生成一个对应的 Unbinder 类型，也就是实现了 Unbinder 接口的一个类。
   • 别看它叫 Unbinder，实际上绑定和解绑都是使用这个对象，绑定用构造方法，解绑用 unbind() 方法。
   • 这个类与被绑定的类在同一个包下，因此可以访问到包访问权限的成员。
   • 这个类的名字是按照规则生成的，被绑定类的名字加一个固定后缀就是这个 Unbinder 类型的名字。
2. ButterKnife.bind(target, view) 方法内部会根据传入的 target 类型，通过名称规则拼接出生成的 Unbinder 类型的类名称，然后使用反射调用构造方法，也就是执行了绑定的代码。再将这个 Unbinder 对象返回，这样就可以通过这个对象调用 unbind() 方法来解除绑定。

组件化的影响

先说明一下我这个简单的组件化是怎么做的：

1. 在 gradle.properties 文件中定义了一个变量 isModule_libdemo1=true 用来设置作为 library 还是作为 application。
2. 在 library 模块的 build.grale 中，通过 isModule_libdemo1 的值来使用不同 plugin。

if (isModule_libdemo1.toBoolean()) {
    apply plugin: 'com.android.library'
} else {
    apply plugin: 'com.android.application'
}

3. 使用不同的 manifest 文件（略）

ButterKnife 在组件化过程中有什么坑吗？

由于是 library 模块，代码用的都是 R2 对象，一旦切换 plugin，由 library 变成 application，就没有 R2 对象了吗，就应该用 R 对象了吗？

if (isModule_libdemo1.toBoolean()) {
    apply plugin: 'com.android.library'
} else {
    apply plugin: 'com.android.application'
}
apply plugin: 'com.jakewharton.butterknife'

即使是 application，也可以使用 ButterKnife 插件，可以生成 R2 对象，因此应该统一使用 R2 来寻找资源。

其他注意事项

• 重构资源名称：用重构工具可以帮你快速修改。但 ButterKnife 生成的 R2 中的名字 Android Studio 可不管，这时编译一下就能发现问题。但最好不要改成原来就有的名字，会没有任何提示默默编译成功，在运行的时候给你出错。
• @OnClick 与 R2：在 @OnClick(id) 修饰的方法中，即使 id 是 R2 的写法，方法体内部仍要使用 R 对象中的 id 来区分多个按钮的 id。可以这么理解，R2 是 ButterKnife 为了绕开资源 id 非常量的问题，R2 与 R 是能一一对应的，因此能够在生成的 Unbinder 代码使用正确的 R 中的 id。

(ole)