Android的圖形系統發展經歷了通過CPU模擬圖形操作，和GPU專門進行圖形處理的階段，因爲這方面硬件技術發展很快，因此Android圖形系統也在不斷調整，以期提供更加快速流暢的UI體驗。
圖形操作可以有兩種方式實現：一是利用通用CPU模擬圖形操作；二是利用GPU專門做圖形操作。前者會增加CPU的負擔，在現在高分辨率已經是普遍現象的時候，讓通用處理器來完成大量的圖形計算已經不現實。Android圖形系統的發展過程也驗證了這一觀點。
爲了達到高效的圖形處理效果，是必須緊密結合軟件和硬件的。這篇文章主要介紹跟Android的圖形子系統。以後可能會對這些主題進行更加深入的探討。
Android圖形系統的軟件構成
下面的示意圖，展示了Android上負責圖形處理的軟件模塊。
一個典型Android應用中各個圖形系統組件的關係圖
GPU:
GPU專門設計用於加速圖形操作。GPU不同於CPU，它的一個設計目的就是高度的並行化，並行化是大部分圖形計算的共同特徵。
Android 剛剛問世的時候，GPU還是可選的，最近發佈的版本中，GPU已經是一個必配硬件。如果系統中沒有GPU，系統使用的OpenGL ES就包含了libagl和pixelflinger，通過軟件實現OpenGL ES協議接口，有時也有硬件支持的CopyBit。但是不幸的是，Android通過軟件模擬OpenGL，並不支持OpenGL ES 2.0。現在，Android系統中的不少組件使用了OpenGL ES 2.0，比如HWUI、Renderscript、SurfaceTexture。平板電腦都有很高的分辨率，純軟件的模擬支持並不能保證圖形的填充需 求，也就不能爲用戶提供流暢的UI體驗。廠商如果想製造基於ICS或者更高版本Android系統的設備，就必須具有支持OpenGL ES 2.0 的GPU。
Canvas:
畫布是應用程序用來繪製Widget或圖形等元素的地 方。Froyo和Gingerbread上，畫布通過Skia來繪製。Honeycomb及以後的版本，HWUI被加入了進來，提供了GPU加速支持。在 Ice Cream Sandwich及以後的版本上，HWUI缺省用於圖形的繪製。
Skia:
Skia是一組2D繪圖的API，它完全通過軟件實現。由於性能方面的原因，Skia逐漸被HWUI所替代。
HWUI
HWUI 可以使UI組件使用GPU加速。HWUI是在Honeycomb中引入進來的，目的是使交互更加快速，及時響應，流暢。在大分辨率的平板電腦上，通過 Skia來繪製動畫，會佔用很高的CPU資源，進而拖慢整個系統。HWUI需要支持OpenGL ES 2.0的GPU，不能通過軟件模擬。
Renderscript
Renderscript 同樣也是Honeycomb引入的新的API，它的設計爲了同時解決移植和性能問題。應用程序員用Renderscript（基於C99）編寫代碼，然後 一個LLVM的交叉編譯器把它編譯爲機器獨立的bit code，應用程序員再將其打包到apk中。當用戶下載apk時，設備上的編譯器（基於LLVM，位於/system/lib/libbcc.so）將 bit code編譯爲目標機器上的指令。
Renderscript在Froyo和Gingerbread上也存在，但是不是公開的API。只有Android的一些wallpaper使用了它。那時它的實現也非常粗糙，功能有限。
Surface:
一 個Surface對應一個屏幕外緩衝區，應用程序用來渲染窗口內容。一個遊戲程序，它可能使用OpenGL在Surface上繪製3D對象，一個普通應用 程序，它可能使用Skia來繪製Widget或者文本，它也可能使用HWUI庫來啓用GPU加速。從ICS開始，Surface通過一個後端的 SurfaceTexture實現，這就意味着Surface對應的不再是一個緩衝區，而是一個紋理（texture）。
Android平臺的圖形棧
SurfaceFlinger:
SurfaceFlinger是一個合成器，它管理來自於不同應用的Surface。比如，可能有許多應用同時存在，與此對應的，存在許多獨立的Surface需要被渲染。SurfaceFlinger決定屏幕上顯示的內容，那些需要被覆蓋，進行裁剪。
SurfaceFlinger使用的是OpenGL ES 1.1標準中的函數。爲什麼呢？如果使用OpenGL ES 2.0，就必須需要支持OpenGL ES 2.0的硬件GPU，這會使系統的啓動更加複雜，也會使模擬器的實現更加困難。
HW Composer:
硬件合成器是Honeycomb引入的一個HAL，SurfaceFlinger使用它，利用硬件資源來加速Surface的合成，比如3D GPU和2D的圖形引擎。
CopyBit:
CopyBit也是一個HAL。它允許使用特殊硬件來加速一些圖形操作，比如複製（blitting）。它設計的初衷是在沒有3D GPU的系統上加速軟件的渲染過程。CopyBit在ICS中被刪除了，因爲GPU已經成爲一個必備硬件，沒有必要專門設計一個加速部件。
Libagl/PixelFlinger:
libagl 是一個通過軟件實現了OpenGL ES 1.0和1.1版本API的組件。它使用PixelFlinger來實現OpenGL調用。爲了加速使用PixelFlinger的渲染過程，JIT被引 入了進來，稱爲CodeFling。CodeFling生成機器代碼，它急劇加速了許多類型的像素操作。
可以看出，Android的圖形系統在不斷的調整，目的是爲了提供更加快速流暢的UI體驗。這就是Android版本中圖形相關代碼變動很大的原因。
Learning about Android Graphics Subsystem
By Bhanu Chetlapalli
Software Engineer, MIPS Technologies
Graphics Performance is the most important component in defining any user interface (UI) experience. The smoothness of the UI interactions and the crispness of the images are all directly dependent on the graphics capabilities of the underlying platform. Customers expect rapid visual feedback when buttons and keys are pressed. Having a dedicated graphics engine and an operating system that correctly utilizes that engine will significantly reduce the workload on the CPU, vastly improving user experience.
Here at MIPS we support many open source and commercial operating systems with versions that are optimized to take full advantage of the MIPS processor architecture. Android is one of those open source operating system that we have put significant work into porting to our architecture. Early in the life of Android many cell phone companies shipped “bare bones” products running Android. Many of those products did not have the responsiveness and crisp graphics customers were expecting because the products did not have a complete graphics engine and relied on the CPU to “emulate” graphics operations. Since then almost all smart phones now have graphics engines that fully support the requirements of Android which takes a large burden off the CPU.
Moving onto the specifics of efficient graphics processing, the hardware and software have to work in tandem to enable this. This post aims to briefly explain a few related topics so that engineers can have a better understanding of Android’s Graphics subsystem. I will cover some of these topics in more detail in my future posts.
The Android Graphics Software Components
The following chart shows the software components in the Android operating system responsible for graphics. I will go through a discussion of most of these and provide some insight into their purpose.
Role of GPUs:
A Graphics Processing Unit (GPU) is a specialized hardware engine which greatly accelerates graphics operations. They are different from CPUs in that they are designed to do highly parallel work – which is typical of most graphics operations.
When Android first started, GPUs were somewhat optional, but with newer releases, GPUs became a mandatory requirement. Systems without GPUs use a software OpenGL ES stack consisting of libagl & pixelflinger, sometimes with hardware support from CopyBIT. Unfortunately software emulation of OpenGL on Android does not support the OpenGL ES 2.0 standard. Today large parts of the Android operating system use OpenGL ES 2.0 through components like HWUI, Renderscript, SurfaceTextures, etc. Tablets devices all have high resolution and software simply cannot keep up with the fill rates required to provide a smooth user experience. Manufacturers who plan to launch new devices that support Android Ice Cream Sandwich (ICS) or later releases must have an OpenGL ES 2.0 GPU.
Canvas:
Canvas is the Android class which application developers would use to draw widgets, pictures etc. In Android versions Froyo and Gingerbread Canvas would do the drawing using Skia. Android Honeycomb and onward, HWUI was added as an alternate GPU-accelerated option. Android Ice Cream Sandwich (ICS) and onward, HWUI is the default.
Skia:
Skia is a 2D drawing API which is used by applications and works completely in software. For performance reasons Skia is slowly being replaced by HWUI.
HWUI
The HWUI library enables UI components to be accelerated using the GPU. HWUI was introduced in Honeycomb to make the user interface fast, responsive and smooth. Since tablets had very high resolutions, using Skia for effects like animation would have been too CPU intensive and slow. HWUI requires an OpenGL ES 2.0 compliant GPU which cannot be emulated by software on Android.
Renderscript
Renderscript was a new API introduced in Honeycomb* to address portability and performance at the same time. The application developer writes the code in the Renderscript language (which is based on C99), and an LLVM cross compiler on the host converts it to machine-independent IR called bit code, the developer then packages the bit code files into the Android application (APK). When the user downloads the APK, an on-device compiler (LLVM based, located in /system/lib/libbcc.so) compiles it from bit code to the actual machine instructions for the target platform.
* Renderscript was available in Froyo & Gingerbread but was not a published API. Only a few wallpapers in the Android source used it. Its implementation was also fairly trivial & constrained.
Surface:
A Surface in Android corresponds to an off screen buffer into which an application renders the contents. An application might be a game which uses OpenGL to draw 3D objects directly into a surface or a normal application which uses Skia to draw widgets, text, etc. It could even use HWUI library to enable a GPU accelerated user interface. From Android ICS, surfaces are implemented with a SurfaceTexture backend which means instead of a buffer, a texture is used.
SurfaceFlinger:
SurfaceFlinger is the compositor that manages multiple surfaces from various apps. For example, there could be many running applications with independent Surfaces that are being rendered. SurfaceFlinger determines what will be shown on the screen and does overlays as needed.
SurfaceFlinger uses only the functions in the OpenGL ES 1.1 standard. If SurfaceFlinger used functions in OpenGL ES 2.0, it would require GPU hardware and drivers to be working – which would complicate bring-up on new devices and the Android emulator.
HW Composer:
HW Composer is a Hardware Abstraction Layer (HAL) introduced in Honeycomb that is used by SurfaceFlinger to efficiently perform composition using hardware resources like a 3D GPU or a 2D graphics engine.
CopyBit:
CopyBit was a hardware abstraction layer (HAL) which allowed the use of special hardware that can speed up some graphics operations like blitting etc. It was used to accelerate software rendering on systems without 3D GPUs. CopyBit support was removed in ICS, since GPUs became mandatory for supporting the newer user interface.
Libagl/PixelFlinger:
libagl is the library which implements the OpenGL ES 1.0 & 1.1 API in software. It uses PixelFlinger to implement the OpenGL calls. To speed up the rendering using PixelFlinger, a just in time compiler (JIT) was introduced called CodeFlinger. CodeFlinger generates direct machine code which drastically speeds up many types of pixel operations.
Conclusion
I hope this provided you with a general summary of all the different graphics components in Android. In my next article I will go into more details about the operation of some of these components. MIPS continues to lead the industry in highly optimized versions of the Android operating system. For more information about Android on MIPS go to http://developer.mips.com or http://www.github.com/mips