Distrugerea miturilor css animație vs

La un moment dat, majoritatea dezvoltatorilor au folosit jQuery pentru a anima articole în browser. Desaturați asta, întindeți - lucruri simple. Dar când proiectele interactive au devenit mai agresive, iar dispozitivele mobile au intrat în scenă, performanța a devenit cea mai importantă.

Flash a dispărut treptat de la distanță, iar animatorii talentați au obligat HTML5 să facă lucruri pe care nu le-a mai făcut niciodată. Aveau nevoie de instrumente mai eficiente pentru efecte complexe și performanțe de primă clasă.

jQuery pur și simplu nu a fost destinat pentru asta. Browserele s-au maturizat și au început să ofere soluții.

Cea mai cunoscută soluție este animația CSS. CSS animație ca favorit al industriei IT, de mai mulți ani, a fost discutată fără sfârșit la conferințe în care expresii precum "accelerarea hardware" și "prietenia cu dispozitivele mobile" au mângâiat publicul.

Fiind cineva care este fascinat (pe marginea obsesiei, de fapt) cu animație și performanță, m-am grăbit să urc la îmbrățișarea CSS. Și nu am avut timp să merg departe, pentru că au fost multe probleme serioase, despre care nimeni nu le-a spus. Am fost în șoc.

Nu există control independent asupra scalei / rotației / poziției

Animarea scării, rotirea și poziția elementului este extrem de comună. În CSS, toți acești parametri sunt înghesuiți în proprietatea transformă, ceea ce face imposibilă crearea unei animații separate pentru fiecare parametru al unui element.

De exemplu, ce se întâmplă dacă doriți să efectuați rotații și animații la scară independent una de cealaltă, cu calcule și funcții de atenuare diferite?

În opinia mea, aceasta este în mod clar partea slabă a CSS, dar dacă creați animații mai simple care implică transformări în întregime în orice moment, atunci acest moment nu va fi o problemă pentru dvs.

productivitate

Argumentul cel mai obișnuit pentru utilizarea CSS pentru animație este "accelerarea hardware". Sună apetisant, nu?

Să o distrugem în două părți:

Angajarea GPU-ului

GPU-ul este foarte optimizat pentru sarcini cum ar fi mutarea pixelilor, aplicarea de matrice de transparență și conversie, astfel încât browserele moderne încearcă să transfere astfel de sarcini de la CPU la GPU.

Secretul este de a selecta elemente animate în propria lor straturi GPU, pentru că odată ce stratul este creat (cu condiția ca aceasta să nu se schimba pixelii originale) pentru GPU nu este dificil să se mute acești pixeli și să le combine împreună.

In loc de a calcula fiecare pixel de 60 de ori pe secundă, GPU poate stoca grupuri de pixeli (ambele straturi) și pur și simplu spun „schimburi acest grup de 10 pixeli și în jos cu 5 pixeli“ (sau ceva similar).

De asemenea, rețineți că nu toate proprietățile CSS obțin accelerația GPU în animațiile CSS. De fapt, majoritatea nu primesc această accelerare. Transformările (scala, rotația, schimbarea și înclinarea) și transparența reprezintă operațiunile de bază care beneficiază de accelerarea GPU-ului.

Redistribuirea calculelor la un alt flux

O altă parte a "accelerației hardware" este legată de posibilitatea de a folosi diferite fire de CPU pentru calculele legate de animație. Din nou, acest lucru pare grozav în teorie, dar nu merge fără costuri, iar dezvoltatorii adesea supraestimează beneficiile pe care le primesc.

Mai întâi, numai proprietățile care nu afectează fluxul de documente pot fi într-adevăr transmise unui alt fir.

Prin urmare, din nou, transformarea și transparența sunt principalii beneficiari. Cu ramificarea fluxurilor, apare cheltuielile asociate cu gestionarea acestui proces.

Deoarece randarea graficii și aspectul documentului consumă majoritatea resurselor de calcul (mult mai mari) în majoritatea animațiilor (fără a lua în calcul valorile intermediare ale proprietăților de animație), beneficiul utilizării unui flux separat pentru interpolare este minim.

De exemplu, dacă 98% din munca pentru o anumită animație este o randare grafica și aspectul documentului, iar 2% - găsirea de noi valori ale poziției / rotație / transparență / altceva, chiar și calcularea lor de 10 ori mai repede, în general, veți vedea doar despre tot 1 % creștere a vitezei.

Comparație de performanță

Testul de stres dat mai jos creează un anumit număr de elemente de imagine (puncte) și le conduce din centru într-o locație aleatorie în apropierea limitelor, utilizând întârzieri arbitrare, creând astfel un efect de zbor prin stele.

Setați un număr mare de puncte și vedeți compararea jQuery. GSAP și Zepto.

Deoarece Zepto folosește transformările CSS pentru toate animațiile, performanța sa ar trebui să fie cea mai bună, nu-i așa?

Rezultatele confirmă ceea ce se celebrează pe Internet - animația CSS este mult mai rapidă decât jQuery.

sus, stânga, lățime, înălțime

Windows Surface RT, iPhone 5s (iOS7), iPad 3 (iOS 6), iPad 3 (iOS7), Samsung Galaxy Tab 2, Chrome, Firefox, Safari, Opera, Kindle Fire HD, IE11

Windows Surface RT, iPhone 5s (iOS7), iPad 3 (iOS7), Samsung Galaxy Tab 2, Firefox, Opera, IE11

iPad 3 (iOS6), Safari, Chrome

Cât de mult mai rapid? Versiunea inițială de test a avut un număr de numărul de cadre pe secundă pentru a obține rezultate cantitative, dar în curând a constatat că nu există nici o modalitate cu adevărat precisă pentru a măsura acest indicator în toate browserele, în special cu animatii CSS, iar unele browsere au fost date de date care induc în eroare, așa că am eliminat această caracteristică.

Deși puteți estima cu ușurință performanța relativă, creșterea numărului de puncte, comutarea între motoare și urmărirea modului în care se efectuează animația (mișcare uniformă, uniformitatea intervalelor de timp, distribuția punctelor etc.). În final, obiectivul principal este de a obține animații prezentabile.

Deși sperăm că acest lucru se va schimba. Fie ca asa, in cele mai reale proiecte nu veti observa niciodata o diferenta in performanta.

Vă încurajez să efectuați propriile teste pentru a vedea ce tehnologie va oferi o animație lină într-un anumit proiect (proiecte).

Nu cumpărați mitul că animația CSS este întotdeauna mai rapidă și nu presupuneți că testul de viteză de mai sus reflectă ceea ce vedeți în aplicația dvs. Testați, testați și testați din nou.

Execuția controalelor și a evenimentelor

Unele browsere vă permit să opriți sau să reporniți animația cu ajutorul cadrelor CSS cheie, dar asta e tot.

Nu puteți face referire la un anumit loc în animație precum și nu se poate schimba lin direcția de deplasare în domeniul animației, sau a modifica scara de timp sau pentru a adăuga callbacks în anumite locuri, sau să le atașați la un set bogat de evenimente de redare.

animație modernă este foarte puternic asociat cu interactivitate, atât de incredibil de util pentru a putea efectua animația valorilor inițiale variabile până la sfârșitul variabilă (de exemplu, în funcție de locul în care utilizatorul face clic pe mouse-ul), sau schimba ceva „din zbor“, dar animație declarativă CSS-based nu permit acest lucru.

flux de lucru

Pentru tranziții simple între două stări (de exemplu, curse sau meniuri de deschidere etc.), transformările CSS sunt perfect potrivite.

Cu toate acestea, pentru o serie de evenimente, va trebui de obicei să utilizați animații CSS cu cadre cheie, în care trebuie să specificați selectorii ca procente, de exemplu:

Dar când creați o animație, nu sunteți ghidată de intervale de timp, nu procente? De exemplu, "măriți transparența pentru o secundă, apoi deplasați-o spre dreapta în decurs de 0,75 secunde, apoi pentru restul secunde pentru a face un salt în jos".

Ce se întâmplă dacă petreceți mai multe ore calculând o secvență complexă în procente și clientul spune apoi: "Faceți această parte în mijloc timp de 3 secunde mai mult"? Uff, trebuie să renunți la toate procentele!

În mod obișnuit, animațiile pentru clădiri implică un număr mare de experimente, în special cu funcțiile de timp și atenuare.

Acest lucru este relevant în cazul în care metoda search () ar fi suficient de utilă. Imaginați-vă că creați o piesă de animație cu 60 de secunde și apoi ascuțiți ultimele 5 secunde: va trebui să vă așezați în primele 55 de secunde de fiecare dată când doriți să vedeți rezultatul ajustărilor dvs. în ultimele părți.

Ugh! Folosind metoda search (), poți pur și simplu să te referi la un anumit loc în procesul de animație pentru a intra în partea pe care lucrezi și apoi să o ștergi când termini. Aceasta este o economie de timp semnificativă.

Este folosit pe scară largă pentru a crea animații pentru obiecte bazate pe panza și alte obiecte din biblioteci terțe, dar, din păcate, animațiile CSS sunt doar pentru elementele DOM.

Aceasta înseamnă că, dacă puneți o mulțime de timp și energie în animația CSS, acestea nu pot fi transferate altor tipuri de proiecte.

Va trebui să schimbați setul de instrumente de animație.

Există câteva alte instrumente utile care sunt relevante pentru fluxul de lucru care nu sunt prezente în animațiile CSS:

Efecte limitate

Nu puteți face nimic din următoarea listă utilizând animația CSS:

Animație de-a lungul unei curbe (de exemplu, curba Bezier);
Folosiți funcții interesante de înmuiere, cum ar fi elasticitatea, elasticitatea sau înmuierea dur. Există o opțiune cubic-bezier (). Dar permite doar două puncte-cheie, care limitează foarte mult oportunitățile;
Mișcarea în conformitate cu legile fizice. De exemplu, o mișcare netedă bazată pe inerție și o întoarcere ușoară înapoi, implementată în acest demo Draggable;
Animând poziția de defilare;
Direcția de rotație (de exemplu, "rotiți exact 270 de grade în direcția cea mai scurtă, în sensul acelor de ceasornic sau în sens invers acelor de ceasornic");
Animarea atributelor.

compatibilitate

Animațiile bazate pe CSS nu funcționează în versiunile IE9 și în versiunile anterioare ale browserului. Cei mai mulți dintre noi urăsc să oferim suport pentru browserele învechite (în special IE), însă realitatea este că unii dintre noi au clienți care o cer.

Utilizarea prefixelor este necesară pentru multe browsere, dar puteți utiliza instrumentele de preprocesare pentru a evita să le scrieți manual.

concluzie

Sunt animațiile CSS rău? Cu siguranță nu. De fapt, ele sunt excelente pentru tranziții simple între state (de exemplu, răsturnarea), când nu este necesară compatibilitatea cu browserele moștenite.

Transformările 3D au, de obicei, performanțe bune (iOS7 este o excepție notabilă), iar animațiile CSS pot fi foarte atractive pentru dezvoltatorii care preferă să pună întreaga animație și prezentări în stratul CSS.

Pot să înțeleg de ce animațiile CSS erau atât de atractive în comparație cu jQuery.animate (). Cine, în mintea lor corectă, nu ar fi profitat de posibilitatea de a obține o creștere de 10 ori a productivității?

În plus, am vrut să arunc o lumină asupra unor aspecte ale animațiilor CSS care provoacă frustrare (despre care nimeni nu vorbește), deci acum puteți lua o decizie mai informată despre cum să creați animații.

Va fi specificația animațiilor Web rezolvată de problemele existente?

W3C lucrează la o nouă specificație numită «Web animații» (animație web), al cărui scop este de a aborda multe dintre deficiențele din animațiile CSS și transformări, oferind un control mai bun de performanță și caracteristici suplimentare.

Desigur, se pare că acesta este un pas înainte în multe privințe, dar există încă o serie de neajunsuri (dintre care unele nu vor fi, probabil depășite de necesitatea de a sprijini versiuni mai vechi ale specificațiilor CSS existente, astfel încât, de exemplu, componente independente ale transformării de management este puțin probabil).

Deși aceasta este o poveste complet diferită. Trebuie să așteptăm și să vedem cum se întâmplă lucrurile. Există, desigur, băieți inteligenți care lucrează la această specificație.

Articole similare

Pagina anterioară

Pagina următoare