This is a subset of the complete list of Lint http://tools.android.com/tips/lint-checks. The checks listed below belong to the "Performance" category.
1. DrawAllocation
--------------
Summary: Memory allocations within drawing code
Priority: 9 / 10
Severity: Warning
Category: Performance
You should avoid allocating objects during a drawing or layout operation.
These are called frequently, so a smooth UI can be interrupted by garbage
collection pauses caused by the object allocations.
The way this is generally handled is to allocate the needed objects up front
and to reuse them for each drawing operation.
Some methods allocate memory on your behalf (such as Bitmap.create), and these
should be handled in the same way.
2. Wakelock
--------
Summary: Incorrect WakeLock usage
Priority: 9 / 10
Severity: Warning
Category: Performance
Failing to release a wakelock properly can keep the Android device in a high
power mode, which reduces battery life. There are several causes of this, such
as releasing the wake lock in onDestroy() instead of in onPause(), failing to
call release() in all possible code paths after an acquire(), and so on.
NOTE: If you are using the lock just to keep the screen on, you should
strongly consider using FLAG_KEEP_SCREEN_ON instead. This window flag will be
correctly managed by the platform as the user moves between applications and
doesn't require a special permission. See
http://developer.android.com/reference/android/view/WindowManager.LayoutParams
html#FLAG_KEEP_SCREEN_ON.
3. Recycle
-------
Summary: Missing recycle() calls
Priority: 7 / 10
Severity: Warning
Category: Performance
Many resources, such as TypedArrays, VelocityTrackers, etc., should be
recycled (with a recycle() call) after use. This lint check looks for missing
recycle() calls.
4. UseCompoundDrawables
--------------------
Summary: Node can be replaced by a TextView with compound drawables
Priority: 6 / 10
Severity: Warning
Category: Performance
A LinearLayout which contains an ImageView and a TextView can be more
efficiently handled as a compound drawable (a single TextView, using the
drawableTop, drawableLeft, drawableRight and/or drawableBottom attributes to
draw one or more images adjacent to the text).
If the two widgets are offset from each other with margins, this can be
replaced with a drawablePadding attribute.
There's a lint quickfix to perform this conversion in the Eclipse plugin.
5. ViewTag
-------
Summary: Tagged object leaks
Priority: 6 / 10
Severity: Warning
Category: Performance
Prior to Android 4.0, the implementation of View.setTag(int, Object) would
store the objects in a static map, where the values were strongly referenced.
This means that if the object contains any references pointing back to the
context, the context (which points to pretty much everything else) will leak.
If you pass a view, the view provides a reference to the context that created
it. Similarly, view holders typically contain a view, and cursors are
sometimes also associated with views.
6. ViewHolder
----------
Summary: View Holder Candidates
Priority: 5 / 10
Severity: Warning
Category: Performance
When implementing a view Adapter, you should avoid unconditionally inflating a
new layout; if an available item is passed in for reuse, you should try to use
that one instead. This helps make for example ListView scrolling much
smoother.
More information:
http://developer.android.com/training/improving-layouts/smooth-scrolling.html#ViewHolder
7. FieldGetter
-----------
Summary: Using getter instead of field
Priority: 4 / 10
Severity: Warning
Category: Performance
NOTE: This issue is disabled by default!
You can enable it by adding --enable FieldGetter
Accessing a field within the class that defines a getter for that field is at
least 3 times faster than calling the getter. For simple getters that do
nothing other than return the field, you might want to just reference the
local field directly instead.
NOTE: As of Android 2.3 (Gingerbread), this optimization is performed
automatically by Dalvik, so there is no need to change your code; this is only
relevant if you are targeting older versions of Android.
More information:
http://developer.android.com/guide/practices/design/performance.html#internal_get_set
8. UseSparseArrays
---------------
Summary: HashMap can be replaced with SparseArray
Priority: 4 / 10
Severity: Warning
Category: Performance
For maps where the keys are of type integer, it's typically more efficient to
use the Android SparseArray API. This check identifies scenarios where you
might want to consider using SparseArray instead of HashMap for better
performance.
This is particularly useful when the value types are primitives like ints,
where you can use SparseIntArray and avoid auto-boxing the values from int to
Integer.
If you need to construct a HashMap because you need to call an API outside of
your control which requires a Map, you can suppress this warning using for
example the @SuppressLint annotation.
9. UseValueOf
----------
Summary: Should use valueOf instead of new
Priority: 4 / 10
Severity: Warning
Category: Performance
You should not call the constructor for wrapper classes directly, such as`new
Integer(42)`. Instead, call the valueOf factory method, such as
Integer.valueOf(42). This will typically use less memory because common
integers such as 0 and 1 will share a single instance.
10. FloatMath
---------
Summary: Using FloatMath instead of Math
Priority: 3 / 10
Severity: Warning
Category: Performance
In older versions of Android, using android.util.FloatMath was recommended for
performance reasons when operating on floats. However, on modern hardware
doubles are just as fast as float (though they take more memory), and in
recent versions of Android, FloatMath is actually slower than using
java.lang.Math due to the way the JIT optimizes java.lang.Math. Therefore, you
should use Math instead of FloatMath if you are only targeting Froyo and
above.
More information:
http://developer.android.com/guide/practices/design/performance.html#avoidfloat
11. UnusedResources
---------------
Summary: Unused resources
Priority: 3 / 10
Severity: Warning
Category: Performance
Unused resources make applications larger and slow down builds.
12. UnusedIds
---------
Summary: Unused id
Priority: 1 / 10
Severity: Warning
Category: Performance
NOTE: This issue is disabled by default!
You can enable it by adding --enable UnusedIds
This resource id definition appears not to be needed since it is not
referenced from anywhere. Having id definitions, even if unused, is not
necessarily a bad idea since they make working on layouts and menus easier, so
there is not a strong reason to delete these.
13. UnusedNamespace
---------------
Summary: Unused namespace
Priority: 1 / 10
Severity: Warning
Category: Performance
Unused namespace declarations take up space and require processing that is not
necessary
14. HandlerLeak
-----------
Summary: Handler reference leaks
Priority: 4 / 10
Severity: Warning
Category: Performance
Since this Handler is declared as an inner class, it may prevent the outer
class from being garbage collected. If the Handler is using a Looper or
MessageQueue for a thread other than the main thread, then there is no issue.
If the Handler is using the Looper or MessageQueue of the main thread, you
need to fix your Handler declaration, as follows: Declare the Handler as a
static class; In the outer class, instantiate a WeakReference to the outer
class and pass this object to your Handler when you instantiate the Handler;
Make all references to members of the outer class using the WeakReference
object.
15. MergeRootFrame
--------------
Summary: FrameLayout can be replaced with <merge> tag
Priority: 4 / 10
Severity: Warning
Category: Performance
If a <FrameLayout> is the root of a layout and does not provide background or
padding etc, it can often be replaced with a <merge> tag which is slightly
more efficient. Note that this depends on context, so make sure you understand
how the <merge> tag works before proceeding.
More information:
http://android-developers.blogspot.com/2009/03/android-layout-tricks-3-optimize-by.html
16. DisableBaselineAlignment
------------------------
Summary: Missing baselineAligned attribute
Priority: 3 / 10
Severity: Warning
Category: Performance
When a LinearLayout is used to distribute the space proportionally between
nested layouts, the baseline alignment property should be turned off to make
the layout computation faster.
17. InefficientWeight
-----------------
Summary: Inefficient layout weight
Priority: 3 / 10
Severity: Warning
Category: Performance
When only a single widget in a LinearLayout defines a weight, it is more
efficient to assign a width/height of 0dp to it since it will absorb all the
remaining space anyway. With a declared width/height of 0dp it does not have
to measure its own size first.
18. NestedWeights
-------------
Summary: Nested layout weights
Priority: 3 / 10
Severity: Warning
Category: Performance
Layout weights require a widget to be measured twice. When a LinearLayout with
non-zero weights is nested inside another LinearLayout with non-zero weights,
then the number of measurements increase exponentially.
19. Overdraw
--------
Summary: Overdraw: Painting regions more than once
Priority: 3 / 10
Severity: Warning
Category: Performance
If you set a background drawable on a root view, then you should use a custom
theme where the theme background is null. Otherwise, the theme background will
be painted first, only to have your custom background completely cover it;
this is called "overdraw".
NOTE: This detector relies on figuring out which layouts are associated with
which activities based on scanning the Java code, and it's currently doing
that using an inexact pattern matching algorithm. Therefore, it can
incorrectly conclude which activity the layout is associated with and then
wrongly complain that a background-theme is hidden.
If you want your custom background on multiple pages, then you should consider
making a custom theme with your custom background and just using that theme
instead of a root element background.
Of course it's possible that your custom drawable is translucent and you want
it to be mixed with the background. However, you will get better performance
if you pre-mix the background with your drawable and use that resulting image
or color as a custom theme background instead.
20. UselessLeaf
-----------
Summary: Useless leaf layout
Priority: 2 / 10
Severity: Warning
Category: Performance
A layout that has no children or no background can often be removed (since it
is invisible) for a flatter and more efficient layout hierarchy.
21. UselessParent
-------------
Summary: Useless parent layout
Priority: 2 / 10
Severity: Warning
Category: Performance
A layout with children that has no siblings, is not a scrollview or a root
layout, and does not have a background, can be removed and have its children
moved directly into the parent for a flatter and more efficient layout
hierarchy.
22. TooDeepLayout
-------------
Summary: Layout hierarchy is too deep
Priority: 1 / 10
Severity: Warning
Category: Performance
Layouts with too much nesting is bad for performance. Consider using a flatter
layout (such as RelativeLayout or GridLayout).The default maximum depth is 10
but can be configured with the environment variable ANDROID_LINT_MAX_DEPTH.
23. TooManyViews
------------
Summary: Layout has too many views
Priority: 1 / 10
Severity: Warning
Category: Performance
Using too many views in a single layout is bad for performance. Consider using
compound drawables or other tricks for reducing the number of views in this
layout.
The maximum view count defaults to 80 but can be configured with the
environment variable ANDROID_LINT_MAX_VIEW_COUNT.
24. ObsoleteLayoutParam
-------------------
Summary: Obsolete layout params
Priority: 6 / 10
Severity: Warning
Category: Performance
The given layout_param is not defined for the given layout, meaning it has no
effect. This usually happens when you change the parent layout or move view
code around without updating the layout params. This will cause useless
attribute processing at runtime, and is misleading for others reading the
layout so the parameter should be removed.