一、注解是用来干嘛的？
- 便于生成文档。
- 用于编译时的检查。
- 用于简洁化代码。
首先，生成文档这个最常见，如果你看过一些android源码就会发现
/**
* Same as {@link #startActivity(Intent, Bundle)} with no options
* specified.
*
* @param intent The intent to start.
*
* @throws android.content.ActivityNotFoundException
*
* @see {@link #startActivity(Intent, Bundle)}
* @see #startActivityForResult
*/
@Override
public void startActivity(Intent intent) {
this.startActivity(intent, null);
}
像里面的@link，@param，@see等等这些，主要为了方便用户阅读。
其次，编译时检查，例如：
@Override
public String toString() {
return "This is String Representation of current object.";
}
我们知道@Override代表重写，那么如果加不加这个注解有什么关系呢，实际上就程序运行而言，你加不加一点关系都没有，都不影响运行，但是跟运行结果有关。试想一下，如果你重写父类的这个方法，但是你没有加上@Override，你手一滑又把toString写成tostring，或者toStirng之类的，也能正常运行，but，运行结果却跟预期大相径庭，怎么办，检查来检查去，检查到怀疑人生都可能难以发现这个bug，我重写了啊，怎么没作用呢？如果你加上@Override，编译器在编译的时候就会自动检查你重写的这个类在父类中到底存不存在，你说你重写了，但是父类中根本没有，骗机！
最后，简洁化代码，通常是自定义注解，第三方注解库存在的目的，也是本文的重点所在。关于第三点的作用，我这里讲的会跟其他的博客文章不太一样，主要原因是本文的标题已经说明了，”关于android”、”浅要分析”。关于java的注解，以及注解的起源，机制等资料，欢迎大家查看文下或其他的资料。自定义注解不难，有兴趣的可以自行了解，本文主要说下三方注解，现在带有注解或专门注解的三方库越来越多，像xutils，ButterKnife，AndroidAnnotations，Dagger2等等，这些框架或者说工具所要达到的效果主要就是简洁化代码，使一锅大杂烩变得有可读性，方便以后或者他人的维护，譬如说，不用注解，你的代码往往是这样式的：
public class MainActivity extends FragmentActivity implements OnClickListener {
/** 消息界面布局 */
private View home_main_layout;
/** 联系人界面布局 */
private View home_nearby_layout;
/** 设置界面布局 */
private View home_choice_layout;
/** 动态界面布局 */
private View home_msg_layout;
/** 设置界面布局 */
private View home_user_layout;
/** 在Tab布局上显示消息图标的控件 */
private ImageView home_main_image;
/** 在Tab布局上显示联系人图标的控件 */
private ImageView home_nearby_image;
/** 在Tab布局上显示动态图标的控件 */
private ImageView home_msg_image;
/** 在Tab布局上显示设置图标的控件 */
private ImageView home_user_image;
/** 在Tab布局上显示消息标题的控件 */
private TextView home_main_text;
/** 在Tab布局上显示联系人标题的控件 */
private TextView home_nearby_text;
/** 在Tab布局上显示动态标题的控件 */
private TextView home_msg_text;
/** 在Tab布局上显示设置标题的控件 */
private TextView home_user_text;
/** 在Tab布局上显示设置图标的控件 */
private ImageView home_choice_image;
/** 在Tab布局上显示消息标题的控件 */
private TextView home_choice_text;
/** 初始化控件 */
private void initViews() {
home_main_layout = findViewById(R.id.home_main_layout);
home_nearby_layout = findViewById(R.id.home_nearby_layout);
home_msg_layout = findViewById(R.id.home_msg_layout);
home_user_layout = findViewById(R.id.home_user_layout);
home_choice_layout = findViewById(R.id.home_choice_layout);
home_main_image = (ImageView) findViewById(R.id.home_main_image);
home_nearby_image = (ImageView) findViewById(R.id.home_nearby_image);
home_msg_image = (ImageView) findViewById(R.id.home_msg_image);
home_user_image = (ImageView) findViewById(R.id.home_user_image);
home_choice_image = (ImageView) findViewById(R.id.home_choice_image);
home_main_text = (TextView) findViewById(R.id.home_main_text);
home_nearby_text = (TextView) findViewById(R.id.home_nearby_text);
home_msg_text = (TextView) findViewById(R.id.home_msg_text);
home_user_text = (TextView) findViewById(R.id.home_user_text);
home_choice_text = (TextView) findViewById(R.id.home_choice_text);
}
看着还行哈，但如果加上注解之后呢，
@ContentView(R.layout.activity_main)
public class MainActivity extends FragmentActivity implements OnClickListener {
/** 消息界面布局 */
@ViewInject(R.id.home_main_layout)
private View home_main_layout;
/** 联系人界面布局 */
@ViewInject(R.id.home_nearby_layout)
private View home_nearby_layout;
/** 设置界面布局 */
@ViewInject(R.id.home_choice_layout)
private View home_choice_layout;
/** 动态界面布局 */
@ViewInject(R.id.home_msg_layout)
private View home_msg_layout;
/** 设置界面布局 */
@ViewInject(R.id.home_user_layout)
private View home_user_layout;
/** 在Tab布局上显示消息图标的控件 */
@ViewInject(R.id.home_main_image)
private ImageView home_main_image;
/** 在Tab布局上显示联系人图标的控件 */
@ViewInject(R.id.home_nearby_image)
private ImageView home_nearby_image;
/** 在Tab布局上显示动态图标的控件 */
@ViewInject(R.id.home_msg_image)
private ImageView home_msg_image;
/** 在Tab布局上显示设置图标的控件 */
@ViewInject(R.id.home_user_image)
private ImageView home_user_image;
/** 在Tab布局上显示消息标题的控件 */
@ViewInject(R.id.home_main_text)
private TextView home_main_text;
/** 在Tab布局上显示联系人标题的控件 */
@ViewInject(R.id.home_nearby_text)
private TextView home_nearby_text;
/** 在Tab布局上显示动态标题的控件 */
@ViewInject(R.id.home_msg_text)
private TextView home_msg_text;
/** 在Tab布局上显示设置标题的控件 */
@ViewInject(R.id.home_user_text)
private TextView home_user_text;
/** 在Tab布局上显示设置图标的控件 */
@ViewInject(R.id.home_choice_image)
private ImageView home_choice_image;
/** 在Tab布局上显示消息标题的控件 */
@ViewInject(R.id.home_choice_text)
private TextView home_choice_text;
可以看到，这样注解后，上面initViews() 方法可以去除了，整体的代码是不是更清爽了，而且需要绑定的控件越多，使用注解的优势越明显。
那么，使用注解这样简化代码，又加了一个三方库，会不会影响效率呢，答案是不一定，这个接着来看。
二、注解的生命
J2SE5.0版本在 java.lang.annotation提供了四种元注解，专门注解其他的注解：
@Documented –注解是否将包含在JavaDoc中
@Retention –什么时候使用该注解
@Target –注解用于什么地方
@Inherited – 是否允许子类继承该注解
其中第一、三、四条并不要求一定要实现，第二条属于注解的生命周期，则必须要指出，如果想搞懂注解的这几个要记住（敲黑板，这道题前两年都没考，今年肯定考，三十分，爱记不记哈），@Retention包含三个生命周期：
- RetentionPolicy.SOURCE – 在编译阶段丢弃。这些注解在编译结束之后就不再有任何意义，所以它们不会写入字节码。
@Override,@SuppressWarnings都属于这类注解。- RetentionPolicy.CLASS – 在类加载的时候丢弃。在字节码文件的处理中有用。注解默认使用这种方式。
- RetentionPolicy.RUNTIME – 始终不会丢弃，运行期也保留该注解，因此可以使用反射机制读取该注解的信息。我们自定义的注解通常使用这种方式。
说到这里需要回顾下注解的作用，上面说了主要有三个作用，生成文档、编译时检查、简化代码这三条大致对应于这三个生命周期，就是说一些主要用于生成文档的注解，生命周期注明RetentionPolicy.SOURCE就可以了，依次类推，但是，你们看到我”大致”两个字加黑没，早期的android注解框架基本都是在运行期通过反射机制来读取注解信息，并加以解释的，比如Xutils，它的contentview的注解是这样的：
package org.xutils.view.annotation;
import java.lang.annotation.ElementType;
import java.lang.annotation.Retention;
import java.lang.annotation.RetentionPolicy;
import java.lang.annotation.Target;
@Target(ElementType.TYPE)
@Retention(RetentionPolicy.RUNTIME)
public @interface ContentView {
int value();
}
当然了，不可能光是这样，你声明个注解，程序就能搞懂你这是绑定contentView，它还需要个解释器来解释，你这个注解到底干了啥，这一点跟接口是一样的，你不能就写个接口放那不去实现，也没有用。Xutils关于这部分的解释器是这么写的：
@Override
public void inject(Activity activity) {
//获取Activity的ContentView的注解
Class<?> handlerType = activity.getClass();
try {
ContentView contentView = findContentView(handlerType);
if (contentView != null) {
int viewId = contentView.value();
if (viewId > 0) {
Method setContentViewMethod = handlerType.getMethod("setContentView", int.class);
setContentViewMethod.invoke(activity, viewId);
}
}
} catch (Throwable ex) {
LogUtil.e(ex.getMessage(), ex);
}
injectObject(activity, handlerType, new ViewFinder(activity));
}
主要还是利用反射的方式，调用setContentView()这个方法。这么着是没有问题的，但是写代码就唯恐多，需要绑定的控件多了的话在这里就会影响一定的效率，本来使用android原生的findViewById方法，这些控件资源在编译期就能确定了，运行时可以直接使用，但是通过这种注解，控件要在运行时才会被绑定，而且每次运行这个页面都要走一遍反射。所以，有没有一种既可以简化代码，又不会影响效率的注解呢？人们做事总是又想快又想省，这在程序界尤其严重，对于这样的问题，我们这些小白可能就束手无策了，但是对大牛就是小菜一碟了。
所以上面加黑了“大致”两个字，大致就是一般对应，还有不对应的，比如说现在，像一般比较专门的注解框架，如ButterKnife，Dagger2等就采用了动态生成代码这样一种方式来解决这个问题，注解时把@Retention(RetentionPolicy.RUNTIME)改成@Retention(RetentionPolicy.CLASS)，把注解的生命周期改到编译期，在编译时动态生成一个类，我们简称“类A”，在“类A”里我们把所有注解过的控件一 一进行绑定，相当于什么呢，相当于我们封装了一个类，这个类专门用来处理view的声明和事件绑定，如果有人用过Afinal这个框架应该知道这个。下面简要看看ButterKnife关于注解的机制：
/**
* Bind a field to the view for the specified ID. The view will automatically be cast to the field
* type.
* <pre><code>
* {@literal @}BindView(R.id.title) TextView title;
* </code></pre>
*/
@Retention(CLASS) @Target(FIELD)
public @interface BindView {
/** View ID to which the field will be bound. */
@IdRes int value();
}
最重要看什么，看周期，看@Retention，接着有篇文章讲的已经很到位了，比如小明同学分析的
ButterKnife 中所有的注解都使用 Retention 为 CLASS 保留。所以在 ButterKnife 中，有个很重要的 ButterKnifeProcessor。当 java 文件进行编译时，ButterKnifeProcessor 的 process() 方法被调用，生成相关的 ViewBinder 类，用于将 View 或者 Listener 进行绑定。
@Override public boolean process(Set<? extends TypeElement> elements, RoundEnvironment env) {
Map<TypeElement, BindingSet> bindingMap = findAndParseTargets(env);
for (Map.Entry<TypeElement, BindingSet> entry : bindingMap.entrySet()) {
TypeElement typeElement = entry.getKey();
BindingSet binding = entry.getValue();
JavaFile javaFile = binding.brewJava(sdk);
try {
javaFile.writeTo(filer);
} catch (IOException e) {
error(typeElement, "Unable to write binding for type %s: %s", typeElement, e.getMessage());
}
}
return false;
}
具体可以查看他的文章参看更多。
总之，通过编译期生成代码而非运行期反射的方式，确保了运行时的效率，又能保持代码的简洁可读性，这是注解发展到现在被越来越多人喜爱的重要原因。
这篇文章的主旨在于浅要的解释注解在android中的作用，以及很多注解库之所以日益活跃的原因。写作过程中参阅了诸多大牛的文章，一 一列在文末，如果大家参阅本文后依然对注解不甚明了，欢迎继续参考以下引文。文笔简陋，知识浅薄，这篇文章仅作为学习注解的一篇笔记，如果文中有任何错误之处，请诸位不吝赐教。
