![Biểu tượng HAL đồ họa Android](https://source.android.com/static/docs/core/graphics/images/ape-fwk-hal-graphics.png?authuser=7&hl=vi)
Khung Android cung cấp nhiều API kết xuất đồ họa cho 2D và 3D tương tác với việc triển khai trình điều khiển đồ họa của nhà sản xuất, vì vậy điều quan trọng là phải hiểu rõ cách các API đó hoạt động ở cấp độ cao hơn. Trang này giới thiệu lớp trừu tượng phần cứng đồ họa (HAL) mà các trình điều khiển đó được xây dựng trên đó. Trước khi tiếp tục phần này, hãy làm quen với các thuật ngữ sau:
Canvas
(phần tử API)Surface
. Canvas
có các phương pháp để vẽ ảnh bitmap, đường thẳng, hình tròn, hình chữ nhật, văn bản, v.v. trên máy tính tiêu chuẩn và được liên kết với một bitmap hoặc bề mặt. Canvas là cách đơn giản nhất, dễ dàng nhất để vẽ các đối tượng 2D trên màn hình. Lớp cơ sở là Canvas
.android.graphics.drawable
. Để biết thêm thông tin về các tài nguyên có thể vẽ và các tài nguyên khác, hãy xem Tài nguyên .android.opengl
và javax.microedition.khronos.opengles
thể hiện chức năng OpenGL ES.Surface
(phần tử API)Surface
. Sử dụng trực tiếp lớp SurfaceView
thay vì lớp Surface
.SurfaceView
(phần tử API)View
bao bọc một đối tượng Surface
để vẽ và hiển thị các phương thức để xác định kích thước và định dạng của nó một cách linh hoạt. Chế độ xem bề mặt cung cấp cách vẽ độc lập với luồng giao diện người dùng cho các hoạt động sử dụng nhiều tài nguyên, chẳng hạn như trò chơi hoặc xem trước máy ảnh, nhưng kết quả là nó sử dụng thêm bộ nhớ. Chế độ xem bề mặt hỗ trợ cả đồ họa canvas và OpenGL ES. Lớp cơ sở cho đối tượng SurfaceView
là SurfaceView
.R.style
và mở đầu bằng Theme_
.View
(phần tử API)View
là lớp cơ sở cho hầu hết các thành phần bố cục của màn hình hoạt động hoặc hộp thoại, chẳng hạn như hộp văn bản và cửa sổ. Đối tượng View
nhận lệnh gọi từ đối tượng cha của nó (xem ViewGroup
) để tự vẽ và thông báo cho đối tượng cha về kích thước và vị trí ưa thích của nó, những điều này có thể không được cha mẹ tôn trọng. Để biết thêm thông tin, xem View
.ViewGroup
(phần tử API)widget
nhưng mở rộng lớp ViewGroup
.android.widget
.Window
(phần tử API)Window
dùng để chỉ định các thành phần của một cửa sổ chung, chẳng hạn như giao diện, văn bản trên thanh tiêu đề cũng như vị trí và nội dung của menu. Các hộp thoại và hoạt động sử dụng cách triển khai của lớp Window
để hiển thị đối tượng Window
. Bạn không cần triển khai lớp Window
hoặc sử dụng windows trong ứng dụng của mình.Các nhà phát triển ứng dụng vẽ hình ảnh lên màn hình theo ba cách: bằng Canvas , OpenGL ES hoặc Vulkan .
Thành phần đồ họa Android
Bất kể nhà phát triển API kết xuất nào sử dụng, mọi thứ đều được hiển thị trên một bề mặt. Bề mặt đại diện cho phía nhà sản xuất của hàng đợi bộ đệm thường được SurfaceFlinger sử dụng. Mọi cửa sổ được tạo trên nền tảng Android đều được hỗ trợ bởi một bề mặt. Tất cả các bề mặt hiển thị được kết xuất đều được SurfaceFlinger tổng hợp lên màn hình.
Sơ đồ sau đây cho thấy các thành phần chính hoạt động cùng nhau như thế nào:
![thành phần kết xuất hình ảnh](https://source.android.com/static/docs/core/graphics/images/ape-fwk-graphics.png?authuser=7&hl=vi)
Hình 1. Các bề mặt được hiển thị như thế nào.
Các thành phần chính được mô tả dưới đây:
Nhà sản xuất luồng hình ảnh
Nhà sản xuất luồng hình ảnh có thể là bất cứ thứ gì tạo ra bộ đệm đồ họa để sử dụng. Các ví dụ bao gồm bộ giải mã video OpenGL ES, Canvas 2D và mediaserver.
Người tiêu dùng luồng hình ảnh
Ứng dụng sử dụng luồng hình ảnh phổ biến nhất là SurfaceFlinger, dịch vụ hệ thống sử dụng các bề mặt hiện có và tổng hợp chúng lên màn hình bằng cách sử dụng thông tin do Trình quản lý cửa sổ cung cấp. SurfaceFlinger là dịch vụ duy nhất có thể sửa đổi nội dung của màn hình. SurfaceFlinger sử dụng OpenGL và Hardware Composer để tạo một nhóm bề mặt.
Các ứng dụng OpenGL ES khác cũng có thể sử dụng luồng hình ảnh, chẳng hạn như ứng dụng máy ảnh sử dụng luồng hình ảnh xem trước của máy ảnh. Các ứng dụng không phải GL cũng có thể là ứng dụng tiêu dùng, chẳng hạn như lớp ImageReader.
Trình soạn thảo phần cứng
Sự trừu tượng hóa phần cứng cho hệ thống con hiển thị. SurfaceFlinger có thể ủy quyền công việc sáng tác nhất định cho Trình soạn thảo phần cứng để giảm tải công việc từ OpenGL và GPU. SurfaceFlinger hoạt động như một ứng dụng khách OpenGL ES khác. Vì vậy, khi SurfaceFlinger đang tích cực tổng hợp một hoặc hai bộ đệm thành một bộ đệm thứ ba, chẳng hạn, nó đang sử dụng OpenGL ES. Điều này làm cho việc tổng hợp năng lượng thấp hơn so với việc GPU thực hiện mọi tính toán.
Hardware Composer HAL thực hiện nửa còn lại của công việc và là điểm trung tâm cho tất cả kết xuất đồ họa của Android. Trình soạn thảo phần cứng phải hỗ trợ các sự kiện, một trong số đó là VSYNC (một sự kiện khác là hotplug để hỗ trợ HDMI plug-and-play).
Gralloc
Cần có bộ cấp phát bộ nhớ đồ họa (Gralloc) để cấp phát bộ nhớ theo yêu cầu của nhà sản xuất hình ảnh. Để biết chi tiết, xem Gralloc HAL .
Dòng dữ liệu
Xem sơ đồ sau để biết mô tả về quy trình đồ họa của Android:
![luồng dữ liệu đồ họa](https://source.android.com/static/docs/core/graphics/images/graphics-pipeline.png?authuser=7&hl=vi)
Hình 2. Luồng dữ liệu đồ họa qua Android
Các đối tượng bên trái là các trình kết xuất tạo bộ đệm đồ họa, chẳng hạn như màn hình chính, thanh trạng thái và giao diện người dùng hệ thống. SurfaceFlinger là nhà soạn nhạc và Hardware Composer là nhà soạn nhạc.
Hàng đợi đệm
BufferQueues cung cấp chất kết dính giữa các thành phần đồ họa Android. Đây là một cặp hàng đợi làm trung gian cho chu kỳ đệm liên tục từ nhà sản xuất đến người tiêu dùng. Sau khi nhà sản xuất chuyển giao bộ đệm của họ, SurfaceFlinger chịu trách nhiệm tổng hợp mọi thứ trên màn hình.
Xem sơ đồ sau để biết quy trình giao tiếp BufferQueue.
![Quá trình giao tiếp BufferQueue](https://source.android.com/static/docs/core/graphics/images/bufferqueue.png?authuser=7&hl=vi)
Hình 3. Quá trình giao tiếp BufferQueue
BufferQueue chứa logic liên kết các nhà sản xuất luồng hình ảnh và người tiêu dùng luồng hình ảnh với nhau. Một số ví dụ về nhà sản xuất hình ảnh là các bản xem trước máy ảnh do trò chơi HAL hoặc OpenGL ES của máy ảnh tạo ra. Một số ví dụ về người sử dụng hình ảnh là SurfaceFlinger hoặc một ứng dụng khác hiển thị luồng OpenGL ES, chẳng hạn như ứng dụng máy ảnh hiển thị kính ngắm máy ảnh.
BufferQueue là cấu trúc dữ liệu kết hợp vùng đệm với hàng đợi và sử dụng Binder IPC để chuyển vùng đệm giữa các tiến trình. Giao diện của nhà sản xuất hoặc những gì bạn chuyển cho ai đó muốn tạo bộ đệm đồ họa là IGraphicBufferProducer (một phần của SurfaceTexture ). BufferQueue thường được sử dụng để hiển thị trên Surface và sử dụng với GL Consumer, cùng với các tác vụ khác.
BufferQueue có thể hoạt động ở ba chế độ khác nhau:
Chế độ giống đồng bộ - BufferQueue theo mặc định hoạt động ở chế độ giống đồng bộ, trong đó mọi bộ đệm đến từ nhà sản xuất sẽ đi ra ngoài ở người tiêu dùng. Không có bộ đệm nào bị loại bỏ trong chế độ này. Và nếu nhà sản xuất quá nhanh và tạo ra bộ đệm nhanh hơn mức chúng bị cạn kiệt, nó sẽ chặn và chờ bộ đệm miễn phí.
Chế độ không chặn - BufferQueue cũng có thể hoạt động ở chế độ không chặn trong đó nó tạo ra lỗi thay vì chờ bộ đệm trong những trường hợp đó. Không có bộ đệm nào bị loại bỏ trong chế độ này. Điều này rất hữu ích để tránh những bế tắc tiềm ẩn trong phần mềm ứng dụng có thể không hiểu được sự phụ thuộc phức tạp của khung đồ họa.
Chế độ loại bỏ - Cuối cùng, BufferQueue có thể được cấu hình để loại bỏ bộ đệm cũ thay vì tạo ra lỗi hoặc chờ đợi. Ví dụ: nếu tiến hành kết xuất GL sang chế độ xem kết cấu và vẽ càng nhanh càng tốt, bộ đệm phải bị loại bỏ.
Để thực hiện hầu hết công việc này, SurfaceFlinger hoạt động như một ứng dụng khách OpenGL ES khác. Vì vậy, khi SurfaceFlinger đang tích cực tổng hợp một hoặc hai bộ đệm thành một bộ đệm thứ ba, chẳng hạn, nó đang sử dụng OpenGL ES.
Nhà soạn nhạc phần cứng HAL thực hiện nửa công việc còn lại. HAL này đóng vai trò là điểm trung tâm cho tất cả kết xuất đồ họa của Android.