Hardware Acceleration

本文介绍了Android 3.0及以上版本中引入的硬件加速特性,详细解释了如何在不同层级上启用或禁用硬件加速,以及它对应用性能的影响。文章还讨论了软件绘制模型与硬件加速绘制模型的区别,并列举了一些不受支持的绘制操作。

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

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 hardware devices with hardware acceleration turned on to find any problems. The Unsupported drawing operations section describes known issues with drawing 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 theandroid:hardwareAccelerated attribute for the <activity> element. The following example enables hardware acceleration for 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 at the window level.

View level

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

myView.setLayerType(View.LAYER_TYPE_SOFTWARE, null);

Note: You currently cannot enable hardware acceleration at the 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 ofView.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 utilizesdisplay 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, if your application callsinvalidate() on a button and that button sits on top of another view, the Android system redraws the view even though it hasn't changed.
  • 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 LinearLayoutlooks 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 callingsetLayerType(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 and disable 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 theView.setLayerType() method. This API takes two parameters: the type of layer you want to use and an optionalPaint 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 asLAYER_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 work around limitations of the hardware rendering pipeline.

View layers and animations

Hardware layers can deliver faster and smoother animations when your application is hardware accelerated. Running an animation at 60 frames per second is not always possible when animating complex views that issue a lot of drawing operations. This can be alleviated by using hardware layers to render the view to a hardware texture. The hardware texture can then be used to animate the view, eliminating the need for the view to constantly redraw itself when it is being animated. The view is not redrawn unless you change the view's properties, which calls invalidate(), or if you call invalidate() manually. If you are running an animation in your application and do not obtain the smooth results you want, consider enabling hardware layers on your 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
  • xytranslationXtranslationY: Changes the layer's position
  • scaleXscaleY: Changes the layer's size
  • rotationrotationXrotationY: Changes the layer's orientation in 3D space
  • pivotXpivotY: 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 them only for the duration of the animation and then disable them after the animation is done. You can 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 garbage collector to run more often and also bypasses caches and optimizations in the hardware pipeline.
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.
<think>好的,用户遇到了在Ubuntu上编译AOSP后启动模拟器时出现的KVM硬件加速错误。我需要帮他解决这个问题。首先,我需要回忆之前处理类似问题的经验,并结合提供的引用内容来分析可能的解决方案。根据引用[1],错误信息显示需要硬件加速,而CPU加速状态显示KVM需要支持vmx或svm的CPU。这说明用户可能没有开启虚拟化支持,或者KVM没有正确配置。引用[3]提到进入BIOS开启IntelVT或AMDSVM,并用命令检查是否开启。所以第一步应该是检查BIOS设置,确保虚拟化已启用。接下来,用户可能已经开启了虚拟化,但需要验证。可以用egrep命令检查/proc/cpuinfo中的vmx或svm标志是否存在。如果返回0,说明没开启,需要进入BIOS设置。引用[3]中的步骤应该可以解决这个问题。 然后,安装KVM相关软件包。在Ubuntu上,通常需要安装qemu-kvm、libvirt-daemon-system等包,并将用户加入kvm组。这可以解决权限问题,确保用户有权访问/dev/kvm设备。如果用户没有安装这些包,或者没有正确配置权限,就会出现错误。 安装完成后,需要检查/dev/kvm的权限。使用ls-l查看,确保所属组是kvm,并且用户在该组中。如果没有,可能需要重启或重新加载kvm内核模块。另外,引用[2]提到在虚拟机中处理时,需要开启虚拟化引擎的选项。虽然用户是在物理机上的Ubuntu,但如果他在嵌套虚拟化环境中运行,也需要在宿主机的虚拟机设置中开启虚拟化支持,比如VMware或VirtualBox的VT-x/AMD-V选项。如果以上步骤都正确,但问题依旧,可能需要检查AOSP的编译选项是否正确。比如编译的是x86_64-eng,并且使用正确的lunch选项。确保编译环境和模拟器版本兼容。最后,如果所有配置都正确,但模拟器仍然无法启动,可能需要查看日志,使用详细模式启动emulator,找出具体的错误原因。或者尝试使用不同的模拟器版本,确保没有其他依赖缺失。 总结步骤:检查BIOS虚拟化设置,安装配置KVM,检查用户组权限,验证编译选项,处理嵌套虚拟化情况(如有必要),查看详细日志。需要一步步引导用户排除问题,确保每个环节都正确配置。</think>### 解决方案:Ubuntu AOSP模拟器KVM硬件加速错误处理 #### 1. **确认CPU虚拟化支持已开启** - **进入BIOS/UEFI**:重启电脑,进入BIOS设置界面(按键通常为`F2`/`Del`/`Esc`),找到以下选项: - **Intel CPU**:开启 `Intel Virtualization Technology (VT-x)` 或 `Intel VT-d`[^3]。 - **AMD CPU**:开启 `SVM Mode`[^3]。 - **验证是否生效**: ```bash egrep -c '(svm|vmx)' /proc/cpuinfo ``` 若输出值**大于0**,则表示已开启;若为0,需重新配置BIOS[^3]。 #### 2. **安装KVM依赖包** ```bash sudo apt-get install qemu-kvm libvirt-daemon-system libvirt-clients bridge-utils virt-manager ``` - 将当前用户加入`kvm`和`libvirt`组: ```bash sudo usermod -aG kvm $USER sudo usermod -aG libvirt $USER ``` - **重启系统**使组权限生效。 #### 3. **检查`/dev/kvm`权限** ```bash ls -l /dev/kvm ``` - 正常输出应为:`crw-rw---- 1 root kvm 10, 232 ...` - 若权限错误,执行: ```bash sudo chown root:kvm /dev/kvm ``` #### 4. **验证KVM运行状态** ```bash sudo systemctl is-active kvm ``` - 若状态为`inactive`,启动服务: ```bash sudo systemctl enable --now kvm ``` #### 5. **配置AOSP编译环境** - 确保编译目标为**x86_64**架构: ```bash source build/envsetup.sh lunch aosp_x86_64-eng ``` - 启动模拟器时添加`-accel on`参数: ```bash emulator -accel on ``` #### 6. **虚拟机嵌套虚拟化(仅限虚拟机环境)** - 若在VMware/VirtualBox中运行Ubuntu,需在宿主虚拟机设置中: 1. 开启虚拟化引擎(如Intel VT-x/AMD-V)。 2. 勾选“嵌套虚拟化”选项[^2]。 #### 7. **调试与日志分析** - 启动模拟器时显示详细日志: ```bash emulator -verbose -show-kernel ``` - 检查日志中是否包含`KVM is enabled`或`HAXM is enabled`。 --- ### 常见问题补充 - **Q:BIOS已开启虚拟化,但`/proc/cpuinfo`仍无vmx/svm标志?** - 可能原因:宿主机虚拟机未透传CPU虚拟化特性(需配置嵌套虚拟化)[^2]。 - **Q:模拟器启动后黑屏或无响应?** - 尝试切换模拟器版本(如`emulator -use-system-libs`)。 ---
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值