【转载请注明出处】
作者:DrkCore
原文:http://blog.youkuaiyun.com/drkcore/article/details/74999926
对 Android 开发从业人员来说 setContentView()
和 findViewById()
这两个方法肯定不会陌生,从我们写下第一行 Android 代码开始到使用 Afinal、xUtils 等基于反射和动态注解的框架简化代码,再到最求性能使用基于编译时注解的 ButterKnife,可谓是一路伴随成长。
不过本文倒不是用来讲述视图注解框架的发展历史的,而是因为一个纠结的问题让笔者决定开发一个自己的框架出来。事情是这样的:
原先笔者一直使用 xUtils3 的视图注解来减少这些繁杂的代码,近日新开一个项目时便打定主意转用 ButterKnife,但在引入的过程中就碰到了问题——ButterKnife 并框架没有 ContentView 注解!
翻找文档笔者终于在 GitHub 的 ISSUE#8 中找到了原因:
大体的意思是添加 ContentView 注解功能只能节约一行,实际意义并不是很大,在 ISSUE 的最后原作者表示放弃实现这个需求:
对于作者的想法我们暂且不论,代码总归还是要写的,而当笔者在新项目中写下一个 Fragment 代码时……
public class BookFrag extends Fragment {
@Override
public View onCreateView(LayoutInflater inflater, ViewGroup container, Bundle savedInstanceState){
return inflater.inflate(R.layout.frag_book, container, false);
}
}
可以看到其中实际有作用的代码就一行,本来看多了也就习惯了,但是没有对比就没有伤害:
@ContentView(R.layout.frag_book)
public class BookFrag extends BaseFrag {
// 在BaseFrag中实例化了视图
}
可以看到代码中没有一个字符是多余的。用更少的代码干更多的事,省下来的时间用于享受生活,这才是一个程序员应该干的事情!
说干就干。如果使用运行时注解开发的话倒是很简单,笔者曾写过一篇 xUtils3 视图注解模块的浅析(传送门),照搬也能解决问题。但已经使用 ButterKnife 了,索性就自己开发了一个基于编译时注解的框架来解决问题。
框架开发
网络上有很多讲编译时注解的博客,还没掌握相关知识点的同学可以先行了解一下。
这个框架很精简,一共也只 2 个类 100+ 行的代码。
首先是注解类:
@Retention(RetentionPolicy.CLASS)
@Target(ElementType.TYPE)
public @interface ContentView {
int value();
}
注解只有一个方法,用于标记 layout id,接着是注解处理器:
@AutoService(Processor.class)
public class ContentViewProcessor extends AbstractProcessor {
//省略部分代码
//生成类的包路径
public static final String API_PKG = "core.annotation.view";
public static final String API_NAME