Đồ hoạ

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:

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:

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:

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.

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.