android--hardwareaccelerated Hardware acceleration Detailed android:largeheap= "true"

When doing the project, the Guide page of the Viewpager reported Oom exception, the picture is not big, in the manifest file application node added two lines of code to solve the problem

Android : hardwareaccelerated= "false"
Android : largeheap= "true"

Starting with Android3.0 (API level 11), the Android 2D rendering pipeline provides better support for hardware acceleration. All of the drawing operations performed by hardware acceleration are done using the GPU on the View object's canvas. Because enabling hardware acceleration increases the need for resources, such an application consumes more memory.

The easiest way to enable hardware acceleration is to turn on global hardware acceleration for the entire application.

If you should use a program that uses only standard view and drawable, turning on global hardware acceleration does not result in any undesirable drawing effects . However, because hardware acceleration does not support all 2D graphics drawing operations, turning on Global hardware acceleration for applications that use custom view and draw calls can affect drawing effects . Problems typically occur when pixel rendering is abnormal or incorrect for those elements that are not visible. To avoid this problem, Android provides the following levels so that hardware acceleration can be selectively enabled or disabled :

1. Application

2. Activity

3. Window

4. View

If your application performs a custom drawing, it should be tested on the actual hardware device with hardware acceleration to identify the problem.
Control hardware Acceleration
Ability to control hardware-accelerated application levels with the following levels
In the app's Android manifest file, add the following attributes to the <application> element to turn on hardware acceleration for the entire application.

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

Activity level

If the application does not correctly use the global hardware acceleration that is turned on, the activity can also be controlled separately. Use the android:hardwareaccelerated attribute in the <activity> element to enable or disable hardware acceleration at the activity level. The following example enables global hardware acceleration, but disables hardware acceleration for an activity: <application android:hardwareaccelerated= "true" > <activity .../ >

<activity android:hardwareaccelerated= "false"/> </application>

Window level

If finer-grained control is required, you can use the following code to enable hardware acceleration for a given window:

GetWindow (). SetFlags (WindowManager.LayoutParams.FLAG_HARDWARE_ACCELERATED, WindowManager.LayoutParams.FLAG_ hardware_accelerated);

Note: Hardware acceleration cannot be disabled at the window level at this moment.

View level

You can use the following code to suppress hardware acceleration at run time against a separate view object:

Myview.setlayertype (view.layer_type_software, NULL);

Note: Hardware acceleration cannot be turned on at the view level at this moment. View Layer In addition to prohibit hardware acceleration, there are other features, more information please see the "View layer" of this article. Determine if a View object is hardware accelerated
Sometimes, especially for custom view objects, it is beneficial for the application to know whether the current view object is being accelerated by hardware. If the application does a lot of custom drawing operations, and not all operations will be new

Rendering pipeline is supported, this judgment is particularly useful.

There are two different ways to check whether an application is hardware-accelerated:
1. If a view object is bound to a window that is hardware accelerated, the view.ishardwareaccelerated () method returns true;

2. If a Canvas object is hardware-accelerated, the canvas.ishardwareaccelerated () method returns True.

If you have to do this check in your drawing code, use the Canvas.ishardwareaccelerated () method instead of the view.ishardwareaccelerated () method where possible. When a view object is bound to a hardware-accelerated window, it can still use a canvas object that uses a non-hardware acceleration. This happens, for example, when a view object is drawn to a bitmap in the cache.

The role of hardaccelerated:

When hardware acceleration is enabled, the Android framework uses a new drawing mode, which uses the display list to present the application on the screen, which is faster。 To fully understand the display list and how they affect the application, it is useful to understand how Android is drawing a View object without hardware acceleration. The following describes the software-based and hardware-accelerated drawing modes. Software-based drawing mode
In the software's drawing mode, the View object is drawn by the following two steps: 1. To invalidate the view hierarchy; 2. Draws the view hierarchy.
Whenever an application needs to update its UI part, it calls back the invalidate () method of the View object that has changed the content. Invalid message requests are passed in the View object hierarchy to calculate the screen area (dirty area) that needs to be redrawn. The Android system then draws all the areas that intersect the dirty area in the view hierarchy. Unfortunately, there are two drawbacks to this approach:
1. This mode requires a lot of code execution in each drawing pass. For example, if an application calls a button
Invalidate () method, and the button is above another view object, the Android system will redraw it even if the view object does not change.
2. The second problem is that this kind of drawing mode hides bugs in the application. Because when the view object is associated with the dirty area
The Android system will redraw it, so even if you do not invoke the Invalidate () method on the View object, the change in the contents of the View object may cause it to be redrawn. When this happens, rely on another view object that is invalidated to get the correct behavior. This behavior can change every time you modify the application. For this reason, the invalidate () method of the custom view object should always be called when modifying the data and state of the drawing code that affects the View object.
Note: When the View object's properties change, such as the background color or the text in the TextView object, the Android system automatically calls the View object's invalidate () method. Hardware accelerated Drawing Mode
In this mode, the Android system will still use the invalidate () method and the Draw () method to request the screen to update and display the View object, but the actual drawing processing is different, it will immediately execute the drawing command, the Android system to record these commands in the internal display list , the list contains the output of the drawing code for 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 that is not invalidated can perform a simple redraw by republishing the previously recorded display list. This drawing pattern consists of three stages: 1. To invalidate the hierarchy of the view; 2. Record and update the display list; 3. Draws a display list.












Using this mode, it is not possible to rely on the draw () method of the intersecting dirty area view to perform drawing work. To make sure that the Android system records the display list of a View object, you must call the Invalidate () method, and if you forget to call the method, the View object will look the same as it was before the change occurs, which is a relatively easy bug to find. Using a display list is also good for improving the performance of animations, because setting properties such as transparency, rotation, and so on, does not invalidate the target view object (the system does this automatically). This optimization also applies to view objects with a display list (any view object when the application is hardware accelerated). For example, if you have a linearlayout layout for a ListView object that contains a button object, the display list for the LinearLayout layout is as follows: 1. Drawdisplaylist (ListView); 2. Drawdisplaylist (Button).
Assuming that you want to change the opacity of the ListView object now, when you call the Setalpha (0.5f) method of the ListView object, the display list contains the following processing: 1. Savelayeralpha (0.5);
2. Drawdisplaylist (ListView); 3. Restore;
4. Drawdisplaylist (Button).
There is no drawing code to execute the complex ListView object. Instead, the system simply updates the display list of the LinearLayout object. In an application that does not have hardware acceleration enabled, the list (ListView) and its parent object will execute the drawing code again. Drawing operations that are not supported by hardware acceleration
In hardware acceleration, the 2D rendering pipeline supports most of the drawing operations typically used for canvas, as well as some rarely used operations. All the drawing operations that are used to render the application are sent to the Android system, the default widgets and layouts, and some common visual effects such as reflection and tile texture are supported. The known operations that do not support hardware acceleration are listed below: 1. Canvas
Chippath () chipregion () drawpicture () Drawpostext () Drawtextonpath () drawvertives (2). Paint
Setlineartext () Setmaskfilter () Setrasterizer ()
In addition, there are some operational behaviors that vary depending on hardware acceleration enabled: 1. Canvas
ClipRect (): Hardware acceleration ignores the three clip modes of XOR, Difference, and Reversedifference, and 3D transforms are not available for clip rectangles.
Drawbitmapmesh (): Hardware acceleration ignores color arrays. DrawLines (): Hardware acceleration does not support antialiasing.
Setdrawfilter (): Hardware acceleration can be set, but is ignored. 2. Paint
Setdither (): Hardware acceleration ignores its settings.
Setfilterbitmap (): Bitmap filtering is always turned on.












Setshadowlayer (): This setting is only valid for text. 3. Composeshader
Composeshader objects can contain only different types of shaders (for example, Bitmapshader and lineargradient, but cannot contain instances of two Bitmapshader objects).
A Composeshader object cannot contain a Composeshader object.
If your application is affected by the functionality or limitations of these errors, you can turn off hardware acceleration by calling the Setlayertype (View.layer_type_software, null) method to the parts of the application that are affected. This way, there is still the ability to use hardware acceleration elsewhere.
View Layer
In all versions of Android, the view object has the ability to render out-of-screen buffers by using the View object's drawing buffer, or by using the Canvas.savelayer () method. Out-of-screen buffers or layers are used by multiple purposes. They can achieve better performance when rendering complex animations or using composite effects. For example, use the Canvas.savelayer () method to temporarily render a view object in a layer, and then use the opacity factor to synthesize the view object onto the screen for a fade-out effect.
Starting with Android3.0 (API level 11), use the View.setlayertype () method to take more control of the way the layer is used and when the opportunity is available. This API requires two parameters: one is the type of the layer and the other is optional, which describes the paint object to which the layer should be synthesized. The ability to use this paint object for color filtering, special blending modes, or layer transparency. The view object is capable of using the following three layer types:
The Layer_type_none:view object is rendered in a normal manner and is not returned by an off-screen cache. This type is the default behavior;
Layer_type_hardware: If the application is hardware-accelerated, then the view object is rendered in a hardware texture on the hardware. This layer type behaves the same as Layer_type_software if it is not accelerated by hardware.
The Layer_type_software:view object is rendered in a bitmap in the software. The type of layer to use depends on the following targets:
1. Performance: Use the hardware layer type to render the view into a hardware texture. Once the view object is rendered to a
Layer, its drawing code is not executed until the invalidate () method of the View object is called. For some animations, such as alpha animations, you can use the layer directly, which is very efficient for the GPU. 2. Visual effects: The use of hardware or software layer types and a paint object, can be some special visual processing applications
To a View object. For example, use the Colormatrixcolorfilter object to draw a black-and-white view object.
3. Compatibility: Using the Software layer type forces a view object to be rendered in the software. If the View object is hardware
Acceleration (for example, if the entire application is hardware-accelerated) rendering problems, it is an easy way to use the software layer type to address the hardware rendering pipeline limitations. View layers and animations
When the application is hardware accelerated, the hardware layer can deliver faster, smoother animations. When playing an animation with a complex drawing operation, it is not always possible to play at a speed of 60 frames per second. This can be mitigated by using the hardware layer to render the view object in a hardware texture. The hardware texture can be used in an animated view so that when the View object renders an animation, it eliminates the redraw action required by the View object. The view object will not be redrawn until the property of the View object changes (the invalidate () method is called). If you run an animation in your application and do not get the desired smoothing results, consider enabling the hardware layer on the animation view.
When a view is returned by the hardware layer, some properties processed by the layer method are composited onto the screen. Because they don't












The view object needs to be invalidated and redrawn, so setting these properties is very efficient. Below is a list of how the affected layers are synthesized. Invoking these property sets results in an optimization of the invalidation process and does not redraw the target view object:
1. Alpha: Change the transparency of the layer;
2. X,y,translation,translation: Change the position of the layer; 3. Scalex,scaley: The size of the change;
4. Rotation,rotation,rotationy: Change the direction of the middle of the 3D space, 5. Pivotx,pivoty: Change the origin of the layer.
These properties are the names used when animating a view object with a Objectanimator object. If you want to access these properties, you call the appropriate set or Get method. For example, to modify the Alpha property, call the Setalpha () method. The following code shows the most efficient way to rotate a view object around the y axis in 3D space: View.setlayertype (view.layer_type_hardware, NULL); Objectanimator.offloat (View, "RotationY", +). Start (); Because the hardware layer consumes the display memory, it is highly recommended to enable the hardware layer only during animation playback, and disable the hardware layer after the animation has finished playing. The ability to use animation listeners to do this: View.setlayertype (view.layer_type_hardware, NULL);
Objectanimator animator = objectanimator.offloat (view, "RotationY", 180); Animator.addlistener (New Animatorlisteneradapter () {@Override
public void Onanimationend (Animator animation) {
View.setlayertype (View.layer_type_none, NULL); } });
Animator.start ();
For more information on animating properties, see Property Animation (http://developer.android.com/guide/topics/graphics/prop-animation.html)
Tips and Tricks
Switching to hardware-accelerated 2D graphics can improve performance, but you still need to design your application in the following recommended ways to effectively use the GPU:
1. Reduce the number of view objects in your application
The more View objects The system draws, the slower it will be. This situation also applies to the software rendering pipeline. One of the effective ways to reduce the view object is to optimize the UI. 2. Avoid over-plotting
Do not draw too many layers at the top of each other. Because deleting a view removes all other opaque view objects that are obscured on top of the view object at the same time. If you need to draw several layers, try to incorporate them into a single layer, as much as possible in the composition mode above. A good rule is that the number of pixels per frame should not be greater than 2.5 times times that of the number on the screen (as measured by the bitmap's transparent lattice count). 3. Do not create render objects in the drawing method
A common mistake is to create a new paint object or Path object each time the rendering method is called. This forces the garbage collection to run frequently and bypasses caching and optimizations in the hardware pipeline. 4. Do not edit shapes frequently
For complex shapes, such as paths and circles, they are rendered using a texture mask. Each time you create or modify a path, the hardware channel creates a new mask, which consumes a lot of resources.

In order to get the application to request more memory, we know that the Android system has a memory usage limit for each application, and the memory limit of the machine is configured in the/system/build.prop file.

For example:

[Java]View PlainCopy

1. dalvik.vm.heapsize=128m
2. dalvik.vm.heapgrowthlimit=64m

Here, Heapgrowthlimit is a memory limit for a normal application, and the value obtained with Activitymanager.getlargememoryclass () is this. The maximum memory value can be used after heapsize is set to Largeheap=true in manifest.

Setting up Largeheap can indeed increase the amount of memory requested. But not how much memory the system can apply for, but is limited by dalvik.vm.heapsize.
But as programmers we should try to reduce the use of memory, as much as possible to recycle and reuse methods, rather than trying to increase memory. When the memory is very large, the time of each GC will also grow, and performance may decrease.

android--hardwareaccelerated Hardware acceleration Detailed android:largeheap= "true"