最近项目不是很忙，因为项目用到了butterknife框架，所以进行了下系统的研究。研究下来呢发现这个框架真的是吊炸天，而且越研究越觉得太精妙了。虽然并没有完全的把各方面细节都研究明白不过还是算基本原理走痛了。那么这篇就算是一个肤浅的分析吧，所以标题起的有点不要脸。大家见谅下面呢我就开始介绍这个框架啦。
首先呢我先把这个框架的整体思路写出来。然后再扩展开这样大家看起来能清晰点。
butterkknife一个编译时注解注入框架。那么相比那些运行时注解框架相比优势在于运行时注解框架非常耗费内存。而编译时注解内存则相比很节约内存。我们在写注解后再项目编译过程中。
butterknife 会有一个注解处理器。这个处理器会扫描所有有关于我们butterknife 的注解的类。然后生成对应的xxxx_ViewBinding的java类 ，这个java类写的就是我们那些注解要做的操作。比如findviewbyid（），
然后这些java类继承于存在注解的类。那么生成的类 如何与我们实际的类相关联的呢？
在于方法 butterknife.bind（）这个方法会反射调用xxx_viewbinding 类的构造。那么我们那些findvuewbyid 这些代码其实在xxx_viewbinding()的构造里写好了 这样就相当于我们自己写了这些代码省去了很多时间。那么整体的大概原理就是这样的
首先开始讲讲注解的小知识吧 。创建一个注解需要你指定他的作用在哪 是方法，类，字段。 还有要指定他在什么时候作用，运行时，还是编译时。
@Target：
@Target说明了Annotation所修饰的对象范围：Annotation可被用于 packages、types（类、接口、枚举、Annotation类型）、类型成员（方法、构造方法、成员变量、枚举值）、方法参数和本地变量（如循环变量、catch参数）。在Annotation类型的声明中使用了target可更加明晰其修饰的目标。
作用：用于描述注解的使用范围（即：被描述的注解可以用在什么地方）
取值(ElementType)有：
1.CONSTRUCTOR:用于描述构造器
2.FIELD:用于描述域
3.LOCAL_VARIABLE:用于描述局部变量
4.METHOD:用于描述方法
5.PACKAGE:用于描述包
6.PARAMETER:用于描述参数
7.TYPE:用于描述类、接口(包括注解类型) 或enum声明
@Retention：
@Retention定义了该Annotation被保留的时间长短：某些Annotation仅出现在源代码中，而被编译器丢弃；而另一些却被编译在class文件中；编译在class文件中的Annotation可能会被虚拟机忽略，而另一些在class被装载时将被读取（请注意并不影响class的执行，因为Annotation与class在使用上是被分离的）。使用这个meta-Annotation可以对 Annotation的“生命周期”限制。
作用：表示需要在什么级别保存该注释信息，用于描述注解的生命周期（即：被描述的注解在什么范围内有效）
取值（RetentionPoicy）有：
1.SOURCE:在源文件中有效（即源文件保留）
2.CLASS:在class文件中有效（即class保留）
3.RUNTIME:在运行时有效（即运行时保留）
我们的butterknife 的注解就是class 编译时有效。下面介绍完这个注解的基础然后我们开始分析源码
首先这个以bindview 为例
@Retention(CLASS) @Target(FIELD)
public @interface BindView {
/** View ID to which the field will be bound. */
@IdRes int value();
}
这里我们看到指定保留有效为编译 指定使用范围是field 及我们的类变量上 所以我们初始化控件的注解是这样的
@BindView(R.id.swipeLayout)
public MySwipeRefreshLayout swipeLayout;
到这里注解的工作完成。那么我们开始往下走 butterknife.bind(this);这里的话就是通过我们activity的对象获取到了我们activty的根布局view 我们只要有了这个sourceview 就可以进行findviewbyid 的操作了。
@NonNull @UiThread
public static Unbinder bind(@NonNull Activity target) {
View sourceView = target.getWindow().getDecorView();
return createBinding(target, sourceView);
}
我们接下来看createbinding（） 方法 ，发现tagert.getClass（） 获取到了activity 的对象字节码 然后我们通过findBindingConstructorForClass 获取到了ConstructorConstructor 能干什么 他可以直接来创建我们的对象调用对象的构造方法。这就是我说的调用构造来间接调用
注解处理器实现的那些我们省略的代码
private static Unbinder createBinding(@NonNull Object target, @NonNull View source) {
Class targetClass = target.getClass();
if (debug) Log.d(TAG, "Looking up binding for " + targetClass.getName());
Constructor constructor = findBindingConstructorForClass(targetClass);
if (constructor == null) {
return Unbinder.EMPTY;
}
//noinspection TryWithIdenticalCatches Resolves to API 19+ only type.
try {
return constructor.newInstance(target, source);
} catch (IllegalAccessException e) {
}
}
这个Constructor 并不是我们的activty对象 是注解处理器实现的java类的对象 这个对象其实是activity的子类 为了证明这点我们看findBindingConstructorForClass 方法。 我们看到 是首先在 BINDINGS里拿 这个BINDINGS 是什么 他是一个map 他存储了Constructor 对象 static final Map
我们如果在这里拿到了就返回如果没有就往下走 cls.getname() 获取我们的activty的类名 到这里 cls 还是activty的字节码对象 ，然后判断他是不是无效的java类 如果是返回null 如果不是 那么CLassforName(clsname+"+VIewBinding")这个 方法获得我们注解处理器生成的 xxx_viewbinding 类的字节码对象
然后getConstructor (cls,View.class) 这里为什么要传入两个参数 因为我们xx_viewbinding 的构造需要我们activty的对象和 activty的跟View 这样拿到了构造器 放到map集合 并返回 到这里我们知道了 上面我说的 返回的Constructor 并不是我们activity的构造器 是xxx_viewbinding 的构造器
Constructor bindingCtor = BINDINGS.get(cls); if (bindingCtor != null) { return bindingCtor; } String clsName = cls.getName(); if (clsName.startsWith("android.") || clsName.startsWith("java.")) { return null; } try { Class bindingClass = Class.forName(clsName + "_ViewBinding"); bindingCtor = (Constructor) bindingClass.getConstructor(cls, View.class); } catch (ClassNotFoundException e) { bindingCtor = findBindingConstructorForClass(cls.getSuperclass()); } BINDINGS.put(cls, bindingCtor); return bindingCtor;
上面我们吧这一个过程分析完毕了，那么我想给大家看看神秘的 xxx_viewbinding 类 其实这个类我们是能找到的 他就是在build/generated/source/apt/debug 下面 你会发现所有用了注解的类都会有一个对应的xxx_viewbinding 那么我拿出一个来给大家看看 他的 庐山真面目 ,这是我项目里一个登陆的activty大家可以看到 他继承于 我们Loginactivity 所以 你到这里明白了为什么我们的注解 要求用public而不是private 大家可能没看到我这个文章之前不太了解现在你应该知道 就是为了我直接使用我们的 变量 然后进行他们的findviewbyid 等操作。如果是私有的 那么还要通过反射这样很耗费cpu 资源，所以butterknife这个框架可以说考虑的非常全面了。 而且在unbind 的时候 会把这些对象都置为null 这样也大大的避免了内存泄露。
public class LoginActivity_ViewBinding
implements Unbinder {
protected T target;
private View view2131493049;
private View view2131493030;
private View view2131493050;
@UiThread
public LoginActivity_ViewBinding(final T target, View source) {
this.target = target;
View view;
target.et_phone = Utils.findRequiredViewAsType(source, R.id.et_phone, "field 'et_phone'", EditText.class);
target.et_pwd = Utils.findRequiredViewAsType(source, R.id.et_pwd, "field 'et_pwd'", EditText.class);
view = Utils.findRequiredView(source, R.id.tv_forget, "field 'tv_forget' and method 'intentForgetActivity'");
target.tv_forget = Utils.castView(view, R.id.tv_forget, "field 'tv_forget'", TextView.class);
view2131493049 = view;
view.setOnClickListener(new DebouncingOnClickListener() {
@Override
public void doClick(View p0) {
target.intentForgetActivity(p0);
}
});
view = Utils.findRequiredView(source, R.id.img_pwd_isvisible, "field 'img_pwd_isvisible' and method 'changePwdVisible'");
target.img_pwd_isvisible = Utils.castView(view, R.id.img_pwd_isvisible, "field 'img_pwd_isvisible'", ImageView.class);
view2131493030 = view;
view.setOnClickListener(new DebouncingOnClickListener() {
@Override
public void doClick(View p0) {
target.changePwdVisible(p0);
}
});
view = Utils.findRequiredView(source, R.id.bt_login, "method 'clickLogin'");
view2131493050 = view;
view.setOnClickListener(new DebouncingOnClickListener() {
@Override
public void doClick(View p0) {
target.clickLogin(p0);
}
});
}
@Override
@CallSuper
public void unbind() {
T target = this.target;
if (target == null) throw new IllegalStateException("Bindings already cleared.");
target.et_phone = null;
target.et_pwd = null;
target.tv_forget = null;
target.img_pwd_isvisible = null;
view2131493049.setOnClickListener(null);
view2131493049 = null;
view2131493030.setOnClickListener(null);
view2131493030 = null;
view2131493050.setOnClickListener(null);
view2131493050 = null;
this.target = null;
}
}`
到这里 我就吧butterknife的整体的框架分析出来了。不过还是肤浅的 分析。 但是大家肯定很好奇 我们的xxx_viewbinding 是如何产生的呢。那么就请大家关注我的下一篇文章吧。暂时还没有写出来。等写出来欢迎大家来阅读哈。