Cara Betulkan Animasi GSAP ScrollTrigger yang Beku dengan Lenis
Animasi GSAP ScrollTrigger anda tidak bergerak bila guna Lenis? Fahami puncanya dan cara menggunakan `gsap.ticker.add` untuk menyelaraskannya semula.
Masalahnya: Kenapa Animasi 'Scrub' Anda Beku
Jika anda membina laman web moden yang interaktif, anda mungkin pernah menggabungkan GreenSock Animation Platform (GSAP) dengan pustaka smooth scrolling seperti Lenis. ScrollTrigger dari GSAP sangat berkuasa untuk mencipta animasi yang bertindak balas terhadap kedudukan skrol. Lenis pula memberikan pengalaman skrol yang licin dan digilap, yang selalunya tiada pada fungsi skrol pelayar web biasa.
Masalah timbul apabila anda cuba 'scrub' animasi GSAP—iaitu, mengikat kemajuan animasi secara terus kepada kedudukan skrol pengguna. Anda siapkan timeline anda, konfigurasikan ScrollTrigger dengan scrub: true, dan semuanya berfungsi dengan sempurna. Kemudian, anda tambah Lenis. Tiba-tiba, animasi menjadi beku. Ia mungkin terus melompat ke keadaan akhir apabila anda sampai ke penghujung trigger, tetapi ia tidak akan beranimasi dengan lancar semasa anda skrol. Ini adalah masalah biasa, dan ia memerlukan satu pembetulan khusus: pembetulan gsap.ticker untuk Lenis ScrollTrigger.
Di JRV Systems, kami sering berdepan dengan senario ini semasa membangunkan pengalaman web yang sangat interaktif. Isu ini bukanlah pepijat dalam mana-mana pustaka; ia adalah konflik dalam cara kedua-duanya mengendalikan kemas kini.
Isu Sebenar: Pertembungan Kitaran Kemas Kini
Untuk memahami penyelesaiannya, kita perlu faham puncanya terlebih dahulu. Puncanya adalah bagaimana setiap pustaka mendapatkan datanya.
- GSAP ScrollTrigger secara lalai mendengar kepada acara
scrollasli pelayar web. Ia menggunakan acara ini untuk mengetahui kedudukan skrol halaman dan mengemas kini sebarang animasi yang terikat padanya. - Lenis pula melumpuhkan tingkah laku skrol asli. Ia mendengar input pengguna (seperti roda tetikus atau sentuhan) dan kemudian menggerakkan kandungan halaman secara terprogram, mengira kedudukan dengan logiknya sendiri untuk mencipta kesan licin. Kerana ia tidak menggunakan mekanisme scrollbar asli, ia tidak mencetuskan acara
scrollasli yang ditunggu-tunggu oleh ScrollTrigger.
GSAP berjalan menggunakan pemasa dalamannya sendiri, yang dipanggil gsap.ticker. Ia pada asasnya adalah satu gelung requestAnimationFrame, iaitu cara standard pelayar web untuk menjalankan kod dengan cekap sejurus sebelum skrin dilukis semula (idealnya 60 kali sesaat). Oleh kerana ScrollTrigger tidak mendapat sebarang data kedudukan skrol baharu daripada acara asli, ticker tidak mempunyai maklumat baharu untuk mengemas kini animasi, dan ia kelihatan beku.
Penyelesaian: Pembetulan gsap.ticker untuk Lenis dan ScrollTrigger
Penyelesaiannya adalah dengan menyambungkan kemas kini skrol Lenis kepada gelung kemas kini GSAP secara manual. Kita perlu memberitahu ticker GSAP untuk turut menjalankan fungsi kemas kini Lenis pada setiap bingkai (frame). Ini memastikan kedua-dua sistem diselaraskan dengan sempurna.
Berikut adalah coretan kod penting yang menyelesaikan konflik ini:
const lenis = new Lenis()
lenis.on('scroll', ScrollTrigger.update)
gsap.ticker.add((time)=>{
lenis.raf(time * 1000)
})
gsap.ticker.lagSmoothing(0)
Mari kita huraikan kod ini:
const lenis = new Lenis(): Ini adalah permulaan standard untuk pustaka Lenis.lenis.on('scroll', ScrollTrigger.update): Baris ini penting untuk animasi yang tidak menggunakan scrub. Ia memberitahu ScrollTrigger untuk melakukan pengiraannya setiap kali Lenis melaporkan acara skrol. Ini membantu dalam mencetuskan animasi yang hanya dimainkan sekali dengan tepat.gsap.ticker.add((time)=>{ lenis.raf(time * 1000) }): Inilah inti kepada penyelesaian untuk animasi scrub. Kita 'mencelah' masuk ke dalam gelung kemas kini utama GSAP (gsap.ticker). Pada setiap 'tick' (bingkai), kita memanggil kaedahraf(requestAnimationFrame) Lenis. Ini memaksa Lenis untuk mengira semula kedudukan skrolnya, dan oleh kerana kedua-duanya kini berada dalam gelung yang sama, ScrollTrigger boleh mendapatkan data kedudukan terkini untuk mengemas kini animasi scrub.gsap.ticker.lagSmoothing(0): Ini adalah pengoptimuman pilihan tetapi disyorkan. Ia memberitahu ticker GSAP untuk tidak cuba "mengejar" selepas kemungkinan berlaku lengah masa, yang kadangkala boleh mengganggu pustaka smooth scroll.
Dengan menambah beberapa baris kod ini pada persediaan JavaScript projek anda, anda mencipta jambatan antara kedua-dua pustaka, membolehkan mereka berkongsi satu sumber rujukan yang sama untuk masa dan kemas kini.
Butiran Pelaksanaan dan Amalan Terbaik
Semasa melaksanakan pembetulan ini, terdapat beberapa pertimbangan lain yang perlu diingat untuk membina laman web yang mantap dan mudah diakses.
Mengendalikan prefers-reduced-motion
Pengguna boleh mengaktifkan tetapan sistem operasi yang dipanggil prefers-reduced-motion untuk memberi isyarat bahawa mereka mahu melihat kurang animasi. Ini adalah ciri kebolehcapaian yang kritikal. Anda harus menghormati pilihan ini dengan mematikan Lenis dan kesan ScrollTrigger yang kompleks.
const lenis = new Lenis()
if (ScrollTrigger.isTouch !== 1 && !window.matchMedia("(prefers-reduced-motion: reduce)").matches) {
lenis.on('scroll', ScrollTrigger.update)
gsap.ticker.add((time) => {
lenis.raf(time * 1000)
})
gsap.ticker.lagSmoothing(0)
}
Kod ini membungkus pembetulan dalam satu syarat yang memeriksa sama ada pengguna memilih untuk mengurangkan gerakan. Kami juga menambah semakan untuk peranti sentuh (ScrollTrigger.isTouch !== 1), kerana smooth scrolling kadangkala terasa kurang semula jadi pada peranti mudah alih.
Pertimbangan untuk iOS Safari Pelayar web mudah alih, terutamanya Safari pada iOS, mempunyai fizik skrol yang unik. Walaupun pembetulan ini secara amnya berfungsi dengan baik, sentiasa uji dengan teliti pada iPhone sebenar. Interaksi antara viewport pelayar, papan kekunci maya, dan skrol terprogram kadangkala boleh menyebabkan kegagapan.
Cara Kami Sahkan Pembetulan Berfungsi
Bagaimana anda tahu pembetulan ini dilaksanakan dengan betul? Tanda yang paling jelas ialah animasi scrub anda berfungsi seperti yang diharapkan. Tetapi untuk pengesahan yang lebih teknikal, anda boleh menggunakan alatan pembangun (developer tools) pelayar web.
- Pemeriksaan Visual: Skrol ke atas dan ke bawah. Animasi sepatutnya mengikut kedudukan skrol anda dengan lancar, bergerak ke hadapan apabila anda skrol ke bawah dan ke belakang apabila anda skrol ke atas.
- Pemantauan Prestasi: Buka pemantau Prestasi pelayar anda (contohnya, dalam Chrome DevTools). Apabila anda skrol, anda sepatutnya melihat kadar bingkai (frame rate) yang konsisten menghampiri 60 bingkai sesaat (fps). Jika animasi tersekat-sekat, graf kadar bingkai akan menunjukkan penurunan yang kerap.
- Log Konsol: Tambah
console.logbuat sementara waktu di dalam fungsigsap.ticker.add. Anda sepatutnya melihatnya berjalan secara berterusan semasa anda skrol, mengesahkan bahawa gelung itu aktif.
Sebagai sebuah studio perisian di Seremban, kami mengamalkan langkah-langkah pengesahan ini untuk memastikan laman web yang kami bina untuk perniagaan di Malaysia bukan sahaja menarik dari segi visual tetapi juga mantap dari segi teknikal dan berprestasi tinggi pada semua peranti biasa.