ButterKnife源码分析

最新推荐文章于 2024-09-18 11:19:13 发布

ImTryCatchException

最新推荐文章于 2024-09-18 11:19:13 发布

阅读量376

点赞数 1

分类专栏：源码分析文章标签：源码 android ButterKnife

本文链接：https://blog.csdn.net/imtrycatchexception/article/details/68944968

版权

源码分析专栏收录该内容

6 篇文章 1 订阅

订阅专栏

最近项目不是很忙，因为项目用到了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<? extends Unbinder> 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<Class<?>, Constructor<? extends Unbinder>> BINDINGS = new LinkedHashMap<>();

我们如果在这里拿到了就返回如果没有就往下走 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<? extends Unbinder> 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<? extends Unbinder>) 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<T extends LoginActivity> 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 是如何产生的呢。那么就请大家关注我的下一篇文章吧。暂时还没有写出来。等写出来欢迎大家来阅读哈。