Comparative analysis of Android annotation framework

Java annotation is equivalent to a mark. Adding an annotation to a program is equivalent to marking the program. The mark can be added to packages, classes, properties, methods and local variables. Then you can write an annotation processor to parse and process these annotations (called compile time annotations), or you can use the reflected annotations to make corresponding processing (called run time annotations) when the program is running.

When developing Android programs, the endless methods of findviewbyid, setonclicklistener and so on have given most developers a headache. Fortunately, there are so-called annotation frameworks on the market that can help developers simplify some processes. The popular ones are butterknife, annotations, xutils, afinal, roboguice and so on. Today, let's compare these annotation frameworks.

Butterknife framework analysis

First, take a look at butterknife, a masterpiece from jakewharton. It is characterized by simple access and relying on one library. In addition, a plug-in is provided on Android studio to automatically generate annotations and class properties.

Butterknife currently supports annotation: View binding (bind), resource binding (bindbool, bindcolor, binddimension, binddrawable, bindint, bindstring), event binding (oncheckedchanged, onclick, oneditoraction, onfocuschange, onItemClick, onitemlongclick, onitemselected, onlongclick, onpagechange, ontextchanged, ontouch).

Butterknife's principle is runtime annotation. Let's take a look at the next demo.

This is an example of view binding. You need to annotate the control ID to be bound on the member variable, and then call the butterknife. Bind (activity target) method to assign values to the annotated member variable. OK, take a look at how butterknife. Bind () works.

As can be seen from the above code, the bind (object target, object source, finder) method needs to be called finally.

This method is to find or generate corresponding ViewBinder objects, and then call the object's bind (Finder finder, T target, Object source) method to assign values to the annotated variables. First look at the findviewbinderforclass (class <? > CLS) method.

It can be seen that a viewbinder object is generated by reflection, and it also has a cache, that is, multiple calls of the same class will only be reflected once. Although reflection is slower than native code, if there is only one reflection, the impact on performance is completely negligible. The question now is what is the viewbinder generated by this reflection, and how does its bind (finder, object source) method assign values to the annotated variables? As mentioned above, the butterknife framework is a compile time annotation. Generally, this kind of annotation will dynamically generate some classes or generate some XML according to the annotation ID during compilation. During runtime, this kind of annotation is not available ~ ~ it will rely on the dynamically generated classes to do some operations, because there is no reflection, and the efficiency is no different from calling methods directly ~ ~ ~. During program compilation, butterknife will generate corresponding code according to all annotations. For example, butterknife will generate the above mainactivity class

It can be seen that the bind annotation finally calls the generated code to find viewbyid and assign a value to it. The event is to set a default event for view, and then call the method you annotate. Therefore, butterknife will not affect the app in terms of performance. Butterknife does not produce much code automatically, and it will not have any impact on the package size of the program.

Android annotations framework analysis

Let's analyze the famous annotations framework. The principle of the framework is the same as butterknife. It generates code at compile time. However, annotations does not generate code for corresponding class calls to assign values to annotated variables and methods, but directly generates an inherited annotated class. This class contains code for assigning values to variables and calling annotated methods. At runtime, the class generated by annotations is run directly, not the class we write. Don't you understand after saying so much? It doesn't matter. Here comes the demo! First look at the class we wrote.

Take another look at the class generated by annotations.

Method call chain: oncreate (bundle saveinstancestate) - -- > setcontentview() --- > onviewchangednotifier_ Notifyviewchanged(), and onviewchanagednotifier_ Notifyviewchanged () method will eventually call onviewchanged (hasviews hasviews) method. In this method, there are codes for assigning values to variables and setting event methods. Pay attention to the name of the automatically generated class and find the rule, that is, add a '' after the name of the class we write Symbols. Now we know why we use the annotations framework. For the configuration of activities in our androidmanifest.xml, the name of the activity should be added with an '' Sign it. Because the code generated by Android annotations is actually loaded. Did you find that there is no reflection in the annotations framework? Yes, the framework does not use reflection and does not initialize. All work is done during compilation, which will not have any speed impact on our program.

What annotations do annotations support? Since annotations has the same performance as butterknife, what about the function? Translate the features of the official website here

1) Dependency injection: inject views, extras, system services, resources,... 2). Simplify thread mode: add comments on the method to determine whether the method runs on the UI thread or sub thread. 3) Event binding: add comments on the method to specify the event that the method handles those views. 4) . rest client: create a client interface, and androidannotations will generate implementation code, which is about the network. 5) . clarity: Android annotations will automatically generate corresponding subclasses during compilation. We can check the corresponding subclasses to understand how the program runs. Xutils framework analysis

Xutils framework is the framework we are using now. Let's analyze its annotation function. Xutils, like Butterknife, adds annotations on member variables and methods, and then calls a method (xutils is ViewUtils.inject ()) assigns member variables and event methods to view. The difference is that butterknife calls automatically generated code to assign values, while xutils is implemented through reflection. OK, talk to the source code.

You can see reflection and reflection to reflection. Although the current reflection speed is also very fast, it still can't be compared with the native code. Once more annotations are used, the initialization speed will be slower and slower. As can be seen from the above annotation processing code, the annotations supported by xutils mainly include UI, resource, event and sharedpreference binding. Like xutils, it is a framework for parsing annotations by reflection at runtime, as well as afinal, roboguice, etc.

There are many other annotation frameworks on the market, but everything changes, either reflection or automatic code generation. Although the reflection function is powerful, it is not desirable. It will not only slow down the speed, but also break the encapsulation of the program. Personally, I think the scheme of generating code is better. All functions are done during compilation and will not affect the user experience. The only disadvantage is that it is more difficult to implement than reflection. However, our program just leaves the difficulties to ourselves and the happiness to users!

Finally, summarize the above three frameworks.

The difficulty, strength and speed of the above are relative to the three themselves. For example, the access rating of Android annotations is difficult, which does not mean that its access method is difficult, but it is more difficult than butterknife and xutils. If you only want to use the functions of UI binding, resource binding and event binding, butterknife is recommended. The above analysis is purely a personal point of view, for reference only!

The above is the whole content of this article. I hope it will be helpful to your study, and I hope you can support programming tips.