Baiki GSAP ScrollTrigger & Lenis yang Kaku: Guna Patch gsap.ticker
Animasi GSAP ScrollTrigger anda beku bila guna Lenis? Isu ini berpunca dari konflik 'requestAnimationFrame'. Pelajari cara mudah membaikinya dengan 4 baris kod.
Apabila membina laman web moden yang lancar, stack yang sering digunakan ialah GSAP untuk animasi, ScrollTrigger untuk interaksi berasaskan skrol, dan Lenis untuk 'smooth scrolling'. Ia adalah gabungan hebat yang boleh menghasilkan pengalaman pengguna yang premium. Namun, ramai pembangun menghadapi satu masalah yang mengecewakan: animasi ScrollTrigger yang di-'scrub' menjadi kaku semasa skrol, dan hanya bergerak selepas skrol berhenti. Ia nampak rosak dan menjejaskan tujuan efek skrol lancar.
Ini bukanlah satu pepijat (bug) secara teknikal. Ia adalah konflik logik dalam cara kedua-dua library ini mengendalikan 'render frame'. Nasib baik, penyelesaiannya agak mudah dan melibatkan penyelarasan 'update loop' mereka. Artikel ini akan menerangkan punca masalah dan menyediakan penyelesaian Lenis ScrollTrigger gsap.ticker fix yang muktamad.
Punca Masalah: Pertembungan requestAnimationFrame
Untuk memahami penyelesaiannya, kita perlu faham dahulu mengapa ia berlaku. Konflik ini timbul daripada dua sistem berbeza yang cuba mengawal 'render loop' halaman.
-
Cara GSAP ScrollTrigger Berfungsi (Asal): Secara lalai, ScrollTrigger mendengar 'event'
scrollasli daripada pelayar (browser). Apabila anda skrol menggunakan roda tetikus atau 'trackpad', 'event' ini dicetuskan berulang kali, dan ScrollTrigger akan mengemas kini progres animasi mengikutnya. Ia ringkas dan efisien. -
Cara Lenis Berfungsi: Tujuan utama Lenis adalah untuk mengambil alih tingkah laku skrol asli. Ia menangkap input skrol anda, menghalang skrol lalai pelayar, dan kemudian mencipta animasi skrol lancarnya sendiri menggunakan
requestAnimationFrame. Ini adalah satu gelung (loop) pacuan JavaScript yang mengemas kini kedudukan skrol halaman bingkai demi bingkai, menghasilkan efek 'easing' yang kita inginkan.
Konfliknya sekarang sudah jelas: Lenis telah mengambil alih. 'Event' scroll asli yang ditunggu oleh ScrollTrigger tidak lagi dicetuskan secara berterusan. Ia mungkin hanya dicetuskan sekali di penghujung skrol Lenis, sebab itulah anda nampak animasi tiba-tiba melompat ke keadaan terakhirnya. Semasa skrol lancar itu sendiri, ScrollTrigger tidak menerima sebarang kemas kini, jadi animasi kekal beku.
Penyelesaian: Segerakkan Lenis dan GSAP dengan gsap.ticker
Penyelesaiannya adalah dengan berhenti bergantung pada 'event' skrol asli dan sebaliknya menghubungkan kedua-dua library ke dalam satu 'update loop' yang dikongsi. GSAP mempunyai 'loop' requestAnimationFrame sendiri yang sangat dioptimumkan, dipanggil gsap.ticker. Kita boleh gunakannya sebagai sumber rujukan utama untuk kemas kini masa dan 'rendering'.
Berikut adalah coretan kod lengkap yang anda perlukan selepas memulakan Lenis dan GSAP:
const lenis = new Lenis()
lenis.on('scroll', ScrollTrigger.update)
gsap.ticker.add((time)=>{
lenis.raf(time * 1000)
})
gsap.ticker.lagSmoothing(0)
Mari kita huraikan empat baris penting ini:
lenis.on('scroll', ScrollTrigger.update): Baris ini memberitahu ScrollTrigger untuk menjalankan methodupdate()setiap kali Lenis mencetuskan 'event'scroll. Ini memastikan pengiraan kedudukan ScrollTrigger (titik mula/akhir) sentiasa betul berdasarkan kedudukan skrol maya Lenis.gsap.ticker.add((time)=>{...}): Inilah teras kepada penyelesaian Lenis ScrollTrigger gsap.ticker fix. Kita menambah fungsi baru ke dalam 'ticker' utama GSAP, yang berjalan pada setiap bingkai. Di dalam fungsi ini, kita memanggillenis.raf().lenis.raf(time * 1000): Perintah ini memberitahu Lenis untuk memajukan animasi skrol lancarnya untuk bingkai semasa. Kini, Lenis tidak lagi menjalankan 'loop' sendiri, sebaliknya ia dipacu terus oleh GSAP. Kedua-duanya kini segerak dengan sempurna. Kita mendarabtimedengan 1000 kerana 'ticker' GSAP memberikan masa dalam unit saat, manakala methodrafLenis menjangkakan unit milisaat.gsap.ticker.lagSmoothing(0): Ini adalah satu pengoptimuman prestasi. Ia memberitahu 'ticker' GSAP untuk tidak cuba mengimbangi potensi 'lag', yang kadangkala boleh menyebabkan sedikit lompatan apabila digunakan dengan pemacu luaran seperti ini. Hasilnya ialah sambungan yang lebih terus dan stabil.
Mengesahkan Ia Berfungsi
Selepas anda melaksanakan kod tersebut, ujian pertama adalah secara visual. Animasi 'scrubbed' anda kini sepatutnya bergerak lancar seiring dengan skrol Lenis. Untuk lebih kepastian, anda boleh menggunakan 'developer tools' pelayar anda.
-
FPS Meter: Buka 'rendering tools' pelayar anda (dalam Chrome, Command+Shift+P -> "Show rendering" -> "FPS meter"). Semasa anda skrol, anda sepatutnya melihat kadar bingkai (frame rate) yang stabil, idealnya menghampiri kadar segar semula monitor anda (cth., 60fps).
-
Log Konsol: Tambah 'callback'
onUpdatesementara pada salah satu 'tween' GSAP anda untuk mencatat progresnya.gsap.to('.my-element', { scrollTrigger: { scrub: true, // ... }, x: 500, onUpdate: self => console.log(self.progress.toFixed(3)) });Jika ia berfungsi, konsol anda akan dipenuhi dengan nilai progres (0.001, 0.002, dll.) semasa anda skrol. Jika ia rosak, anda tidak akan nampak apa-apa, dan kemudian hanya satu log
1.000apabila skrol berhenti.
Perkara Penting: iOS Safari dan Kebolehcapaian
Walaupun penyelesaian ini mantap, terdapat dua kes terpencil yang penting untuk dipertimbangkan bagi laman web peringkat produksi.
iOS Safari: Mobile Safari mempunyai fizik skrolnya yang unik dan tingkah laku penjimatan bateri yang agresif. Walaupun dengan penyelesaian ini, anda mungkin masih menghadapi sedikit 'jitter' pada paparan yang kompleks, terutamanya semasa 'fling' laju. Tiada penyelesaian magik di sini. Di JRV Systems, proses kami untuk projek yang menyasarkan pengguna Malaysia—di mana bahagian pasaran iPhone adalah signifikan—sentiasa merangkumi ujian rapi pada peranti fizikal iPhone dan iPad, bukan sekadar emulator.
Kebolehcapaian (prefers-reduced-motion): 'Smooth scrolling' boleh menyebabkan mabuk gerakan atau ketidakselesaan bagi sesetengah pengguna. Amalan terbaik kebolehcapaian web adalah untuk menghormati 'media query' prefers-reduced-motion. Anda harus meletakkan kod permulaan Lenis dan logik 'ticker' di dalam satu semakan untuk tetapan ini.
- Semak jika pengguna memilih untuk mengurangkan gerakan.
- Jika ya, jangan mulakan Lenis atau sambungan
gsap.ticker. - Laman web kemudiannya akan kembali menggunakan skrol asli pelayar, iaitu pengalaman yang boleh diakses seperti yang dikehendaki.
Berikut ialah cara anda boleh melaksanakannya:
const prefersReducedMotion = window.matchMedia('(prefers-reduced-motion: reduce)').matches;
if (!prefersReducedMotion) {
const lenis = new Lenis()
lenis.on('scroll', ScrollTrigger.update)
gsap.ticker.add((time)=>{
lenis.raf(time * 1000)
})
gsap.ticker.lagSmoothing(0)
}
Kesimpulan: Penyelesaian Mudah untuk Stack Profesional
Tingkah laku beku antara Lenis dan GSAP ScrollTrigger adalah contoh klasik bagaimana dua library yang hebat boleh berkonflik apabila kedua-duanya cuba menguruskan sumber yang sama. Dengan menggunakan gsap.ticker sebagai jam utama, anda mencipta satu sistem yang disegerakkan di mana animasi terikat sempurna dengan skrol lancar, bingkai demi bingkai.
Melaksanakan penyelesaian Lenis ScrollTrigger gsap.ticker fix ini adalah satu langkah kecil tetapi kritikal. Ia adalah perincian teknikal yang membezakan antara pengalaman pengguna yang mengecewakan dengan pengalaman yang digilap dan profesional yang diharapkan oleh klien daripada aplikasi web moden, sama ada untuk laman e-dagang dinamik atau papan pemuka SaaS yang dibina khas. Ia adalah sebahagian standard daripada aliran kerja pembangunan 'front-end' kami di JRV Systems.