俗话说的好“不想偷懒的程序员,不是好程序员”,我们在日常开发android的过程中,在前端activity或者fragment时,无法避免的会用到
findViewById
这类的代码,然后强制类型转换出我们所需要的控件类型,说实话,对于追求代码简洁,高可读,并且想偷懒的程序员来说,写这样的重复代码,简直就是灾难。当然,我们可以通过一些技术手段来规避这些重复劳动并且“难看”的代码出现
反射方式
我们先介绍一下传统的使用反射方式进行优化findViewById
类型的代码,下面我们来看下是怎么实现的:
注解类FindView
@Target(ElementType.FIELD)
@Retention(RetentionPolicy.RUNTIME)
public @interface FindView {
public int value();
/* parent view id */
public int parent() default 0;
}
在看下我们的使用方式
在activity或者fragment中,使用以下方式注入ID并且初始化对象
@SetOnClickListener({R.id.ll_community_switch,R.id.panel_abot,R.id.ll_me_info})
public class MeFragment implements OnClickListener{
@FindView(R.id.panel_shell)
private FrameLayout mShellPanel;
@FindView(R.id.panel_coverture)
private LinearLayout mPanelCoverture;
public void onClick(View v) {
switch (v.getId()) {
case R.id.ll_community_switch: {
// TODO
break;
}
case R.id.ll_panel_abot: {
// TODO
break;
}
......
}
我们都知道,注解使用的其中一种方式是给类/方法/成员变量设置注解,然后在某个地方,对设置的注解进行解析,以期获取到注解对应的类/方法/成员变量的一些属性或者能力,我们这里正是利用的这个特性,在activity(onCreate)或者fragment(onActivityCreated)的生命周期中,加入我们解析注解的代码,对注解属性进行初始化操作
// 查找注解到视图
InjectFinder.injectView(this); // this代表Fragment或者Activity对象
在injectView方法中,我们通过反射方式获取到activity或者fragment的FindView注解,然后根据注解中的ID,最终还是通过findViewById的方法获取到对应的控件(注:SetOnClickListener注解原理类似)
public static <O> void injectView(Class<?> clazz, O o) {
Class<?> tempClazz = clazz != null ? clazz : (o != null ? o.getClass() : null);
if (tempClazz != null) {
// find view
final SparseArray<View> tempViewArray = new SparseArray<View>();
Field[] fields = tempClazz.getDeclaredFields();
if (Assert.notEmpty(fields)) {
for (Field field : fields) {
FindView viewInject = field.getAnnotation(FindView.class);
if (viewInject != null) {
try {
int viewId = viewInject.value();
View view = findViewById(o, viewId, viewInject.parent());
// Check if the object type is match
Class<?> targetType = field.getType();
Class<?> viewType = view.getClass();
if (!targetType.isAssignableFrom(viewType)) {
String err = "Type mismatch! \n"
+ " The view is (" + viewType.getName() + ") R.id."
+ view.getContext().getResources().getResourceEntryName(viewId)
+ "#" + String.format("0x%08x", viewId) + "\n"
+" Cannot set to (" + targetType.getName() + ") "
+ o.getClass().getName() + "." + field.getName();
Log.e(TAG, err);
continue;
}
// 设置变量值
if (setField(o, field, view)) {
tempViewArray.append(viewId, view);
}
} catch (Throwable e) {
Log.e(TAG, e);
}
}
}
}
// 获取onClicklistener类
boolean isClickClazz = Assert.isInstanceOf(OnClickListener.class, o);
// 获取注解的View id
int[] clickIds = findClickIds(tempClazz);
if (Assert.notEmpty(clickIds)) {
for (int id : clickIds) {
if (id != 0) {
View tempView = tempViewArray.get(id);
if (tempView == null) {
try {
tempView = findViewById(o, id, 0);
} catch (Throwable t) {
Log.e(TAG, t);
}
}
if (tempView != null) {
// 设置点击事件
if (isClickClazz) {
tempView.setOnClickListener(ViewUtils.proxy((OnClickListener) o));
}
}
}
}
}
}
}
通过以上代码,我们知道,通过反射方式,虽然可以达到我们的目的,但是反射我们都知道,效率是比较低下的,那么我们是否有更好的方式呢,条条大路通罗马,我就不信只有这一条,下面我们隆重介绍一下我们的ButterKnife依赖注入框架,你会发现一切都是那么的自然,那么顺溜~~~
ButterKnife
由于使用放射等方式处理注入,会存在效率方面的问题,所以我们的JakeWharton大神写了ButterKnife框架,来帮助我们实现依赖注入。
ButterKnife的github地址,现在最新版本8.2.1,我们先来谈谈ButterKnife对比反射方式的优势在哪里?
ButterKnife优势
- 强大的View绑定和Click事件处理功能,简化繁琐的代码编写
- 可以支持Adapter中的VIewHolder绑定问题
- 采用编译时通过注解生成代码,对运行时没有侵入,对比反射方式,效率倍高
- 代码清晰,可读性强
好了,废话不多说,程序员学习一个新技术时,总是先尝试这先使用它,再刨析他的原理
ButterKnife安装
这里我们基于android studio(Android Studio 2.2 Preview 6)开发,所以安装的时候也是预计studio的,我们看下具体配置
在你android project级别的build.gradle
配置文件中,引入android-apt
插件
buildscript {
repositories {
jcenter()
}
dependencies {
// butter knife plugins
classpath 'com.neenbedankt.gradle.plugins:android-apt:1.8'
}
}
在module中使用ButterKnife
在你使用ButterKnife框架的android module的build.gradle
配置文件中,引入如下依赖
android studio版本是2.2.0及以上版本
dependencies {
/* butterknife */
compile 'com.jakewharton:butterknife:8.2.1'
annotationProcessor 'com.jakewharton:butterknife-compiler:8.2.1'
}
android studio版本是2.2.0以下版本
apply plugin: 'android-apt'
android {
...
}
dependencies {
compile 'com.jakewharton:butterknife:8.2.1'
apt 'com.jakewharton:butterknife-compiler:8.2.1'
}
在library中使用ButterKnife
添加插件到library的buildscript
中
buildscript {
repositories {
mavenCentral()
}
dependencies {
classpath 'com.jakewharton:butterknife-gradle-plugin:8.2.1'
}
}
然后在使用该library的module中,配置以下插件
apply plugin: 'com.android.library'
apply plugin: 'com.jakewharton.butterknife'
ButterKnife使用实例
注入视图
@BindView(R.id.toolbar)
Toolbar toolbar;
@BindView(R.id.fab)
FloatingActionButton fab;
注入事件
@OnClick(R.id.fab)
public void show(View view){
Snackbar.make(view, "Replace with your own action",Snackbar.LENGTH_LONG)
.setAction("Action", null).show();
}
当然,需要我们在activity或者fragment初始化的时候进行绑定操作
@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_main);
ButterKnife.bind(this);
setSupportActionBar(toolbar);
}
看到这里,是不是还是不清晰,只是知道了怎么使用,那我们现在来刨析一下ButterKnife是怎么工作的?
ButterKnife原理刨析
可能很多人都觉得ButterKnife在bind(this)方法执行的时候通过反射获取MainActivity中所有的带有@BindView注解的属性并且获得注解中的R.id.xxx值,最后还是通过反射拿到Activity.findViewById()方法获取View,并赋值给MainActivity中的某个属性。这是一种原始的使用反射的方式,缺点是反射影响App性能,造成卡顿,并且会产生大量的临时对象,频繁的引发GC。
ButterKnife显然没有使用这种方式,它用了Java Annotation Processing技术,就是在Java代码编译成Java字节码的时候就已经处理了@Bind、@OnClick(ButterKnife还支持很多其他的注解)这些注解了。
Java Annotation Processing
Java Annotation Processing是javac中用于编译时扫描和解析Java注解的工具
你可以你定义注解,并且自己定义解析器来处理它们。Annotation processing是在编译阶段执行的,它的原理就是读入Java源代码,解析注解,然后生成新的Java代码。新生成的Java代码最后被编译成Java字节码,注解解析器(Annotation Processor)不能改变读入的Java 类,比如不能加入或删除Java方法
下图是Java 编译代码的整个过程,可以帮助我们很好理解注解解析的过程:
框架工作流程
当你编译使用了ButterKnife框架的应用程序时,ButterKnifeProcessor类的process()方法开始工作,会执行以下操作:
- 扫描Java代码中所有的ButterKnife注解@Bind、@OnClick、@OnItemClicked等
- 当它发现一个类中含有任何一个注解时,ButterKnifeProcessor会帮你生成一个Java类,名字类似
$$ViewBinder,这个新生成的类实现了ViewBinder 接口 - 这个ViewBinder类中包含了所有对应的代码,比如@Bind注解对应findViewById(), @OnClick对应了view.setOnClickListener()等等
最后当Activity启动ButterKnife.bind(this)执行时,ButterKnife会去加载对应的ViewBinder类调用它们的bind()方法
一个例子如下:
android源码
public class MainActivity extends AppCompatActivity {
@BindView(R.id.toolbar)
Toolbar toolbar;
@BindView(R.id.fab)
FloatingActionButton fab;
@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_main);
ButterKnife.bind(this);
setSupportActionBar(toolbar);
}
@OnClick(R.id.fab)
public void show(View view){
Snackbar.make(view, "Replace with your own action", Snackbar.LENGTH_LONG)
.setAction("Action", null).show();
}
}
编译之后,会在目录下生成两个文件
让我们来看下这两个文件内容:
MainActivity_ViewBinder.class
public final class MainActivity_ViewBinder implements ViewBinder<MainActivity> {
@Override
public Unbinder bind(Finder finder, MainActivity target, Object source) {
return new MainActivity_ViewBinding<>(target, finder, source);
}
}
MainActivity_ViewBinding.class
public class MainActivity_ViewBinding<T extends MainActivity> implements Unbinder {
protected T target;
private View view2131492973;
public MainActivity_ViewBinding(final T target, Finder finder, Object source) {
this.target = target;
View view;
target.toolbar = finder.findRequiredViewAsType(source, R.id.toolbar, "field 'toolbar'", Toolbar.class);
view = finder.findRequiredView(source, R.id.fab, "field 'fab' and method 'show'");
target.fab = finder.castView(view, R.id.fab, "field 'fab'", FloatingActionButton.class);
view2131492973 = view;
view.setOnClickListener(new DebouncingOnClickListener() {
@Override
public void doClick(View p0) {
target.show(p0);
}
});
}
@Override
public void unbind() {
T target = this.target;
if (target == null) throw new IllegalStateException("Bindings already cleared.");
target.toolbar = null;
target.fab = null;
view2131492973.setOnClickListener(null);
view2131492973 = null;
this.target = null;
}
}
我们可以看到MainActivity_ViewBinder
类在执行bind
方法的时候会new一个MainActivity_ViewBinding
对象,并且传入了MainActivity
实例,在MainActivity_ViewBinding
对象执行构造方法的时候,需要对target.XXX,所以我们这里在MainActivity
中的BindView
注解的属性,不能使用private修饰符,那么使用protected修饰是否可以呢?答案是可以的,因为ButterKnifeProcessor类的process()方法会在MainActivity的同一个包下生成Binder和Binding类,所以同包下是可以调用到的。同样的道理,onClickListener也是通过找到view,然后设置view的onclicklistener为target.XXX()方法,同样的调用target.XXX()方法需要public或者protected修饰。
通过以上的流程我们知道,ButterKnife是在编译时通过注解方式解析生成了Binder类和Binding,在Activity中调用了ButterKnife.bind(this)方法后,通过Bunder和Binding的配合,找到Activity中的类,并且类似与代理一样的,为Activity的注解绑定了对应的实例或者调用方法。
ButterKnife.bind 执行阶段
最后,执行bind方法时,我们会调用ButterKnife.bind(this):
ButterKnife会调用findViewBinderForClass(targetClass)加载MainActivity$$ViewBinder.java类
然后调用ViewBinder的bind方法,动态注入MainActivity类中所有的View属性和
如果Activity中有@OnClick注解的方法,ButterKnife会在ViewBinder类中给View设置onClickListener,并且将@OnClick注解的方法传入其中
在上面的过程中可以看到,为什么你用@Bind、@OnClick等注解标注的属性或方法必须是public或protected的,因为ButterKnife是通过ExampleActivity.this.editText来注入View的
为什么要这样呢?有些注入框架比如roboguice你是可以把View设置成private的,答案就是性能。如果你把View设置成private,那么框架必须通过反射来注入View,不管现在手机的CPU处理器变得多快,如果有些操作会影响性能,那么是肯定要避免的,这就是ButterKnife与其他注入框架的不同
有一点需要注意
通过ButterKnife来注入View时,ButterKnife有bind(Object, View) 和 bind(View)两个方法,有什么区别呢?
如果你自定义了一个View,比如public class BadgeLayout extends Fragment,那么你可以可以通过ButterKnife.bind(BadgeLayout)来注入View的
如果你在一个ViewHolder中inflate了一个xml布局文件,得到一个View对象,并且这个View是LinearLayout或FrameLayout等系统自带View,那么不是不能用ButterKnife.bind(View)来注入View的,因为ButterKnife认为这些类的包名以com.android开头的类是没有注解功能的(-。- 这不是废话吗?),所以这种情况你需要使用ButterKnife.bind(ViewHolder,View)来注入View。
这表示你是把@Bind、@OnClick等注解写到了这个ViewHolder类中,ViewHolder中的View呢需要从后面那个View中去找