Kể từ ngày 27 tháng 3 năm 2025, bạn nên sử dụng android-latest-release
thay vì aosp-main
để xây dựng và đóng góp cho AOSP. Để biết thêm thông tin, hãy xem phần Thay đổi đối với AOSP.
HAL của Trình soạn nhạc phần cứng
Sử dụng bộ sưu tập để sắp xếp ngăn nắp các trang Lưu và phân loại nội dung dựa trên lựa chọn ưu tiên của bạn.
HAL của Trình tổng hợp phần cứng (HWC) xác định cách hiệu quả nhất để kết hợp vùng đệm với phần cứng hiện có. Là một HAL, cách triển khai của HAL này là dành riêng cho thiết bị và thường do nhà sản xuất thiết bị gốc (OEM) phần cứng hiển thị thực hiện.
Bạn có thể dễ dàng nhận ra giá trị của phương pháp này khi xem xét các lớp phủ. Lớp phủ này kết hợp nhiều vùng đệm trong phần cứng hiển thị thay vì GPU. Ví dụ: hãy xem xét một điện thoại Android thông thường theo hướng dọc, với thanh trạng thái ở trên cùng, thanh điều hướng ở dưới cùng và nội dung ứng dụng ở mọi nơi khác. Nội dung của mỗi lớp nằm trong các vùng đệm riêng biệt. Bạn có thể xử lý thành phần bằng một trong các phương thức sau:
- Kết xuất nội dung ứng dụng vào vùng đệm tạm thời, sau đó kết xuất thanh trạng thái lên trên, thanh điều hướng ở trên cùng và cuối cùng là truyền vùng đệm tạm thời đến phần cứng hiển thị.
- Truyền cả ba vùng đệm đến phần cứng hiển thị và hướng dẫn phần cứng này đọc dữ liệu từ các vùng đệm khác nhau cho các phần khác nhau của màn hình.
Phương pháp sau có thể hiệu quả hơn đáng kể.
Các tính năng của bộ xử lý hiển thị có thể khác nhau đáng kể. Số lớp phủ, liệu các lớp có thể xoay hay kết hợp hay không, cũng như các quy tắc hạn chế về vị trí và lớp phủ có thể khó thể hiện thông qua API. Để đáp ứng các tuỳ chọn này, HWC thực hiện các phép tính sau:
- SurfaceFlinger cung cấp cho HWC danh sách đầy đủ các lớp và hỏi: "Bạn muốn xử lý việc này như thế nào?"
- HWC phản hồi bằng cách đánh dấu từng lớp là thành phần thiết bị hoặc ứng dụng.
- SurfaceFlinger sẽ xử lý mọi ứng dụng, truyền vùng đệm đầu ra đến HWC và để HWC xử lý phần còn lại.
Vì các nhà cung cấp phần cứng có thể tuỳ chỉnh mã ra quyết định, nên bạn có thể đạt được hiệu suất tốt nhất trên mọi thiết bị.
Các lớp phủ có thể kém hiệu quả hơn so với thành phần GL khi không có gì trên màn hình thay đổi. Điều này đặc biệt đúng khi nội dung lớp phủ có pixel trong suốt và các lớp chồng chéo được kết hợp. Trong những trường hợp như vậy, HWC có thể yêu cầu thành phần GLES cho một số hoặc tất cả các lớp và giữ lại vùng đệm tổng hợp. Nếu SurfaceFlinger yêu cầu kết hợp cùng một bộ đệm, thì HWC có thể hiển thị bộ đệm ghi tạm đã kết hợp trước đó. Điều này có thể cải thiện thời lượng pin của thiết bị ở trạng thái rảnh.
Các thiết bị Android thường hỗ trợ 4 lớp phủ. Việc cố gắng kết hợp nhiều lớp hơn lớp phủ sẽ khiến hệ thống sử dụng thành phần GLES cho một số lớp, nghĩa là số lớp mà ứng dụng sử dụng có thể ảnh hưởng đáng kể đến mức tiêu thụ điện năng và hiệu suất.
Nội dung và mã mẫu trên trang này phải tuân thủ các giấy phép như mô tả trong phần Giấy phép nội dung. Java và OpenJDK là nhãn hiệu hoặc nhãn hiệu đã đăng ký của Oracle và/hoặc đơn vị liên kết của Oracle.
Cập nhật lần gần đây nhất: 2025-07-27 UTC.
[[["Dễ hiểu","easyToUnderstand","thumb-up"],["Giúp tôi giải quyết được vấn đề","solvedMyProblem","thumb-up"],["Khác","otherUp","thumb-up"]],[["Thiếu thông tin tôi cần","missingTheInformationINeed","thumb-down"],["Quá phức tạp/quá nhiều bước","tooComplicatedTooManySteps","thumb-down"],["Đã lỗi thời","outOfDate","thumb-down"],["Vấn đề về bản dịch","translationIssue","thumb-down"],["Vấn đề về mẫu/mã","samplesCodeIssue","thumb-down"],["Khác","otherDown","thumb-down"]],["Cập nhật lần gần đây nhất: 2025-07-27 UTC."],[],[],null,["# Hardware Composer HAL\n\nThe Hardware Composer (HWC) HAL determines the most efficient\nway to composite buffers with the available hardware. As a HAL, its\nimplementation is device-specific and usually done by the display hardware OEM.\n\nThe value of this approach is easy to recognize when you consider *overlay\nplanes*, which composite multiple buffers in\nthe display hardware rather than the GPU. For example, consider a typical\nAndroid phone in portrait orientation, with the status bar on top, navigation\nbar at the bottom, and app content everywhere else. The contents for each layer\nare in separate buffers. You can handle composition using either of the\nfollowing methods:\n\n- Rendering the app content into a scratch buffer, then rendering the status bar over it, the navigation bar on top of that, and finally passing the scratch buffer to the display hardware.\n- Passing all three buffers to the display hardware and instructing it to read data from different buffers for different parts of the screen.\n\nThe latter approach can be significantly more efficient.\n\nDisplay processor capabilities vary significantly. The number of overlays,\nwhether layers can be rotated or blended, and restrictions on positioning and\noverlap can be difficult to express through an API. To accommodate these options, the HWC performs\nfollowing calculations:\n\n1. SurfaceFlinger provides HWC with a full list of layers and asks, \"How do you want to handle this?\"\n2. HWC responds by marking each layer as device or client composition.\n3. SurfaceFlinger takes care of any client, passing the output buffer to HWC, and lets HWC handle the rest.\n\nBecause hardware vendors can custom tailor decision-making code, it's possible\nto get the best performance out of every device.\n\nOverlay planes may be less efficient than GL composition when nothing on the\nscreen is changing. This is particularly true when overlay contents have\ntransparent pixels and overlapping layers are blended. In such cases,\nthe HWC can request GLES composition for some or all layers and retain\nthe composited buffer. If SurfaceFlinger asks to composite the same\nset of buffers, the HWC can show the previously composited scratch\nbuffer. This can improve the battery life of an idle device.\n\nAndroid devices typically support four overlay planes.\nAttempting to composite more layers than overlays causes the system to use GLES\ncomposition for some of them, meaning the number of layers used by an app can\nhave a measurable impact on power consumption and performance."]]