1. Soalan dan Konteks
Soalan ini menguji prestasi frontend dan asas pelayar web. Sebuah halaman mengendalikan input, tatalan, dan animasi di samping memproses analitik, pengiraan keutamaan rendah, atau kerja yang ditangguhkan. Terangkan perkara yang diselesaikan oleh fungsi panggilan balik melahu (idle callbacks), cara mengelakkan penantian tanpa had, dan sebab komit DOM biasanya tergolong dalam requestAnimationFrame.
2. Perkara yang Dinilai oleh Penemu Duga
- Sama ada anda memahami bahawa
requestIdleCallbackmenjadualkan kerja berkeutamaan rendah semasa tempoh melahu pelayar; ia tidak memintas (preempt) benang utama. - Sama ada anda menggunakan
IdleDeadline.timeRemaining()untuk pemecahan kerja (chunks) dan menetapkantimeoutapabila kerja mempunyai tarikh akhir. - Sama ada anda menyedari sokongan pelayar yang terhad dan mereka bentuk pengesanan keupayaan dengan semantik sandaran (fallback) yang jelas.
- Sama ada anda mengasingkan pengiraan, penghantaran rangkaian, mutasi DOM, dan pemasaan animasi, kemudian mengukur kesan terhadap interaksi.
Panduan temu duga frontend Coursera menyenaraikan pengoptimuman prestasi, metrik pengeluaran, dan pertukaran kompromi (trade-offs) sebagai bidang penilaian teras. MDN menerangkan requestIdleCallback() sebagai kerja latar belakang semasa tempoh melahu; pilihan timeout miliknya boleh menghalang kerja yang diperlukan daripada menunggu terlalu lama tetapi boleh menjejaskan interaksi. Contoh rasmi Chrome seterusnya mengasingkan pengiraan melahu daripada kemas kini DOM dalam bingkai berikutnya.
3. Soalan Penjelasan Sebelum Anda Menjawab
- Bolehkah kerja tersebut ditangguhkan? Apakah tarikh akhir yang dikenakan pada kelompok analitik, prefetching, dan maklum balas pengguna yang diperlukan?
- Adakah panggilan balik tersebut akan mengubah DOM, mengemas kini keadaan, menulis storan, atau hanya menghantar permintaan rangkaian?
- Adakah pelayar sasaran menyokong API ini? Jika tidak, adakah kerja itu patut ditangguhkan, dijalankan serta-merta, atau digugurkan?
- Metrik manakah yang dilindungi: kelewatan input (input delay), tugasan panjang (long tasks), kelancaran animasi, atau penghantaran analitik?
4. Rangka Kerja Jawapan 30 Saat
Saya akan mengklasifikasikan kerja sebagai boleh digugurkan, boleh ditangguhkan, atau diperlukan. Bagi pengiraan kecil bukan kritikal atau giliran penghantaran, saya akan menggunakan requestIdleCallback dalam belanjawan timeRemaining() yang tersedia dan menambah timeout hanya apabila tarikh akhir adalah penting. Panggilan balik akan menyediakan data dan bukannya melakukan mutasi DOM yang tidak dapat diramalkan; requestAnimationFrame berikutnya akan melakukan komit terhadap perubahan yang kelihatan. Saya akan mengesan ciri API, mengekalkan semantik pembatalan, tamat tempoh, dan penghantaran dalam sandaran, serta mengukur kelewatan input, tugasan panjang, dan penyelesaian perniagaan.
5. Huraian Mendalam Langkah demi Langkah
Langkah 1: Tentukan Sama Ada Kerja Sesuai dalam Masa Melahu
Maklum balas pengguna, animasi, dan pemaparan kritikal tidak boleh bergantung pada masa melahu. Pengelompokan analitik, prefetching bukan kritikal, pengindeksan berperingkat, dan pensirilan latar belakang boleh menunggu. Kerja yang mesti selesai sebelum tarikh akhir memerlukan timeout, tetapi laluan had masa tamat mungkin bersaing dengan interaksi; kurangkan saiz kelompok atau bahagikan kerja jika kos tersebut tidak dapat diterima.
Langkah 2: Pecahkan Kerja dalam Belanjawan
Panggilan balik menerima deadline. Proses hanya kelompok kecil yang muat dalam timeRemaining() dan masukkan panggilan balik lain ke dalam giliran apabila kerja masih berbaki. Gunakan penanda penyahduplikasian supaya setiap peristiwa tidak menjadualkan panggilan balik lain. Batalkan kerja dalam giliran apabila berlaku pertukaran laluan, penyahlekapan (unmount), atau versi hasil yang lebih baharu supaya hasil lapuk tidak mengemas kini halaman.
Langkah 3: Asingkan Pemasaan Pengiraan, Rangkaian, dan DOM
Panggilan balik melahu boleh menyediakan data, mensirikannya, atau memasukkan penghantaran ke dalam giliran; permintaan rangkaian itu sendiri tidak menjamin belanjawan melahu yang berterusan. Penulisan DOM boleh mencetuskan tata letak dan pengecatan yang tidak dapat diramalkan, jadi lakukan pengiraan atau bina serpihan (fragment) semasa masa melahu dan komit perubahan yang kelihatan dalam requestAnimationFrame. Jika pengiraan kekal berat pada CPU, Worker mengasingkan benang utama dengan lebih boleh dipercayai berbanding pemecahan tanpa henti.
Langkah 4: Reka Bentuk Keserasian dan Pengukuran
Kesan ciri API dan pilih penjadualan natif, pemasa, atau saluran mesej. Jangan mendakwa sandaran mempunyai semantik melahu natif; nyatakan sama ada ia menangguhkan, menjalankan serta-merta, atau menggugurkan kerja pilihan. Catatkan panjang giliran, masa menunggu, kiraan had masa tamat, hit pembatalan, kelewatan input, dan tugasan panjang, kemudian bandingkan data pengguna sebenar sebelum dan selepas perubahan.
6. Contoh Jawapan Berkualiti Tinggi
Saya terlebih dahulu akan bertanya sama ada kerja tersebut mempengaruhi interaksi semasa dan bila ia mesti diselesaikan. Analitik, prefetching bukan kritikal, dan pensirilan yang boleh dipecahkan boleh menggunakan requestIdleCallback; maklum balas input, animasi, dan pemaparan kritikal tidak boleh menunggu masa melahu.
Saya akan memproses kelompok kecil sehingga timeRemaining() tidak mencukupi. Hanya giliran dengan tarikh akhir perniagaan sebenar yang akan menerima timeout, dan saya menerima bahawa laluan had masa tamat boleh menyebabkan kegagapan paparan (jank). Panggilan balik menyediakan data, manakala requestAnimationFrame melakukan komit terhadap perubahan DOM. Penyahlekapan dan versi hasil yang lebih baharu membatalkan giliran supaya kerja lapuk tidak menulis semula.
Oleh sebab MDN menandakan sokongan sebagai terhad, saya akan melakukan pengesanan ciri. Tanpa sokongan natif, saya akan menangguhkannya dengan pemasa atau saluran mesej, atau menggugurkan kerja pilihan mengikut keperluan produk, sambil mengekalkan peraturan tamat tempoh yang sama. Akhir sekali, saya akan mengukur kelewatan input, tugasan panjang, masa menunggu giliran, kiraan had masa tamat, dan penghantaran analitik untuk membuktikan sama ada pengalaman pengguna bertambah baik.
7. Mod Kegagalan Biasa
- Menganggap panggilan balik melahu sebagai benang latar belakang; ia masih berjalan pada benang utama, jadi kod segerak yang panjang menyekat input.
- Menetapkan
timeoutyang pendek tanpa syarat; had masa tamat menukar kerja berkeutamaan rendah menjadi perebutan interaksi secara tiba-tiba. - Melakukan mutasi DOM yang besar di dalam panggilan balik melahu; kos tata letak dan pengecatan yang tidak dapat diramalkan boleh memadamkan faedahnya.
- Melangkau pengesanan keupayaan dan menjadikan sokongan API yang terhad sebagai prasyarat untuk kefungsian yang betul.
- Menjadualkan sekali bagi setiap peristiwa tanpa penyatuan (coalescing), penyahduplikasian, pembatalan, atau semakan versi hasil.
8. Soalan Susulan dan Maklum Balas
Susulan 1: Bolehkah panggilan balik menunggu selama-lamanya apabila tiada masa melahu?
Tanpa timeout, kerja yang diperlukan boleh menunggu untuk masa yang lama. Berikan had masa tamat kepada kerja yang terikat dengan tarikh akhir dan kurangkan saiz kelompok atau pilih penjadual yang lebih langsung pada laluan had masa tamat. Biarkan kerja yang boleh digugurkan tamat tempoh dan bukannya mengorbankan tindak balas input.
Susulan 2: Mengapa tidak mengemas kini DOM di dalam requestIdleCallback?
Mutasi DOM mempunyai kos tata letak, pengecatan, dan penggubahan yang tidak dapat diramalkan serta boleh melebihi belanjawan melahu. Lakukan pengiraan atau bina serpihan semasa masa melahu, komit dalam requestAnimationFrame, dan sahkan dengan pengukuran tugasan panjang dan kelewatan input.
Susulan 3: Bilakah anda patut menggunakan Worker?
Gunakan Worker apabila pengiraan berat CPU yang berterusan masih menduduki benang utama selepas pemecahan kerja. Worker menambah kos pensirilan, komunikasi, dan pembatalan; kerja kecil yang boleh ditangguhkan adalah lebih mudah dengan panggilan balik melahu.