[insert lengthy and passionate +1/me too implementation]
Also:
there are much
more complicated optimizations to the byte code that Dalvik doesn't
handle well.
I'd like to know more about that as well!
On Dec 7, 6:34 pm, Matt Quigley matthew.quig...@gmail.com wrote:
In the latest Android SDK Tools (revision 8), ProGuard has been
integrated into the ant build. This is easier to set up than it was
before (http://www.androidengineer.com/2010/07/optimizing-obfuscating-
and-shrinking.html), but I'm curious about the optimizations that are
disabled by default.
From the proguard.cfg file created with android update project -p .:
-optimizations !code/simplification/arithmetic,!field/*,!class/merging/
*
#1: code/simplification/arithmetic: This removes things like turning
3 + 3 into 6. A shame, but understandable, because there are much
more complicated optimizations to the byte code that Dalvik doesn't
handle well. This one is completely understood.
#2: !field/*: This refers to the following:
field/removal/writeonly - Removes write-only fields.
field/marking/private - Marks fields as private, whenever possible.
field/propagation/value - Propagates the values of fields across
methods.
#3: !class/merging/*: This disables merging two or more classes
horizontally or vertically (in the same class hierarchy).
The question here is, why would #2 and #3 give Android or Dalvik any
problems? The classes are valid Java classes in the end. I suspect
the answer for #2 is that projects built into Android require that the
R.* classes to remain intact. However, this is NOT the case for
private apps created by developers, unless they use introspection to
access those fields. There is no need for the R class at all; all of
the constants of that class can be propagated into whomever uses them,
and the the R class can be removed. For #3, this might have something
to do with the fact that Views referenced in layout .xml files are
dynamically created at runtime by reflection, and maybe merging these
classes together messes them up. But isn't that prevented by -keep
public class * extends **View?
For over a year I've been obfuscating my app and #2 and #3 have never
been used. I don't plan on using them from now on, either. Unless,
someone can clarify why I shouldn't be enabling #2 and #3?
Thanks!
-Matt
P.S. I would recommend adding the following to the next version of the
Android SDK Tool's automatically generated proguard.cfg file:
# Keep classes which are not directly referenced by code, but
referenced by layout files.
-keep public class * extends **View {
public init(android.content.Context);
public init(android.content.Context, android.util.AttributeSet);
public init(android.content.Context, android.util.AttributeSet,
int);
public void set*(...);}
This prevents classes which extend View, TextView, etc. classes from
being renamed. This will avoid ClassNotFoundExceptions when
developers use custom View classes referenced in their layout files.
It will hit some false positives (i.e. a class which ends with View
may not actually be used as such), but that is acceptable IMHO, and
can be easily changed by a developer as needed.
An alternative is to use -keep public class * extends
android.view.View, which removes all false positives, but will add
some missed cases, such as a class which extends TextView.
--
You received this message because you are subscribed to the Google
Groups Android Developers group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
