Google berkomitmen untuk mendorong terwujudnya keadilan ras bagi komunitas Kulit Hitam. Lihat caranya.

Halaman ini diterjemahkan oleh Cloud Translation API.

Beberapa Tingkat Penyegaran

Android 11 menambahkan dukungan untuk perangkat dengan beberapa kecepatan refresh. Ada tiga komponen utama untuk fitur ini:

API HAL baru diperkenalkan di android.hardware.graphics.composer@2.4 .
Kode platform untuk mengurai konfigurasi perangkat untuk kecepatan refresh yang berbeda dan mengatur kecepatan refresh yang diinginkan
SDK dan NDK API baru untuk memungkinkan aplikasi menyetel frekuensi gambar yang diinginkan

Penerapan

Dukungan khusus untuk peralihan kecepatan refresh telah ditambahkan ke android.hardware.graphics.composer@2.4 HAL . Kami sangat menyarankan menggunakan versi ini karena versi komposer HAL sebelumnya memiliki dukungan terbatas untuk peralihan kecepatan refresh.

Grup konfigurasi

Atribut baru CONFIG_GROUP telah ditambahkan ke IComposerClient::Attribute yang dapat ditanyakan menggunakan getDisplayAttribute_2_4 API. Atribut ini memungkinkan vendor untuk mengelompokkan konfigurasi tampilan. Konfigurasi dalam grup yang sama memungkinkan peralihan tanpa hambatan di antara mereka di sebagian besar kasus. Grup konfigurasi digunakan oleh platform untuk membedakan konfigurasi mana yang dapat dialihkan di antara mereka untuk mengubah kecepatan refresh dan bukan atribut lain untuk konfigurasi.

Pertimbangkan contoh berikut yang menunjukkan manfaat menggunakan grup konfigurasi dengan perangkat yang mendukung empat konfigurasi tampilan:

1080p@60Hz
1080p@90Hz
1080i@72Hz
1080i@48Hz

Meskipun perangkat mendukung kecepatan refresh 48Hz, 60Hz, 72Hz, dan 90Hz, layar beroperasi pada mode yang berbeda dan beralih dari 60Hz ke 72Hz mengubah konfigurasi tampilan dari 1080p ke 1080i, yang mungkin bukan perilaku yang diinginkan. Ini diselesaikan dengan menggunakan grup konfigurasi. Dengan mengelompokkan 60Hz dan 90Hz bersama-sama dalam satu grup konfigurasi dan 48Hz dan 72Hz dalam grup konfigurasi lainnya. Platform tahu bahwa itu dapat beralih antara 60Hz dan 90Hz dan antara 48Hz dan 72Hz tetapi tidak antara 60Hz dan 72Hz karena ini akan menghasilkan perubahan konfigurasi daripada hanya mengubah kecepatan refresh.

Pembaruan API Komposer

getDisplayVsyncPeriod

Untuk kontrol dan prediktabilitas yang lebih baik saat mengubah kecepatan refresh getDisplayVsyncPeriod telah ditambahkan. getDisplayVsyncPeriod mengembalikan kecepatan refresh saat ini (dalam hal periode vsync) saat layar beroperasi. Ini sangat berguna saat transisi antara kecepatan refresh dan kecepatan refresh saat ini diperlukan oleh platform untuk memutuskan kapan memulai frame berikutnya.

setActiveConfigWithConstraints

Metode setActiveConfigWithConstraints adalah ekstensi baru untuk metode setActiveConfig yang ada dan memberikan informasi lebih lanjut tentang perubahan konfigurasi. Batasan diberikan sebagai bagian dari parameter vsyncPeriodChangeConstraints dan berisi parameter berikut.

waktu yang diinginkanNanos

Waktu dalam CLOCK_MONOTONIC setelah periode vsync dapat berubah (yaitu periode vsync tidak boleh berubah sebelum waktu ini). Ini berguna ketika platform ingin merencanakan ke depan untuk perubahan kecepatan refresh tetapi sudah memiliki beberapa buffer dalam antrian untuk disajikan. Platform menetapkan waktu ini sesuai untuk memperhitungkan buffer tersebut dan memastikan bahwa transisi kecepatan refresh akan semulus mungkin.

mulusDiperlukan

Jika benar, mengharuskan perubahan periode vsync harus terjadi dengan mulus tanpa artefak visual yang terlihat. Bendera ini digunakan oleh platform saat perubahan kecepatan refresh diperlukan sebagai akibat dari perubahan konten (misalnya, perangkat dalam keadaan diam dan animasi dimulai). Ini memberi vendor kesempatan untuk tidak mengizinkan perubahan konfigurasi tertentu ketika mereka dapat menghasilkan artefak visual yang nyata. Jika konfigurasi tidak dapat diubah dengan mulus dan seamlessRequired disetel ke true , implementasi diharapkan mengembalikan SEAMLESS_NOT_POSSIBLE sebagai kode pengembalian dan memanggil callback onSeamlessPossible yang baru ketika perubahan konfigurasi yang sama dapat dilakukan dengan mulus.

Setelah berhasil, implementasi mengembalikan VsyncPeriodChangeTimeline yang memberi tahu platform kapan harus mengharapkan perubahan kecepatan refresh terjadi. parameter newVsyncAppliedTimeNanos perlu disetel ke waktu di CLOCK_MONOTONIC saat tampilan baru akan mulai disegarkan pada periode vsync baru. Ini, bersama dengan desiredTimeNanos yang diinginkan memungkinkan platform untuk merencanakan terlebih dahulu sakelar kecepatan penyegaran dan mulai mencentang aplikasi untuk kecepatan penyegaran baru terlebih dahulu. Ini memungkinkan transisi kecepatan refresh yang mulus.

Beberapa implementasi memerlukan bingkai penyegaran untuk dikirim sebelum kecepatan penyegaran dapat dikirim. Untuk itu, HAL memiliki parameter refreshRequired untuk menunjukkan bahwa bingkai penyegaran diperlukan dan refreshTimeNanos untuk menunjukkan vsync pertama di mana bingkai penyegaran perlu dikirim setelahnya.

onVsyncPeriodTimingChanged [panggilan balik]

Panggilan balik baru yang dapat dipanggil oleh HAL untuk menunjukkan ke platform bahwa beberapa parameter timeline berubah dan platform perlu menyesuaikan timeline-nya. Panggilan balik ini diharapkan akan dipanggil jika karena alasan tertentu garis waktu lama terlewatkan karena waktu pemrosesan yang lama pada HAL atau bingkai penyegaran yang terlambat.

Bagaimana platform memutuskan untuk mengubah kecepatan refresh?

Pemilihan kecepatan refresh terjadi di dua layanan sistem berikut:

Manajer Tampilan: DisplayManager menetapkan kebijakan tingkat tinggi seputar kecepatan refresh. Ini menetapkan konfigurasi tampilan default, yang sama dengan konfigurasi HAL komposer. Selain itu, ini menetapkan rentang nilai minimum dan maksimum untuk dipilih SurfaceFlinger sebagai kecepatan refresh.
SurfaceFlinger: Menentukan kecepatan refresh dengan menyetel konfigurasi yang berada dalam grup konfigurasi yang sama dengan konfigurasi default dan dengan kecepatan refresh dalam rentang min/maks.

Manajer Tampilan menjalankan langkah-langkah berikut untuk menentukan kebijakan:

Menemukan ID konfigurasi default dengan menanyakan konfigurasi aktif dari SurfaceFlinger
Membatasi rentang nilai minimum dan maksimum dengan mengulangi kondisi sistem
- Pengaturan kecepatan refresh default : Nilai kecepatan refresh default diatur dalam overlay konfigurasi R.integer.config_defaultRefreshRate . Nilai ini digunakan untuk menentukan kecepatan refresh perangkat standar untuk animasi dan interaksi sentuh.
- Pengaturan kecepatan refresh puncak: Nilai kecepatan refresh puncak dibaca dari Settings.System.PEAK_REFRESH_RATE . Nilai ini diubah dalam waktu proses untuk mencerminkan pengaturan perangkat saat ini (seperti dari opsi menu). Nilai default diatur dalam overlay konfigurasi R.integer.config_defaultPeakRefreshRate .
- Pengaturan kecepatan refresh minimum : Nilai kecepatan refresh minimum dibaca dari Settings.System.MIN_REFRESH_RATE . Nilai ini dapat diubah dalam waktu proses untuk mencerminkan pengaturan perangkat saat ini (seperti dari opsi menu). Nilai defaultnya adalah 0, jadi tidak ada minimum default.
- ModeId yang diminta aplikasi : Aplikasi dapat mengatur WindowManager.LayoutParams.preferredDisplayModeId untuk mencerminkan konfigurasi pilihan yang harus dioperasikan oleh tampilan. Dalam sebagian besar kondisi, DisplayManager menetapkan ID konfigurasi default yang sesuai dan menetapkan kecepatan refresh minimum dan maksimum agar sesuai dengan kecepatan refresh konfigurasi.
- Penghemat Baterai : Kecepatan refresh dibatasi hingga 60Hz atau lebih rendah saat perangkat dalam mode daya rendah, yang ditunjukkan melalui Settings.Global.LOW_POWER_MODE.

Setelah DisplayManager menetapkan kebijakan, SurfaceFlinger menetapkan kecepatan refresh berdasarkan lapisan aktif (lapisan yang mengantre pembaruan bingkai). Jika pemilik lapisan menyetel laju bingkai , SurfaceFlinger mencoba menyetel laju penyegaran ke sesuatu yang merupakan pengganda dari laju tersebut. Misalnya jika dua lapisan aktif mengatur kecepatan bingkai ke 24 dan 60 SurfaceFlinger akan memilih 120Hz jika tersedia. Jika kecepatan refresh tersebut tidak tersedia untuk SurfaceFlinger, itu akan mencoba untuk memilih kecepatan refresh yang memiliki kesalahan minimal untuk frame rate. Untuk informasi lebih lanjut, lihat dokumentasi pengembang di developer.android.com

SurfaceFlinger mempertahankan flag berikut untuk mengontrol bagaimana kecepatan refresh ditentukan:

ro.surface_flinger.use_content_detection_for_refresh_rate: Jika disetel, kecepatan refresh ditentukan berdasarkan lapisan aktif, bahkan jika kecepatan bingkai tidak disetel. SurfaceFlinger mempertahankan heuristik di mana ia menemukan fps rata-rata lapisan memposting buffer dengan melihat stempel waktu presentasi yang dilampirkan ke buffer.
ro.surface_flinger.set_touch_timer_ms : jika > 0, kecepatan refresh default akan digunakan saat pengguna menyentuh layar untuk batas waktu yang dikonfigurasi. Heuristik ini dilakukan agar siap dengan kecepatan refresh default untuk animasi.
ro.surface_flinger.set_idle_timer_ms : jika > 0, kecepatan refresh min akan digunakan ketika tidak ada pembaruan layar untuk batas waktu yang dikonfigurasi.
ro.surface_flinger.set_display_power_timer_ms : jika > 0, kecepatan refresh default akan digunakan saat menghidupkan tampilan (atau saat keluar dari AOD) untuk batas waktu yang dikonfigurasi.

API Kecepatan Bingkai

API kecepatan bingkai memungkinkan aplikasi memberi tahu platform Android tentang kecepatan bingkai yang diinginkan dan tersedia di aplikasi yang menargetkan Android 11. Untuk mempelajari lebih lanjut tentang API kecepatan bingkai, lihat dokumentasi pengembang di developer.android.com .

Opsi pengembang

Opsi pengembang baru telah ditambahkan ke menu yang mengaktifkan overlay pada tampilan dengan kecepatan refresh saat ini. Opsi baru ada di bawah Pengaturan > Sistem > Opsi pengembang > Tampilkan kecepatan penyegaran.