Nhiều tốc độ làm mới

Android 11 bổ sung tính năng hỗ trợ cho các thiết bị có nhiều tốc độ làm mới. Tính năng này có 3 thành phần chính:

  • Các API HAL mới được giới thiệu trong android.hardware.graphics.composer@2.4.
  • Mã nền tảng để phân tích cú pháp cấu hình thiết bị cho các tốc độ làm mới khác nhau và đặt tốc độ làm mới mong muốn
  • SDK và API NDK mới cho phép các ứng dụng đặt tốc độ khung hình mong muốn

Triển khai

Chúng tôi đã thêm tính năng hỗ trợ chuyên biệt cho việc chuyển đổi tốc độ làm mới vào android.hardware.graphics.composer@2.4 HAL. Bạn nên sử dụng phiên bản này vì các phiên bản trước của composer HAL có giới hạn về khả năng hỗ trợ chuyển đổi tốc độ làm mới.

Nhóm cấu hình

Một thuộc tính mới CONFIG_GROUP đã được thêm vào IComposerClient::Attribute có thể truy vấn bằng API getDisplayAttribute_2_4. Thuộc tính này cho phép nhà cung cấp nhóm các cấu hình màn hình với nhau. Các cấu hình trong cùng một nhóm cho phép chuyển đổi liền mạch giữa các cấu hình trong hầu hết các trường hợp. Nền tảng dùng nhóm cấu hình để phân biệt những cấu hình có thể chuyển đổi giữa chúng nhằm chuyển đổi tốc độ làm mới chứ không phải các thuộc tính khác cho một cấu hình.

Hãy xem xét ví dụ sau đây minh hoạ lợi ích của việc sử dụng các nhóm cấu hình với một thiết bị hỗ trợ 4 cấu hình màn hình:

  • 1080p ở tốc độ 60 Hz
  • 1080p ở tốc độ 90 Hz
  • 1080i ở tốc độ 72 Hz
  • 1080i ở tốc độ 48 Hz

Mặc dù thiết bị hỗ trợ tốc độ làm mới 48 Hz, 60 Hz, 72 Hz và 90 Hz, nhưng màn hình hoạt động ở một chế độ khác và việc chuyển từ 60 Hz sang 72 Hz sẽ thay đổi cấu hình màn hình từ 1080p thành 1080i, điều này có thể không phải là hành vi mong muốn. Bạn có thể giải quyết vấn đề này bằng cách sử dụng nhóm cấu hình. Bằng cách nhóm 60 Hz và 90 Hz vào một nhóm cấu hình và 48 Hz và 72 Hz vào một nhóm cấu hình khác. Nền tảng này biết rằng có thể chuyển đổi giữa 60 Hz và 90 Hz, cũng như giữa 48 Hz và 72 Hz nhưng không thể chuyển đổi giữa 60 Hz và 72 Hz vì điều này sẽ dẫn đến thay đổi về cấu hình thay vì chỉ thay đổi tốc độ làm mới.

Nội dung cập nhật về Composer API

getDisplayVsyncPeriod
Để kiểm soát và dự đoán tốt hơn khi thay đổi tốc độ làm mới, getDisplayVsyncPeriod đã được thêm vào. getDisplayVsyncPeriod trả về tốc độ làm mới hiện tại (theo chu kỳ vsync) mà màn hình hoạt động. Điều này đặc biệt hữu ích trong khi chuyển đổi giữa tốc độ làm mới và tốc độ làm mới hiện tại mà nền tảng cần để quyết định thời điểm bắt đầu khung hình tiếp theo.
setActiveConfigWithConstraints
Phương thức setActiveConfigWithConstraints là một tiện ích mới cho phương thức setActiveConfig hiện có và cung cấp thêm thông tin về thay đổi cấu hình. Các giới hạn được đưa ra trong các tham số vsyncPeriodChangeConstraints và chứa các tham số sau.
    desiredTimeNanos
    Thời gian trong CLOCK_MONOTONIC sau đó khoảng thời gian đồng bộ hoá dọc có thể thay đổi (tức là khoảng thời gian đồng bộ hoá dọc không được thay đổi trước thời gian này). Điều này hữu ích khi nền tảng muốn lên kế hoạch trước cho việc thay đổi tốc độ làm mới nhưng đã có một số vùng đệm trong hàng đợi để trình bày. Nền tảng sẽ đặt thời gian này cho phù hợp để tính đến các vùng đệm đó và đảm bảo quá trình chuyển đổi tốc độ làm mới diễn ra mượt mà nhất có thể.
    seamlessRequired
    Nếu đúng, yêu cầu thay đổi khoảng thời gian đồng bộ hoá dọc phải diễn ra liền mạch mà không có hiện tượng giả tạo về hình ảnh đáng chú ý. Nền tảng sử dụng cờ này khi cần thay đổi tốc độ làm mới do nội dung thay đổi (ví dụ: thiết bị đang ở trạng thái chờ và bắt đầu tạo ảnh động). Điều này cho phép nhà cung cấp không cho phép một số thay đổi về cấu hình khi những thay đổi đó có thể dẫn đến một hiện tượng giả lập hình ảnh đáng chú ý. Nếu không thể thay đổi các cấu hình một cách liền mạch và seamlessRequired được đặt thành true, thì quá trình triển khai dự kiến sẽ trả về SEAMLESS_NOT_POSSIBLE làm mã trả về và gọi lệnh gọi lại onSeamlessPossible mới khi có thể thực hiện cùng một thay đổi về cấu hình một cách liền mạch.

Khi thành công, quá trình triển khai sẽ trả về một VsyncPeriodChangeTimeline cho biết thời điểm nền tảng dự kiến sẽ xảy ra thay đổi về tốc độ làm mới. Bạn cần đặt các tham số newVsyncAppliedTimeNanos thành thời gian trong CLOCK_MONOTONIC khi màn hình mới bắt đầu làm mới ở khoảng thời gian đồng bộ hoá dọc mới. Cùng với desiredTimeNanos, điều này cho phép nền tảng lên kế hoạch trước cho việc chuyển đổi tốc độ làm mới và bắt đầu đánh dấu các ứng dụng cho tốc độ làm mới mới từ trước. Điều này cho phép chuyển đổi tốc độ làm mới một cách liền mạch.

Một số cách triển khai yêu cầu gửi khung làm mới trước khi có thể gửi tốc độ làm mới. Để làm việc đó, HAL có tham số refreshRequired để cho biết cần có khung hình làm mới và refreshTimeNanos để cho biết vsync đầu tiên mà sau đó cần gửi khung hình làm mới.

onVsyncPeriodTimingChanged [callback]
Một lệnh gọi lại mới mà HAL có thể gọi để cho nền tảng biết rằng một số tham số của dòng thời gian đã thay đổi và nền tảng cần điều chỉnh dòng thời gian của mình. Lệnh gọi lại này dự kiến sẽ được gọi nếu vì lý do nào đó mà dòng thời gian cũ bị bỏ lỡ do thời gian xử lý dài trên HAL hoặc khung làm mới muộn.

Nền tảng quyết định thay đổi tốc độ làm mới như thế nào?

Việc chọn tốc độ làm mới diễn ra trong 2 dịch vụ hệ thống sau:

DisplayManager
DisplayManager đặt chính sách cấp cao về tốc độ làm mới. Thao tác này sẽ đặt một cấu hình hiển thị mặc định, giống như cấu hình HAL của trình kết hợp. Ngoài ra, nó đặt một phạm vi giá trị tối thiểu và tối đa cho SurfaceFlinger để chọn làm tốc độ làm mới.
SurfaceFlinger
Xác định tốc độ làm mới bằng cách đặt một cấu hình nằm trong cùng một nhóm cấu hình với cấu hình mặc định và có tốc độ làm mới nằm trong phạm vi tối thiểu/tối đa.

Display Manager sẽ thực hiện các bước sau để xác định chính sách:

  • Tìm mã nhận dạng cấu hình mặc định bằng cách truy vấn cấu hình đang hoạt động từ SurfaceFlinger
  • Hạn chế phạm vi giá trị tối thiểu và tối đa bằng cách lặp lại các điều kiện hệ thống
    • Chế độ cài đặt tốc độ làm mới mặc định: Giá trị tốc độ làm mới mặc định được đặt trong lớp phủ cấu hình R.integer.config_defaultRefreshRate. Giá trị này được dùng để xác định tốc độ làm mới thiết bị tiêu chuẩn cho các ảnh động và lượt tương tác bằng cách chạm.
    • Chế độ cài đặt tốc độ làm mới cao nhất: Giá trị tốc độ làm mới cao nhất được đọc từ Settings.System.PEAK_REFRESH_RATE. Giá trị này sẽ thay đổi trong thời gian chạy để phản ánh chế độ cài đặt hiện tại của thiết bị (chẳng hạn như từ một lựa chọn trong trình đơn). Giá trị mặc định được đặt trong lớp phủ cấu hình R.integer.config_defaultPeakRefreshRate.
    • Chế độ cài đặt tốc độ làm mới tối thiểu: Giá trị tốc độ làm mới tối thiểu được đọc từ Settings.System.MIN_REFRESH_RATE. Bạn có thể thay đổi giá trị này trong thời gian chạy để phản ánh chế độ cài đặt hiện tại của thiết bị (chẳng hạn như từ một lựa chọn trong trình đơn). Giá trị mặc định là 0, nên không có giá trị tối thiểu mặc định.
    • Ứng dụng yêu cầu ModeId: Ứng dụng có thể đặt WindowManager.LayoutParams.preferredDisplayModeId để phản ánh cấu hình ưu tiên mà màn hình sẽ hoạt động. Trong hầu hết các điều kiện, DisplayManager sẽ đặt mã cấu hình mặc định cho phù hợp và đặt tốc độ làm mới tối thiểu và tối đa sao cho phù hợp với tốc độ làm mới của cấu hình.
    • Trình tiết kiệm pin: Tốc độ làm mới bị giới hạn ở mức 60 Hz hoặc thấp hơn khi thiết bị ở chế độ nguồn điện thấp, được biểu thị bằng biểu tượng Settings.Global.LOW_POWER_MODE.

Sau khi DisplayManager đặt chính sách, SurfaceFlinger sẽ đặt tốc độ làm mới dựa trên các lớp đang hoạt động (các lớp xếp hàng cập nhật khung hình). Nếu chủ sở hữu của lớp đặt tốc độ khung hình, SurfaceFlinger sẽ cố gắng đặt tốc độ làm mới thành một giá trị là bội số của tốc độ đó. Ví dụ: nếu 2 lớp đang hoạt động đặt tốc độ khung hình thành 24 và 60, thì SurfaceFlinger sẽ chọn 120 Hz nếu có. Nếu SurfaceFlinger không có tốc độ làm mới như vậy, thì tốc độ này sẽ cố gắng chọn tốc độ làm mới có lỗi tối thiểu cho tốc độ khung hình. Để biết thêm thông tin, hãy xem tài liệu dành cho nhà phát triển trên developer.android.com

SurfaceFlinger duy trì các cờ sau để kiểm soát cách quyết định tốc độ làm mới:

  • ro.surface_flinger.use_content_detection_for_refresh_rate: Nếu bạn đặt tốc độ làm mới, tốc độ này sẽ được quyết định dựa trên các lớp đang hoạt động, ngay cả khi bạn chưa đặt tốc độ khung hình. SurfaceFlinger duy trì một phương pháp phỏng đoán, trong đó phương pháp này tìm ra tốc độ khung hình trung bình mà lớp đang đăng các vùng đệm bằng cách xem dấu thời gian trình bày được đính kèm vào vùng đệm.
  • ro.surface_flinger.set_touch_timer_ms: nếu > 0, tốc độ làm mới mặc định sẽ được dùng khi người dùng chạm vào màn hình trong thời gian chờ đã định cấu hình. Heuristic này được thực hiện để sẵn sàng với tốc độ làm mới mặc định cho ảnh động.
  • ro.surface_flinger.set_idle_timer_ms: nếu > 0, tốc độ làm mới tối thiểu sẽ được dùng khi không có bản cập nhật màn hình nào trong thời gian chờ đã định cấu hình.
  • ro.surface_flinger.set_display_power_timer_ms: nếu > 0, tốc độ làm mới mặc định sẽ được dùng khi bật màn hình (hoặc khi thoát khỏi chế độ AOD) trong khoảng thời gian chờ đã định cấu hình.

Frame Rate API

API tốc độ khung hình cho phép các ứng dụng thông báo cho nền tảng Android về tốc độ khung hình dự kiến và có sẵn trên các ứng dụng nhắm đến Android 11. Để tìm hiểu thêm về API tốc độ khung hình, hãy xem tài liệu dành cho nhà phát triển trên developer.android.com.

Tuỳ chọn cho nhà phát triển

Một lựa chọn mới dành cho nhà phát triển đã được thêm vào trình đơn để bật/tắt lớp phủ trên màn hình với tốc độ làm mới hiện tại. Lựa chọn mới này nằm trong phần Cài đặt > Hệ thống > Tuỳ chọn cho nhà phát triển > Hiện tốc độ làm mới.