Repository navigation
Package annotations with RetentionPolicy.SOURCE in separate JAR to lighten the final APK #129
Description
Activity
A quick test on my pet project shows that just changing the dependency scope of com.googlecode.androidannotations:androidannotations:api:2.4 from "compile" to "provided" reduces the size of the final APK (signed + aligned) from 153681 to 92876 bytes.
It still works because I'm not using the other runtime goodies of AndroidAnnotations, just Dependency Injection and Lifecycle Events.Very interesting !!
In fact, we could completely switch to "provided" scope for the API Jar if we generated the "runtime goodies" as part of the Annotation Processing. The good thing would be that we would only generated them if needed. The bad thing is that it might be more error prone on our side, and harder to maintain.
Regarding the annotation diverse retention policies : basically, we only needed
RetentionPolicy.SOURCEwhen we began with AndroidAnnotations. But due to Eclipse "incremental compilation", we sometime need to look at previously compiled classes, and check for annotations. So that's why we changed some retention policies.If we defined the scope of the library to "provided", that wouldn't be a problem anyway.
As you can see on the G+ post made by @eneveu : https://plus.google.com/109455886848457681950/posts/DQBejxAbZ8C
It seems that we could import that functionnality from Google Guava.
Sorry but I don't see the link between this issue and a runtime classloader, could you give us more details ?
Quick summary :
- The annotation retention is now
RetentionPolicy.CLASSfor all annotations, which is needed for incremental compilation and superclass processing - We should let AA generate the helper classes instead of providing them through the JAR
- Then we should let the JAR be in
providedscope - The current API jar has a dependency on the full annotation processing jar, which is wrong. This is only a problem when using Maven and friends. Not much of a problem if using ProGuard, since the code is unused and therefore removed anyway
- The annotation retention is now
Hi folks :)
We should let AA generate the helper classes instead of providing them through the JAR
I worked on that this day.
The principle is to package those classes sources into the processor jar and copy these sources as needed.
The main advantage to have those sources into the processor jar is that we can read and modify those sources easily. Furthermore, those sources do not need to be modified at compile time so there is no need to generate them using CodeModel.
It is my understanding that annotations declared with @retention(RetentionPolicy.SOURCE) are discarded at compilation time and as such are not needed at runtime.
Most annotations are in this case, with the exceptions being:
com.googlecode.androidannotations.annotations.EBean / @retention(RetentionPolicy.CLASS)
com.googlecode.androidannotations.annotations.rest.Rest / @retention(RetentionPolicy.CLASS)
com.googlecode.androidannotations.annotations.EApplication / @retention(RetentionPolicy.CLASS)
Including them in the androidannotation-api JAR ends up in making the final APK unnecessarily big.
Indeed, a quick analysis of the com/googlecode/androidannotations/androidannotations/2.4/androidannotations-2.4-api.jar file seems to indicate that these annotations are taking up to 60% of its size.
Placing those annotations in a separate JAR that could be depended on with a "provided" scope would lighten the final APK, wouldn't it.
I'm not that familiar with the annotation processor so I wouldn't be surprised if I'm completely wrong...
Best regards,
Patrick.
PS: thanks to pyricau and a-thomas for the great presentation at last evening PAUG!