Invalid layout param in a LinearLayout: layout_centerVertical
Issue: Looks for layout params that are not valid for the given parent layout
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.
This Handler class should be static or leaks might occur (com.borqs.appinstaller.AppMoveFragment.LoadAppHandler)
Issue: Ensures that Handler classes do not hold on to a reference to an outer class
In Android, Handler classes should be static or leaks might occur. Messages enqueued on the application thread's MessageQueue also retain their target Handler. If the Handler is an inner class, its outer class will be retained as well. To avoid leaking the outer class, declare the Handler as a static nested class with a WeakReference to its outer class.
Use android.util.FloatMath#ceil() instead of java.lang.Math#ceil to avoid argument float to double conversion
Issue: Suggests replacing java.lang.Math calls with android.util.FloatMath to avoid conversions
On modern hardware, "double" is just as fast as "float" though of course it takes more memory. However, if you are using floats and you need to compute the sine, cosine or square root, then it is better to use the android.util.FloatMath class instead of java.lang.Math since you can call methods written to operate on floats, so you avoid conversions back and forth to double.
Use a layout_width of 0dip instead of wrap_content for better performance
Issue: Looks for inefficient weight declarations in LinearLayouts
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.
Nested weights are bad for performance
Issue: Looks for nested layout weights, which are costly
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.
The resource R.drawable.ic_action_search appears to be unused
Issue: Looks for unused resources
Unused resources make applications larger and slow down builds.
Avoid object allocations during draw/layout operations (preallocate and reuse instead)
Issue: Looks for memory allocations within drawing code
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.
This tag and its children can be replaced by one <TextView/> and a compound drawable
Issue: Checks whether the current node can be replaced by a TextView using compound drawables.
A LinearLayout which contains an ImageView and a TextView can be more efficiently handled as a compound drawable.
There's a lint quickfix to perform this conversion in the Eclipse plugin.
This <FrameLayout> can be replaced with a <merge> tag
Issue: Checks whether a root <FrameLayout> can be replaced with a <merge> tag
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.
This LinearLayout layout or its FrameLayout parent is useless
Issue: Checks whether a parent layout can be removed.
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.