Android Graphic - Overview

翻译原文连接：
http://source.android.com/devices/graphics/index.html

Graphics

The Android framework offers a variety of graphics rendering APIs for 2D and 3D that interact with manufacturer implementations of graphics drivers, so it is important to have a good understanding of how those APIs work at a higher level. This page introduces the graphics hardware abstraction layer (HAL) upon which those drivers are built.

Android Framework 为2D和3D提供了多种多样的图形渲染API，这些API与厂商实现的graphics drivers交互，所以了解这些API在更高层次是如何工作的是很重要的。这篇文章将介绍图形硬件抽象层（HAL），那些driver正是基于其上来构建的。

Application developers draw images to the screen in two ways: with Canvas or OpenGL. See System-level graphics architecture for a detailed description of Android graphics components.

应用开发者绘制图像到屏幕上有两种方法：使用Canvas 或者OpenGL。系统级的graphics architecture一文，对Android graphic组件有更详细的描述。

android.graphics.Canvas is a 2D graphics API and is the most popular graphics API among developers. Canvas operations draw all the stock and custom android.view.Views in Android. In Android, hardware acceleration for Canvas APIs is accomplished with a drawing library called OpenGLRenderer that translates Canvas operations to OpenGL operations so they can execute on the GPU.

android.graphics.Canvas是一个2D的图形API，而且是开发者中最流行的图形API。Canvas operations draw all the stock and custom android.view.Views in Android.(?) 在Android 里面，Canvas API的硬件加速是由一个叫OpenGLRender的渲染库(libhwui.so)实现的，这个库将Canvas的操作转换成可以在GPU上执行的OpenGL操作。

Beginning in Android 4.0, hardware-accelerated Canvas is enabled by default. Consequently, a hardware GPU that supports OpenGL ES 2.0 is mandatory for Android 4.0 and later devices. See the Hardware Acceleration guide for an explanation of how the hardware-accelerated drawing path works and the differences in its behavior from that of the software drawing path.

从Android 4.0 开始，硬件加速Canvas是默认打开的。因此，在Android4.0 以及之后的版本上，支持OpenGl ES 2.0 的硬件GPU都是强制必需的。查看Hardware Acceleration guide可以了解硬件加速的绘制path是如何工作的，以及与软件绘制path在行为上有何不同。

In addition to Canvas, the other main way that developers render graphics is by using OpenGL ES to directly render to a surface. Android provides OpenGL ES interfaces in the android.opengl package that developers can use to call into their GL implementations with the SDK or with native APIs provided in the Android NDK.

除了canvas，开发渲染图形的另外一种方法是通过直接使用OpenGL ES 渲染到一块Surface上。Android在android.opengl package中提供了OpenGl ES 的接口，开发者可以使用SDK里的这些接口完成他们的GL实现(?)，或者使用NDK中提供的native APIs。

Android implementers can test OpenGL ES functionality using the drawElements Quality Program, also known as deqp.

Android 的implementers可以使用drawElements Quality Program 来测试OpenGL ES的功能。

Android graphics components

No matter what rendering API developers use, everything is rendered onto a “surface.” The surface represents the producer side of a buffer queue that is often consumed by SurfaceFlinger. Every window that is created on the Android platform is backed by a surface. All of the visible surfaces rendered are composited onto the display by SurfaceFlinger.

无论开发者使用哪一种渲染API，所有东西都将被渲染到一块“surface”上。这块Surface代表了一个buffer queue的生产者端，这个buffer queue经常被SF消费。每个窗口背后都有一个Surface 支撑。所有可见的渲染完毕的Surface都会被SF合成到Display上。

The following diagram shows how the key components work together:

下面的图显示了关键组件如何协同工作。

Figure 1. How surfaces are rendered 图1. Surfaces 如何被渲染。

The main components are described below: 主要组件描述如下：

Image Stream Producers 图像流生产者

An image stream producer can be anything that produces graphic buffers for consumption. Examples include OpenGL ES, Canvas 2D, and mediaserver video decoders.

一个图像流生产者可以是任何可以产生用于消费的图形buffer的东西。比如OpenGLES， Canvas 2D，以及mediaserver 视频解码器。

Image Stream Consumers 图像流消费者

The most common consumer of image streams is SurfaceFlinger, the system service that consumes the currently visible surfaces and composites them onto the display using information provided by the Window Manager. SurfaceFlinger is the only service that can modify the content of the display. SurfaceFlinger uses OpenGL and the Hardware Composer to compose a group of surfaces.

最常见的消费者是SF，消费当前可见surface，并根据Window Manager提供的信息将他们合成到Display上的系统服务。SF是唯一一个可以修改Display内容的服务。SF使用OpenGL和Hardware Composer来合成一组Surface。

Other OpenGL ES apps can consume image streams as well, such as the camera app consuming a camera preview image stream. Non-GL applications can be consumers too, for example the ImageReader class.

其他OpenGL ES apps 也可以消费图像流，比如，Camera APP 消费camera的preview 图形流。非GL app也可以是消费者，比如ImageReader 类。

Window Manager

The Android system service that controls a window, which is a container for views. A window is always backed by a surface. This service oversees lifecycles, input and focus events, screen orientation, transitions, animations, position, transforms, z-order, and many other aspects of a window. The Window Manager sends all of the window metadata to SurfaceFlinger so SurfaceFlinger can use that data to composite surfaces on the display.

Android中控制一个作为View容器的窗口的系统服务。监管窗口的生命周期，输入和焦点事件，转屏，切换，动画，位置，转换，z-序，以及诸多其他方面。WM将所有的Window信息发送给SF，这样SF就能够使用这些数据在Display上合成surface。

Hardware Composer

The hardware abstraction for the display subsystem. SurfaceFlinger can delegate certain composition work to the Hardware Composer to offload work from OpenGL and the GPU. SurfaceFlinger acts as just another OpenGL ES client. So when SurfaceFlinger is actively compositing one buffer or two into a third, for instance, it is using OpenGL ES. This makes compositing lower power than having the GPU conduct all computation.

Display子系统的硬件抽象层。SF可以将某些合成工作委托给Hardware Composer以分担GPU的工作。SF仅仅作为OpenGL ES的另外一个client端。所以，当SF正在合成一块或两块buffer到第三块上时，例如使用OpenGL ES。这导致使合成消耗更少的能量，比GPU做所有的计算。

The Hardware Composer HAL conducts the other half of the work. This HAL is the central point for all Android graphics rendering. Hardware Composer must support events, one of which is VSYNC. Another is hotplug for plug-and-play HDMI support.

See the Hardware Composer HAL section for more information.

Hardware Composer的HAL层控制另外一半的工作。HAL是所有Android Graphics 渲染的重要部分。Hardware Composer支持一些事件，其中一个是Vsync。另外一个HDMI即插即用的hotplug。

Gralloc

The graphics memory allocator is needed to allocate memory that is requested by image producers. See the Gralloc HAL section for more information.

Graphic 内存分配器用于给Image producers分配内存。查看Gralloc HAL 部分获取更多信息。

Data flow

See the following diagram for a depiction of the Android graphics pipeline:

Figure 2. Graphic data flow through Android

The objects on the left are renderers producing graphics buffers, such as the home screen, status bar, and system UI. SurfaceFlinger is the compositor and Hardware Composer is the composer.

左边的是产生图形buffer的renderers，比如Home screen，status bar，systemUI。SF是合成器，Hardware Composer is the composer(?)

BufferQueue

BufferQueues provide the glue between the Android graphics components. These are a pair of queues that mediate the constant cycle of buffers from the producer to the consumer. Once the producers hand off their buffers, SurfaceFlinger is responsible for compositing everything onto the display.

BufferQueue 提供Android Graphic 组件的蓝色部分。这些成对的队列，负责buffer从producer到consumer的持续周期循环。一旦producer切换buffer，SF有责任合成到display上。

See the following diagram for the BufferQueue communication process.

Figure 3. BufferQueue communication process
图3. BufferQueue通信过程

BufferQueue contains the logic that ties image stream producers and image stream consumers together. Some examples of image producers are the camera previews produced by the camera HAL or OpenGL ES games. Some examples of image consumers are SurfaceFlinger or another app that displays an OpenGL ES stream, such as the camera app displaying the camera viewfinder.

BufferQueue包含维系Image stream producer 和image stream comsumers的逻辑。一些image producer的例子是，由camera HAL产生的camera的preview数据，或者OpenGL ES 游戏。一些image comsumers的例子是，SF，或者其他app 比如显示camera viewfinder的camera app。(?)

BufferQueue is a data structure that combines a buffer pool with a queue and uses Binder IPC to pass buffers between processes. The producer interface, or what you pass to somebody who wants to generate graphic buffers, is IGraphicBufferProducer (part of SurfaceTexture). BufferQueue is often used to render to a Surface and consume with a GL Consumer, among other tasks.

BufferQueue 是包含buffer池队列的一个数据结构，并使用Binder IPC通信在进程间传递buffer。生产者接口，或者你传递给希望产生graphic buffers一方的是IGraphicBufferProduce（SurfaceTexture的一部分。）。 BufferQueue 经常用于在不同task之间，渲染到一块Surface上，被GL consumer 消费(?)。

BufferQueue can operate in three different modes:

Synchronous-like mode - BufferQueue by default operates in a synchronous-like mode, in which every buffer that comes in from the producer goes out at the consumer. No buffer is ever discarded in this mode. And if the producer is too fast and creates buffers faster than they are being drained, it will block and wait for free buffers.

BufferQueue可以以三种不同模式操作：
同步模式 - BufferQueue默认情况下是同步模式，在这种模式下，所有的buffer来自producer，然后被consumer 所消费。没有buffer会被丢弃。如果producer太快，并且创建buffer比消费buffer快的话，producer将会block，等待空闲buffer

Non-blocking mode - BufferQueue can also operate in a non-blocking mode where it generates an error rather than waiting for a buffer in those cases. No buffer is ever discarded in this mode either. This is useful for avoiding potential deadlocks in application software that may not understand the complex dependencies of the graphics framework.

非阻塞模式 - BufferQueue可以在非阻塞模式下运行。它会产生error，而不是等待buffer。在这种mode下，同样没有buffer被丢弃。在那些可能不是很理解graphic framework中复杂依赖关系的应用软件中，这对于避免潜在的死锁是非常有用的。

Discard mode - Finally, BufferQueue may be configured to discard old buffers rather than generate errors or wait. For instance, if conducting GL rendering to a texture view and drawing as quickly as possible, buffers must be dropped.

丢弃模式 - 最后，BufferQueue可能被设置为丢弃旧的buffers，而不是产生错误或等待。比如，如果使用GL渲染到一个texture view，并且尽可能快的绘制，buffers可能会被丢弃。

To conduct most of this work, SurfaceFlinger acts as just another OpenGL ES client. So when SurfaceFlinger is actively compositing one buffer or two into a third, for instance, it is using OpenGL ES.

为了conduct大部分工作，SF仅仅扮演OpenGL ES的另外一个client端。So when SurfaceFlinger is actively compositing one buffer or two into a third, for instance, it is using OpenGL ES.(?)

The Hardware Composer HAL conducts the other half of the work. This HAL acts as the central point for all Android graphics rendering.

Hardware Composer HAL 控制另外一部分工作。对于所有的Android 图形渲染，HAL扮演重要角色。

Synchronization framework

Since Android graphics offer no explicit parallelism, vendors have long implemented their own implicit synchronization within their own drivers. This is no longer required with the Android graphics synchronization framework. See the Explicit synchronization section for implementation instructions.

The synchronization framework explicitly describes dependencies between different asynchronous operations in the system. The framework provides a simple API that lets components signal when buffers are released. It also allows synchronization primitives to be passed between drivers from the kernel to userspace and between userspace processes themselves.

同步框架明确描述了系统中不同异步操作之间的依赖关系。框架提供了一些简单的API，是组件发出信号通知buffer被释放了。同样允许同步的原始类型在从kernel到userspace的driver之间传递(between drivers from the kernel to userspace(?))，以及userspace进程间传递。

For example, an application may queue up work to be carried out in the GPU. The GPU then starts drawing that image. Although the image hasn’t been drawn into memory yet, the buffer pointer can still be passed to the window compositor along with a fence that indicates when the GPU work will be finished. The window compositor may then start processing ahead of time and hand off the work to the display controller. In this manner, the CPU work can be done ahead of time. Once the GPU finishes, the display controller can immediately display the image.

比如，一个app可能排队等候GPU执行任务。GPU开始绘制图像，尽管image还没有绘制到内存，但是这个buffer 指针会携带一个指示GPU何时完成工作的fence，仍然可以传递给窗口合成器。窗口合成器可能提前开始处理，将任务切换到display controller。在这种方式下，CPU任务可以提前完成。一旦GPU完成任务，display controller可以迅速的显示这个image。

The synchronization framework also allows implementers to leverage synchronization resources in their own hardware components. Finally, the framework provides visibility into the graphics pipeline to aid in debugging.

同步框架同样允许implementers 在他们的硬件组件中leverage(?)同步资源。最后，该框架为图形管道提供可视性 以帮助debug(?)。