Android graphics-hardware acceleration (hardware acceleration) (2)

This article translated from: http://developer.android.com/guide/topics/graphics/hardware-accel.html

Determines whether a view object is accelerated by hardware.

Sometimes, especially for custom view objects, It is very helpful for applications to know whether the current view object is accelerated by hardware. This judgment is particularly useful if the application performs many custom drawing operations and not all operations are supported by the new rendering pipeline.

There are two different methods to check whether the application is accelerated by hardware:

1. If a view object is bound to a window accelerated by hardware, the view. ishardwareaccelerated () method returns true;

2. If a canvas object is accelerated by hardware, the canvas. ishardwareaccelerated () method returns true.

If this check must be performed in the drawing code, use the canvas. ishardwareaccelerated () method instead of the view. ishardwareaccelerated () method whenever possible. When a view object is bound to a window accelerated by hardware, it can still use a canvas object not accelerated by hardware. For example, this happens when a view object is drawn to a bitmap in the cache.

Drawing mode of Android

When hardware acceleration is enabled, the android framework uses a new drawing mode, which displays the application on the screen using the display list. To fully understand the display list and how they affect applications, it is helpful to understand how Android draws view objects without hardware acceleration. The following describes the software-based and hardware-accelerated drawing modes.

Software-based drawing mode

In the drawing mode of the software, the view object is drawn through the following two steps:

1. invalidate the view hierarchy;

2. Draw the view hierarchy.

Whenever an application needs to update its UI, it calls the invalidate () method of the view object with content changes back. Invalid Message requests are transmitted in the view object hierarchy to calculate the screen area (Dirty Area) to be repainted ). Then, the android system will draw all the dirty areas in the view hierarchy. Unfortunately, this method has two drawbacks:

1. This mode requires a lot of code execution in each drawing transfer. For example, if the application calls the invalidate () method of a button and the button is located above another view object, even if the view object does not change, then, the android system must redraw it.

2. The second problem is that this plotting mode can hide bugs in applications. Because the Android system re-draws the view object when it is in the same dirty zone, even if the invalidate () method on the view object is not called, the view object content may also be repainted. In this case, you must rely on another invalid view object to obtain the correct behavior. This behavior can change every time you modify the application. For this reason, when modifying the data and status of the drawing code that affects the view object, you should always call the invalidate () method of the custom view object.

Note: When the attribute of the view object changes, such as the background color or text in the textview object, the android system automatically calls the invalidate () method of the view object.

Hardware accelerated drawing mode

In this mode, the android system still uses the invalidate () method and the draw () method to request screen update and display view objects, but the actual drawing processing is different, it immediately executes the drawing commands. The Android system records these commands in the internal display list, which contains the output of the drawing code of the view object hierarchy. Another optimization is that the Android system only needs to record and update the display list for the dirty area of the view object marked by the invalidate () method call. A view object without invalidation can be repainted simply by re-publishing the previously recorded display list. This drawing mode contains three phases:

1. invalidate the view hierarchy;

2. record and update the display list;

3. Draw a display list.

In this mode, the drawing cannot be executed based on the draw () method of the intersection dirty view. To ensure that the Android system records the display list of a view object, you must call the invalidate () method. If you forget to call this method, the view object will appear the same after the change, this is a bug that is easy to find.

Using the display list also improves the animation performance, because when setting properties such as transparency and rotation, the target view object does not need to be invalidated (the system will automatically do this ). This optimization also applies to view objects with display lists (any view objects when an application is accelerated by hardware ). For example, if there is a linearlayout layout of the listview object that contains a button object, the display list of the linearlayout layout is as follows:

1. drawdisplaylist (listview );

2. drawdisplaylist (button ).

If you want to change the opacity of the listview object, the display list contains the following processing when you call the setalpha (0.5f) method of the listview object:

1. savelayeralpha (0.5 );

2. drawdisplaylist (listview );

3. Restore;

4. drawdisplaylist (button ).

The drawing code of the complex listview object is not executed here. On the contrary, the system simply updates the display list of the linearlayout object. In an application without hardware acceleration enabled, both the list (listview) and its parent object will execute drawing code again.