前言

于2020年3月26号，Jack Wharton 官宣 ButterKnife 废弃了。但是我们就没有必要去学习了吗？显然并不是这样的，一个开源库背后的每一分思想和技术都是我们应该去探究的点。

使用方法

最新版本具体信息根据ButterKnife的官网来进行查找。

1. 导入包。 在app下的build.gradle的dependencies中进行引入,当然高版本也容易出现问题。

implementation 'com.jakewharton:butterknife:10.2.1' annotationProcessor 'com.jakewharton:butterknife-compiler:10.2.1' 

2. 项目中进行使用。 根据官网中给出的使用方式来使用即可，下方只给出一种使用

class ExampleActivity extends Activity { // 通过BindView的一个 @BindView(R.id.title) TextView title; @Override public void onCreate(Bundle savedInstanceState) { super.onCreate(savedInstanceState); setContentView(R.layout.simple_activity);     ButterKnife.bind(this); } } 

通过上述的@BindView的一个注解，将布局中一个控件和引用进行相关联的绑定操作。这样的操作还有很多，下面给出部分：

不得不承认，ButterKnife在一定的程度上会提高我的开发效率，但是他到底是怎么运作呢？

源码分析

在使用ButterKnife的时候其实我们是否注意到一个问题，我们一定需要写一个这样的一段代码。

ButterKnife.bind(this); 

如果不写会出现下方这样的错误。

 @BindView(R.id.view) View view; @Override protected void onCreate(Bundle savedInstanceState) { super.onCreate(savedInstanceState); setContentView(R.layout.activity_main); //        判断写和不写时的区别 //        ButterKnife.bind(this); } @Override protected void onResume() { super.onResume();         view.setOnClickListener(new View.OnClickListener() { @Override public void onClick(View v) { } }); } 

我们能够发现没有加入这句的话的代码出现对象为空的情况，那我们也就能明白ButterKnife的入口其实就是我们必须要写的这一段代码了。

对ButterKnife.bind(this)进行追溯

public static Unbinder bind(@NonNull Activity target) { // DecoView是Window中一个变量，是根布局视图的载体 // 详细需要查看Window的唯一子类PhoneWindow // Activity和Window绑定，获取当前的根视图     View sourceView = target.getWindow().getDecorView(); return bind(target, sourceView); // 1 } // 由注释1调用的函数 public static Unbinder bind(@NonNull Object target, @NonNull View source) {     Class<?> targetClass = target.getClass(); // 去寻找一个构造函数     Constructor<? extends Unbinder> constructor = findBindingConstructorForClass(targetClass); // 2 if (constructor == null) { // 直接返回为空 return Unbinder.EMPTY; } //noinspection TryWithIdenticalCatches Resolves to API 19+ only type. try { return constructor.newInstance(target, source); // 3 } catch (IllegalAccessException e) { // 一些错误处理 } } 

先经过上述代码中的注释2，也就是使去构造一个对象。如果没有找到，就直接返回为空；如果找到构造方法了，就进行构造（使用的ClassLoader来加载，也就是反射机制）。那么主要任务还是注释3通过newInstance函数来完成一个Unbinder对象的创建。

public T newInstance(Object ... initargs) throws InstantiationException, IllegalAccessException,                IllegalArgumentException, InvocationTargetException     { if (serializationClass == null) { return newInstance0(initargs); } else { return (T) newInstanceFromSerialization(serializationCtor, serializationClass); } } 

这里的返回值竟然是一个泛型，说明我们之前有说落了什么？回头看看，其实我们就知道了Constructor<? extends Unbinder> constructor = findBindingConstructorForClass(targetClass);这段函数中传入的泛型正是继承自Unbinder，所以我们的泛型返回值的上界也就能够确定了。

在这里我们明确了一个目标，我们需要找到一个拿到了了Unbinder接口的类。yeap！✌️✌️✌️

如果不清楚泛型的知识建议去查看一下我之前写过的文章，面试官问我：“泛型擦除是什么，会带来什么问题？”

加载文件长相

因为我用的是Android Studio，不知道你们用的啥，我给出的话直接是我这边对应的文件位置所在。
app –> build –> intermeiates –> javac –> 对应java编写时的文件目录

如果你在网上看过别的技术博主的文章，应该是知道ButterKnife是会有生成一个文件后缀为_ViewBinding的文件的，如果完全不清楚😑😑😑，也不碍事！！

现在我们就来看看通过这个ButterKnife生成的代码是长什么样的。

public class MainActivity_ViewBinding implements Unbinder { private MainActivity target; @UiThread public MainActivity_ViewBinding(MainActivity target) { this(target, target.getWindow().getDecorView()); } // 绑定，这里存在两个函数是不是似曾相识呢？ @UiThread public MainActivity_ViewBinding(MainActivity target, View source) { this.target = target; // 通过变量来调用他内部的一个变量     target.view = Utils.findRequiredView(source, R.id.view, "field 'view'"); } // 解绑 @Override @CallSuper public void unbind() {     MainActivity target = this.target; if (target == null) throw new IllegalStateException("Bindings already cleared."); this.target = null;     target.view = null; } } 

在这里其实我们已经明白了，为什么我们的变量只能是public或者不加修饰符的原因了。如果不清楚，Emmmmmm，毕竟我也不是那种严厉的人吧。

但是我们并不只是来看这个的，我们要知道注释的功能是如何实现的？我们看到了一个我们定义的view变量，做了一个Utils.findRequiredView(source, R.id.view, "field 'view'");的操作，我们姑且进去看看好了。

public static View findRequiredView(View source, @IdRes int id, String who) { // 我看到了啥?????????????????????? // findViewById()这个函数是不是非常熟悉呢？     View view = source.findViewById(id); if (view != null) { return view; }     String name = getResourceEntryName(source, id); } 

原来他的寻找原理还是通过findViewById()来完成整个的定位操作的，那ButterKnife的神奇之处也就不再神奇了。

为了验证我们的想法，我对@OnClick的注解做了一个测试。下方贴出ButterKnife中给出的答案。

 @UiThread public MainActivity_ViewBinding(MainActivity target, View source) {     viewSource = source;     source.setOnClickListener(new DebouncingOnClickListener() { @Override public void doClick(View p0) {         target.start(); } }); } 

和我们写的方式还是一模一样的。那我们的好奇心来了，他是如何实现这个代码的输出的，这也是我们整个ButterKnife的核心工作了。

文件生成过程

其实在最开始的导包的时候，我们就应该注意到的一个问题，因为我们导入的ButterKnife并不是只有一个库，而我们上面的那个库的工作明显是一个调用的过程。那猜测一下另外一个库的作用会不会是生成的作用呢？

annotationProcessor 'com.jakewharton:butterknife-compiler:10.2.1' 

注： 如果你的本地显示不出这个库，把annotationProcessor改成implementation即可

这里我们要经历一个测试，他是通过ButterKinife.bind(this);触发的还是@BindView这一类的注解来进行触发的？
测试之后，能够发现ButterKinife.bind(this);删除，对我们的使用完全没有影响，但是删去全部的@BindXXX的注解后，文件没了！！！
这也就说明了文件生成的触发的方式来自于了注解。而注解所在的包的位置正是库com.jakewharton:butterknife-compiler中。但是到底是哪个文件呢？我们只好一个个看过去了。

文件也不多，那我们可以一个个看，但是每次看之前我们都要明确一个目标，当然这是我的一个猜测，他应该要对注解进行一个收集，然后再进行一个源码的生成，而且这个文件中，可能会出现几个如下的特征：

（1）输出的时候会出现一个后缀”_ViewBinding“。

（2）文件路径应该会出现对我们自己的包一个名字获取，也就是获取包名/getPackageName()等获取函数。

（3）编译时就会调用到的一个注解

在ButterKnifeProcessor中我们发现了一个注解@AutoService(Processor.class)说明了这个文件，而这个注解就是为了编译时进行加载的，那我们也就找到了我们的目标了，不过我们这个类中只用关注两个函数作为切入点。

• init()函数是他的一个入口。

@Override public synchronized void init(ProcessingEnvironment env) { super.init(env);      String sdk = env.getOptions().get(OPTION_SDK_INT); if (sdk != null) { try { this.sdk = Integer.parseInt(sdk); } catch (NumberFormatException e) {         env.getMessager() .printMessage(Kind.WARNING, "Unable to parse supplied minSdk option '" + sdk                 + "'. Falling back to API 1 support."); } }      debuggable = !"false".equals(env.getOptions().get(OPTION_DEBUGGABLE));      typeUtils = env.getTypeUtils();     filer = env.getFiler(); try {       trees = Trees.instance(processingEnv); } catch (IllegalArgumentException ignored) { } } 

• process()函数是一个执行过程，主要就是一个文件的输出。

@Override public boolean process(Set<? extends TypeElement> elements, RoundEnvironment env) { // 调用一些parseXXX的函数，来获取注解并生成相对应的数据 // BindView、BindAnim。。。各成一组     Map<TypeElement, BindingSet> bindingMap = findAndParseTargets(env); for (Map.Entry<TypeElement, BindingSet> entry : bindingMap.entrySet()) {       TypeElement typeElement = entry.getKey();       BindingSet binding = entry.getValue(); // 这个文件中会出现相对应的文件操作方式 // 比如上述的一些猜测_ViewBinding后缀的文件创建 // 获取包名等一系列操作了。       JavaFile javaFile = binding.brewJava(sdk, debuggable); try {         javaFile.writeTo(filer); } catch (IOException e) { error(typeElement, "Unable to write binding for type %s: %s", typeElement, e.getMessage()); } } return false; } 

那这里我们也就完全的解释清楚了文件是怎么进行生成的。具体的生成过程还是需要去查看butterknife.compiler包下的BindingSet文件。

总结

在这里就能解决我们的思考的问题了，其实文章中已经解决了大部分的问题，剩下最后一个反射的问题，在这里做一个解答。

private static Constructor<? extends Unbinder> findBindingConstructorForClass(Class<?> cls) {     Constructor<? extends Unbinder> bindingCtor = BINDINGS.get(cls); // 存在缓存的判定，也就说明将我们的反射数据已经有所保存 if (bindingCtor != null || BINDINGS.containsKey(cls)) { if (debug) Log.d(TAG, "HIT: Cached in binding map."); return bindingCtor; } // 通过反射机制创建。     Class<?> bindingClass = cls.getClassLoader().loadClass(clsName + "_ViewBinding");     bindingCtor = (Constructor<? extends Unbinder>) bindingClass.getConstructor(cls, View.class);     BINDINGS.put(cls, bindingCtor); return bindingCtor; } 

这是ButterKnife中一段代码，贴出他的意思很明确，其实就是为了说明会出现反射机制，对性能也确实有一定的消耗，但是这种消耗并不大，因为他做了一个缓冲的机制，也就保障我们的性能还是能够做到较大的缓存的。从编码效率提高的角度来看，这种性能代价并不大。