1.流程不可控

选择Annotation的很重要作用还是用来进行 inflate，然而 inflate 的流程在AndroidAnnotation中无法进行控制；其中与inflate相关的函数有：@AfterViews修饰的函数，在控件被inflate之后被调用，AndroidAnnotation能够保证在@AfterView修饰的函数执行时所有相关控件已经被inflate过，但很多时候inflate流程是必须可控的，比如在进行ListView的ViewHolder编写时就需要保证在bindView调用之前所有的控件已经被inflate过，而AndroidAnnotation没有提供一个可以控制inflate流程的方式，造成了在ViewHolder中必须抛弃Annotation的 inflate 方式，这就操成了开发体验的不统一；

2.命名规范性

布局文件类型是xml，而代码一般使用Java语言，两种语言在命名规范上有很大区别，比如同样的一个Button,在xml中习惯叫”ensure_button”而在java中对应的变量名称为”ensureButton”。使用了AndroidAnnotation之后，为了保持两者的一致性，必须破坏一方的命名规范，造成了要么在Java中出现类似”ensure_button”这样的命名或者在xml中出现”ensureButton”这样的命名，影响了两种语言的命名规范性，看起来也会显得非常怪异。

3.类型冗余且怪异

为了保证效率，AndroidAnnotation使用的是编译时注解而不是运行时注解。也就是说我们使用AndroidAnnotation的接口写好了一个类之后在编译时会按照注解规则生成另一个和标准接口相符的子类，运行程序时实际使用的是生成的这个子类。这就带来了一个问题，在使用时类名必须使用该子类的名称。按照AndroidAnnotation的规则，一般该子类的名字是在父类名称后面加上下划线，因此在使用的时候经常需要注意，同时在AndroidMainfest中注明Activity时因为使用的是编译后的子类，因此第一次填写时会提示该Activity不存在，必须进行一次强制编译之后才会回复正常。这些都给使用造成了很大的影响。