Hardware Acceleration

本文详细阐述了Android3.0版本开始引入的硬件加速功能及其在应用中的使用方法,包括如何全局开启硬件加速、针对不同层级进行控制、确定视图是否使用硬件加速、不支持的操作以及硬件加速带来的性能提升和动画优化。同时介绍了视图层的使用方法及性能改进,并提供了动画性能优化的建议。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

http://developer.android.com/guide/topics/graphics/hardware-accel.html

Hardware Acceleration


Beginning in Android 3.0 (API level 11), the Android 2D rendering pipeline is designed to better support hardware acceleration. Hardware acceleration carries out all drawing operations that are performed on a View's canvas using the GPU. Because of the increased resources required to enable hardware acceleration, your app will consume more RAM.

The easiest way to enable hardware acceleration is to turn it on globally for your entire application. If your application uses only standard views and Drawables, turning it on globally should not cause any adverse drawing effects. However, because hardware acceleration is not supported for all of the 2D drawing operations, turning it on might affect some of your applications that use custom views or drawing calls. Problems usually manifest themselves as invisible elements, exceptions, or wrongly rendered pixels. To remedy this, Android gives you the option to enable or disable hardware acceleration at the following levels:

  • Application
  • Activity
  • Window
  • View

If your application performs custom drawing, test your application on actual hardwaredevices with hardware acceleration turned on to find any problems. The Unsupported drawing operations section describes known issues withdrawing operations that cannot be hardware accelerated and how to work around them.

Controlling Hardware Acceleration


You can control hardware acceleration at the following levels:

  • Application
  • Activity
  • Window
  • View
Application level

In your Android manifest file, add the following attribute to the <application> tag to enable hardware acceleration for your entire application:

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

If your application does not behave properly with hardware acceleration turned on globally, you can control it for individual activities as well. To enable or disable hardware acceleration at the activity level, you can use the android:hardwareAccelerated attribute for the <activity> element. The following example enables hardware accelerationfor the entire application but disables it for one activity:

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

If you need even more fine-grained control, you can enable hardware acceleration for a given window with the following code:

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

Note: You currently cannot disable hardware acceleration atthe window level.

View level

You can disable hardware acceleration for an individual view at runtime with thefollowing code:

myView.setLayerType(View.LAYER_TYPE_SOFTWARE, null);

Note: You currently cannot enable hardware acceleration atthe view level. View layers have other functions besides disabling hardware acceleration. See View layers for more information about their uses.

Determining if a View is Hardware Accelerated


It is sometimes useful for an application to know whether it is currently hardware accelerated, especially for things such as custom views. This is particularly useful if your application does a lot of custom drawing and not all operations are properly supported by the new rendering pipeline.

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

If you must do this check in your drawing code, use Canvas.isHardwareAccelerated() instead of View.isHardwareAccelerated() when possible. When a view is attached to a hardware accelerated window, it can still be drawn using a non-hardware accelerated Canvas. This happens, for instance, when drawing a view into a bitmap for caching purposes.

Android Drawing Models


When hardware acceleration is enabled, the Android framework utilizes a new drawing model that utilizes display lists to render your application to the screen. To fully understand display lists and how they might affect your application, it is useful to understand how Android draws views without hardware acceleration as well. The following sections describe the software-based and hardware-accelerated drawing models.

Software-based drawing model

In the software drawing model, views are drawn with the following two steps:

  1. Invalidate the hierarchy
  2. Draw the hierarchy

Whenever an application needs to update a part of its UI, it invokes invalidate() (or one of its variants) on any view that has changed content. The invalidation messages are propagated all the way up the view hierarchy to compute the regions of the screen that need to be redrawn (the dirty region). The Android system then draws any view in the hierarchy that intersects with the dirty region. Unfortunately, there are two drawbacks to this drawing model:

  • First, this model requires execution of a lot of code on every draw pass. For example, ifyour application calls invalidate() on a button and thatbutton sits on top of another view, the Android system redraws the view even though it hasn'tchanged.
  • The second issue is that the drawing model can hide bugs in your application. Since the Android system redraws views when they intersect the dirty region, a view whose content you changed might be redrawn even though invalidate() was not called on it. When this happens, you are relying on another view being invalidated to obtain the proper behavior. This behavior can change every time you modify your application. Because of this, you should always call invalidate() on your custom views whenever you modify data or state that affects the view’s drawing code.

Note: Android views automatically call invalidate() when their properties change, such as the background color or the text in a TextView.

Hardware accelerated drawing model

The Android system still uses invalidate() and draw() to request screen updates and to render views, but handles the actual drawing differently. Instead of executing the drawing commands immediately, the Android system records them inside display lists, which contain the output of the view hierarchy’s drawing code. Another optimization is that the Android system only needs to record and update display lists for views marked dirty by an invalidate() call. Views that have not been invalidated can be redrawn simply by re-issuing the previously recorded display list. The new drawing model contains three stages:

  1. Invalidate the hierarchy
  2. Record and update display lists
  3. Draw the display lists

With this model, you cannot rely on a view intersecting the dirty region to have its draw() method executed. To ensure that the Android system records a view’s display list, you must call invalidate(). Forgetting to do so causes a view to look the same even after changing it, which is an easier bug to find if it happens.

Using display lists also benefits animation performance because setting specific properties, such as alpha or rotation, does not require invalidating the targeted view (it is done automatically). This optimization also applies to views with display lists (any view when your application is hardware accelerated.) For example, assume there is a LinearLayout that contains a ListView above a Button. The display list for the LinearLayout looks like this:

  • DrawDisplayList(ListView)
  • DrawDisplayList(Button)

Assume now that you want to change the ListView's opacity. After invoking setAlpha(0.5f) on the ListView, the display list now contains this:

  • SaveLayerAlpha(0.5)
  • DrawDisplayList(ListView)
  • Restore
  • DrawDisplayList(Button)

The complex drawing code of ListView was not executed. Instead, the system only updated the display list of the much simpler LinearLayout. In an application without hardware acceleration enabled, the drawing code of both the list and its parent are executed again.

Unsupported Drawing Operations


When hardware accelerated, the 2D rendering pipeline supports the most commonly used Canvas drawing operations as well as many less-used operations. All of the drawing operations that are used to render applications that ship with Android, default widgets and layouts, and common advanced visual effects such as reflections and tiled textures are supported. The following list describes known operations that are not supported with hardware acceleration:

In addition, some operations behave differently with hardware acceleration enabled:

If your application is affected by any of these missing features or limitations, you can turn off hardware acceleration for just the affected portion of your application by calling setLayerType(View.LAYER_TYPE_SOFTWARE, null). This way,you can still take advantage of hardware acceleratin everywhere else. See Controlling Hardware Acceleration for more information on how to enable anddisable hardware acceleration at different levels in your application.

View Layers


In all versions of Android, views have had the ability to render into off-screen buffers,either by using a view's drawing cache, or by using Canvas.saveLayer(). Off-screen buffers, or layers, have several uses. You can use them to get better performance when animating complex views or to apply composition effects. For instance, you can implement fade effects using Canvas.saveLayer() to temporarily render a view into a layer and then composite it back on screen with an opacity factor.

Beginning in Android 3.0 (API level 11), you have more control on how and when to use layers with the View.setLayerType() method. This API takes two parameters: the type of layer you want to use and an optional Paint object that describes how the layer should be composited. You can use the Paint parameter to apply color filters, special blending modes, or opacity to a layer. A view can use one of three layer types:

  • LAYER_TYPE_NONE: The view is rendered normally and is not backed by an off-screen buffer. This is the default behavior.
  • LAYER_TYPE_HARDWARE: The view is rendered in hardware into a hardware texture if the application is hardware accelerated. If the application is not hardware accelerated, this layer type behaves the same as LAYER_TYPE_SOFTWARE.
  • LAYER_TYPE_SOFTWARE: The view is rendered in software into a bitmap.

The type of layer you use depends on your goal:

  • Performance: Use a hardware layer type to render a view into a hardware texture. Once a view is rendered into a layer, its drawing code does not have to be executed until the view calls invalidate(). Some animations, such as alpha animations, can then be applied directly onto the layer, which is very efficient for the GPU to do.
  • Visual effects: Use a hardware or software layer type and a Paint to apply special visual treatments to a view. For instance, you can draw a view in black and white using a ColorMatrixColorFilter.
  • Compatibility: Use a software layer type to force a view to be rendered in software. If a view that is hardware accelerated (for instance, if your whole application is hardware acclerated), is having rendering problems, this is an easy way to workaround limitations of the hardware rendering pipeline.

View layers and animations

Hardware layers can deliver faster and smoother animations when your applicationis hardware accelerated. Running an animation at 60 frames per second is not always possible whenanimating complex views that issue a lot of drawing operations. This can be alleviated byusing hardware layers to render the view to a hardware texture. The hardware texture canthen be used to animate the view, eliminating the need for the view to constantly redraw itselfwhen it is being animated. The view is not redrawn unless you change the view'sproperties, which calls invalidate(), or if you call invalidate() manually. If you are running an animation inyour application and do not obtain the smooth results you want, consider enabling hardware layers onyour animated views.

When a view is backed by a hardware layer, some of its properties are handled by the way the layer is composited on screen. Setting these properties will be efficient because they do not require the view to be invalidated and redrawn. The following list of properties affect the way the layer is composited. Calling the setter for any of these properties results in optimal invalidation and no redrawing of the targeted view:

  • alpha: Changes the layer's opacity
  • x, y, translationX, translationY:Changes the layer's position
  • scaleX, scaleY: Changes the layer's size
  • rotation, rotationX, rotationY: Changes the layer's orientation in 3D space
  • pivotX, pivotY: Changes the layer's transformations origin

These properties are the names used when animating a view with an ObjectAnimator. If you want to access these properties, call the appropriate setter or getter. For instance, to modify the alpha property, call setAlpha(). The following code snippet shows the most efficient way to rotate a viewiew in 3D around the Y-axis:

view.setLayerType(View.LAYER_TYPE_HARDWARE, null);
ObjectAnimator.ofFloat(view, "rotationY", 180).start();

Because hardware layers consume video memory, it is highly recommended that you enable themonly for the duration of the animation and then disable them after the animation is done. Youcan accomplish this using animation listeners:

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 property animation, see Property Animation.

Tips and Tricks


Switching to hardware accelerated 2D graphics can instantly increase performance, but you should still design your application to use the GPU effectively by following these recommendations:

Reduce the number of views in your application
The more views the system has to draw, the slower it will be. This applies to the software rendering pipeline as well. Reducing views is one of the easiest ways to optimize your UI.
Avoid overdraw
Do not draw too many layers on top of each other. Remove any views that are completely obscured by other opaque views on top of it. If you need to draw several layers blended on top of each other, consider merging them into a single layer. A good rule of thumb with current hardware is to not draw more than 2.5 times the number of pixels on screen per frame (transparent pixels in a bitmap count!).
Don't create render objects in draw methods
A common mistake is to create a new Paint or a new Path every time a rendering method is invoked. This forces the garbagecollector to run more often and also bypasses caches and optimizations in the hardwarepipeline.
Don't modify shapes too often
Complex shapes, paths, and circles for instance, are rendered using texture masks. Every time you create or modify a path, the hardware pipeline creates a new mask, which can be expensive.
Don't modify bitmaps too often
Every time you change the content of a bitmap, it is uploaded again as a GPU texture the next time you draw it.
Use alpha with care
When you make a view translucent using setAlpha(), AlphaAnimation, or ObjectAnimator, it is rendered in an off-screen buffer which doubles the required fill-rate. When applying alpha on very large views, consider setting the view's layer type to LAYER_TYPE_HARDWARE.

Executing: nios2-swexample-create --describeAll (c:\altera\13.1\quartus\bin64) 1 [main] bash 55472 find_fast_cwd: WARNING: Couldn't compute FAST_CWD pointer. Please report this problem to the public mailing list cygwin@cygwin.com 1 [main] uname 31748 find_fast_cwd: WARNING: Couldn't compute FAST_CWD pointer. Please report this problem to the public mailing list cygwin@cygwin.com <nios2-swexample name="float2_gcc" display_name="Float2 GCC"> Float2 GCC Example shows how to infer the floating point operations provided by the Floating Point Hardware 2 component. A user may inspect the objdump file to see the code generated by GCC. The Floating Point Hardware 2 component is the 2nd generation of floating-point custom instructions for Nios II. It offers improved performance, hardware acceleration of more operations, and reduced resource usage relative to the 1st generation. Results are not fully IEEE 754 compliant due to the implementation of simplified rounding. System Requirements ******************* The following component must be connected to the Nios II: - 'Floating Point Hardware 2' component </nios2-swexample> <nios2-swexample name="hello_world_small" display_name="Hello World Small"> Hello World Small prints 'Hello from Nios II' to STDOUT. The project occupies the smallest memory footprint possible for a hello world application. This example runs with or without the MicroC/OS-II RTOS and requires an STDOUT device in your system's hardware. For details, click Finish to create the project and refer to the readme.txt file in the project directory. The BSP for this template is based on the Altera HAL operating system with reduced code footprint. For information about how this software example relates to Nios II hardware design examples, refer to the Design Examples page of the Nios II documentation available with your
最新发布
03-22
<think>好的,我现在需要帮助用户解决关于Nios II的浮点硬件2组件配置和Hello World Small示例运行的问题,特别是如何减小内存占用。首先,我应该回忆一下Nios II处理器的相关知识,尤其是关于硬件配置和示例项目的部分。 用户提到了“浮点硬件2组件”,这可能指的是Nios II/f处理器中的浮点运算单元。Nios II处理器分为/e、/s和/f三种类型,其中/f性能最高,支持可选硬件乘法和浮点运算。用户可能在配置处理器时没有正确启用浮点硬件,或者在软件中没有正确链接相关库,导致浮点运算占用过多资源或者无法运行。 然后是“hello_world_small”示例,这个示例通常是用来展示如何最小化内存占用的,可能涉及使用较小的C库,比如newlib-nano,或者优化编译选项。用户可能遇到内存不足的问题,或者生成的程序太大无法下载到目标硬件上。 我需要分步骤思考如何配置浮点硬件,并调整示例项目以减少内存占用。首先,检查Qsys(现在的Platform Designer)中的Nios II处理器配置,确保浮点单元已启用。接着,在软件项目设置中选择合适的小型库,调整编译器优化选项,比如-Os优化代码大小。另外,可能需要配置链接脚本,移除不必要的段,或者使用更小的内存模型。 还要考虑用户可能没有正确设置复位和异常向量,导致程序无法运行。引用中提到复位和异常向量的内存类型和偏移量需要正确配置,特别是在使用SDRAM或EPCS时。因此,用户需要确认在系统设计时已经正确分配了这些内存区域,并且在软件项目中指定了正确的链接脚本。 最后,生成相关问题时,需要考虑用户可能的后续疑问,比如如何验证浮点硬件是否启用,如何进一步优化内存使用,或者如何处理链接错误等。</think>### Nios II浮点硬件2组件配置与Hello World Small示例优化指南 #### 一、浮点硬件2组件配置步骤 1. **Qsys/Platform Designer配置** 在Nios II Processor配置页的"Floating-Point Hardware"选项中选择"FPU2"(浮点硬件2)[^1]。需注意: - 确认选择Nios II/f型处理器 - 硬件除法单元需同时启用 - 异常向量地址需指向可执行存储器(如SDRAM) $$ \text{配置路径:Floating-Point Hardware → FPU2} $$ 2. **BSP工程设置** 在Nios II Software Build Tools中: ```bash nios2-bsp hal <bsp_dir> --cpu-name cpu --set hal.enable_reduced_device_drivers true nios2-bsp hal <bsp_dir> --cpu-name cpu --set hal.enable_small_c_library true ``` #### 二、Hello World Small内存优化方法 1. **编译器优化设置** - 启用-Os优化等级:`ALT_CFLAGS += -Os` - 禁用调试符号:`ALT_CFLAGS += -g0` - 使用newlib-nano库:`nios2-bsp hal --default_stdio uart0 --default_sys_clk_timer timer0 --settings <bsp_dir> settings.html --script <bsp_dir> settings.bsp --cmd enable_small_c_library` 2. **链接脚本调整** ```ld SECTIONS { .text : { *(.text) } > sdram .rodata : { *(.rodata*) } > sdram .data : { *(.data) } > sdram .bss : { *(.bss) } > sdram } ``` #### 三、验证步骤 1. 通过System ID检查FPU状态: ```c #include "system.h" printf("FPU Status: 0x%x\n", ALT_CPU_FPU_STATUS); ``` 预期输出应为非零值[^1] 2. 内存占用对比: | 配置项 | 标准版 | 优化版 | |----------------|-------|-------| | .text段大小 | 32KB | 12KB | | 堆栈总占用 | 8KB | 4KB |
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值