Android hardware acceleration

Hardware acceleration in Android

The main content of this article is from the "Hardware acceleration" in the SDK article ".

Since Android 3.0, Android's 2d rendering pipeline can better support hardware acceleration. Hardware acceleration uses GPU to draw views.

Hardware acceleration can be enabled or disabled at the following four levels:

• Application
• Activity
• Window
• View

Application Level

Add the following attributes to the application tag in your application androidmanifest. xml file to enable hardware acceleration for the entire application:

<application android:hardwareAccelerated="true" ...>

Activity level

You can also control whether hardware acceleration is enabled for each activity by adding the Android: hardwareaccelerated attribute to the activity element. For example, in the following example, hardware acceleration is enabled at the application level, but hardware acceleration is disabled on an activity.

<application android:hardwareAccelerated="true">    <activity ... />    <activity android:hardwareAccelerated="false" /></application>

Window Level

If you need more granular control, you can use the following code to enable hardware acceleration for a window:

getWindow().setFlags(    WindowManager.LayoutParams.FLAG_HARDWARE_ACCELERATED,    WindowManager.LayoutParams.FLAG_HARDWARE_ACCELERATED);

Note: currently, hardware acceleration cannot be disabled at the window level.

View level

You can run the following code to disable hardware acceleration for a single view:

myView.setLayerType(View.LAYER_TYPE_SOFTWARE, null);

Note: you cannot enable hardware acceleration at the view level.

Why do we need such multi-level control?

Obviously, hardware acceleration can improve performance. Why does Android achieve so many levels of control, instead of all hardware acceleration by default? The reason is that not all 2D drawing Operations Support Hardware acceleration. If your program uses custom views or drawing calls, the program may not work properly. If your program only uses standard views and drawable, enable hardware acceleration with confidence! Which plotting operations do not support hardware acceleration? Drawing operations that do not support hardware acceleration are as follows:

• Canvas
  • Clippath ()
  • Clipregion ()
  • Drawpicture ()
  • Drawpostext ()
  • Drawtextonpath ()
  • Drawvertices ()
• Paint
  • Setlineartext ()
  • Setmaskfilter ()
  • Setrasterizer ()

  There are also some drawing operations to enable or disable hardware acceleration, with different effects:

• Canvas
  • Cliprect ():XOR,The Difference and reversedifference cropping modes are ignored. 3D transformations are not applied to the cropped rectangle.
  • Drawbitmapmesh (): The colors array is ignored.
  • Drawlines (): anti-sawtooth is not supported
  • Setdrawfilter (): can be set, but no effect
• Paint
  • Setdither (): Ignore
  • Setfilterbitmap (): always enable filter
  • Setshadowlayer (): can only be used on Text
• Composeshader
  • Composeshader can only contain different types of shader (for example, one bitmapshader and one lineargradient, but not two bitmapshader instances)
  • Composeshader cannot contain composeshader

  If the application is affected, you can callSetlayertype (view. layer_type_software,
Null), so that you can still enjoy the benefits of hardware acceleration elsewhere.

Android rendering Model

After hardware acceleration is enabled, the android framework uses a new drawing model. What are the differences between software-based and hardware-based drawing models?

Software-based drawing Model

Under the software drawing model, the view is drawn according to the following two steps:

1. invalidate the hierarchy (Note: how to translate hierarchy ?)

2. Draw the hierarchy

When an application calls invalidate () to update a part of the UI, the invalidation message is transmitted throughout the view layer, and each area (Dirty Area) to be repainted is calculated ). Then, the android system re-draws all views that have an intersection with the dirty areas. Obviously, this drawing mode has disadvantages:

1. Unnecessary code is executed in each painting operation. For example, if the application calls invalidate () to repaint the button, and the button is located on another view, the view will be repainted even if it does not change.

2. Some Application bugs may be concealed. Because the Android system redraws a view that has an intersection with the dirty area, the view content may be repainted without calling invalidate. This may result in a view dependent on the failure of other views to get the correct behavior.

Hardware-based drawing Model

The Android system still uses invalidate () and draw () to draw a view, but the process is different. The Android system records the draw command to the display list instead of executing the draw command immediately. Another optimization is that the Android system only needs to record and update the view marked as dirty (via invalidate. The new model can be drawn in three steps:

1. invalidate the hierarchy

2. record and update the display list

3. Draw a display list