Pielāgotas programmatūras izstrāde. Īss stāsts par zīmola viļņiem

Risinājuma priekšlikumi

Sākām ar vienkāršu SVG objektu, kas tika animēts, izmantojot dažādas bibliotēkas. Tā kā mēs vēlējāmies vienā lapā izvietot 3 objektus, rezultāts nebija tik apmierinošs. Visas animācijas bija vienkārši lēnas - visi viena SVG objekta ceļi bija jāatjaunina ļoti īsos laika periodos, tāpēc visa lapa bija lēna kā gliemežvāks. Mums nācās atteikties no risinājuma ar tīru SVG, kas ievietots dokumentā. Tas atstāja mums ar diviem citiem risinājumiem.

Portāls video elements bija otrais variants. Mēs sākām ar divām problēmām:

- caurspīdīgs fons, ko nevar izmantot ar populārākajiem video formātiem, piemēram, .mp4 vai .webm,

- atsaucība, kas bija reāla problēma, jo videoklipi kā tādi nav mērogojami.
​
Mēs nolēmām paturēt šo risinājumu otrajā plānā - “ja neatradīsim neko citu, izvēlēsimies šo”.

Pēdējā iespēja bija izmantot audekls ar WebGL atveidošana. Tā bija neparasta iespēja, jo mums pašiem bija jāizstrādā visa renderēšanas mehānika. Tas bija tāpēc, ka morfiskie viļņi, kas mums bija, bija pielāgotie - tas lika mums izstrādāt pielāgotu risinājumu Un tas bija variants, kuram mēs vēlējāmies sekot un uz kuru mēs patiešām koncentrējāmies.

Risinājuma arhitektūra

Sāksim no nulles. Kāds bija materiāls, kas mums bija jāizmanto, lai veidotu šos viļņus? Ideja bija tāda, ka visi viļņi bija SVG fails ar izmēru 1×1 un konkrētiem celiņiem, kas izvietoti ap šo apgabalu. Šī SVG animācija tika veidota, izmantojot dažus šī faila stāvokļu veidus. Tādējādi visas animācijas tika attēlotas kā failu kopums, kas ietvēra formas pārvietošanas posmus.

Padziļināti aplūkojiet, kas ir stāvokļi - visi ceļi ir tikai sava veida masīvi ar konkrētām vērtībām, kas izvietotas konkrētā secībā. Mainot šīs vērtības konkrētās pozīcijās šajā masīvā, mainās forma konkrētās tā daļās. Mēs to varam vienkāršot ar šādu piemēru:


stāvoklis 1: [1, 50, 25, 40, 100]
stāvoklis 2: [0, 75, -20, 5, 120]
stāvoklis 3: [5, 0, -100, 80, 90]


Tātad varam pieņemt, ka forma, ko vēlamies atveidot, sastāv no masīva ar 5 elementiem, kas mainās ar lineāro atvieglojumu noteiktos laika periodos. Kad animācija pabeidz pēdējo posmu, tā sākas no pirmā posma, lai radītu bezgalīgas animācijas iespaidu.

Bet... pagaidiet - kas īsti ir iepriekš redzamais masīvs? Kā jau minēju, tas ir ceļš, kas ir atbildīgs par konkrētas formas attēlošanu. Visa burvība ir ietverta d SVG ceļa īpašība. Šis īpašums satur “komandu” kopumu formas zīmēšanai, un katrai komandai ir vairāki argumenti. Iepriekš minētais masīvs sastāv no visām šīm komandām pievienotajām vērtībām (argumentiem).

Vienīgā atšķirība starp šiem “valsts failiem” bija konkrētu komandu vērtības, jo komandu secība bija vienāda. Tādējādi visa burvība bija saistīta ar visu vērtību iegūšanu un to animēšanu.

Vednis ar nosaukumu Fizika

Iepriekšējā rindkopā es minēju, ka vienīgā objekta animēšanas maģija ir pāreju izveide starp visiem formas posmiem. Jautājums ir - kā to izdarīt ar audeklu?
​
Funkcija, ka visi, kas strādāja ar audekls jāzina, ir requestAnimationFrame. Ja jūs to redzat pirmo reizi, es patiesi ticu, ka jums vajadzētu sākt, izlasot šo. Tātad ar šo funkciju, kas mūs interesē, ir arguments - DOMHighResTimeStamp. Tas izskatās patiešām biedējoši, bet praksē to nav tik grūti saprast. Var teikt, ka tas ir laika zīmogs, kas norāda laiku, kas pagājis no pirmā renderēšanas brīža.

Labi, bet ko mēs ar to varam darīt? Kā requestAnimationFrame funkcija jāizsauc rekursīvi, mēs varam piekļūt laika deltai starp tās izsaukumiem. Un šeit mēs sākam ar zinātni! ⚛️ (ok, varbūt ne raķešu zinātne... vēl)
​
Fizika māca, ka attāluma delta ir vienāda ar laika delta reizinājumu ar ātrumu. Mūsu gadījumā ātrums ir konstants, jo mēs vēlamies sasniegt galapunktu noteiktā laikā. Tāpēc aplūkosim, kā mēs to varam attēlot ar iepriekš minētajiem stāvokļiem:

Pieņemsim, ka mēs vēlamies pāriet starp šiem stāvokļiem tūkstoš milisekundēs, tāpēc ātruma vērtības būs šādas:


delta: [ -1, 25, -45, -35, 20]
ātrums: [-1/1000, 25/1000, -45/1000, -35/1000, 20/1000]


Iepriekš minētais ātrums mums norāda: par katru milisekundi palielināsim vērtību par -1/1000. Un šeit ir punkts, kurā mēs varam atgriezties pie mūsu requestAnimationFrame un laika delta. Konkrētās pozīcijas vērtība, par kuru vēlamies palielināt vērtību, ir laika delta reizinājums ar tās pozīcijas ātrumu. Vēl viena lieta, ko var panākt bez problēmām, ir ierobežot vērtību tā, lai tā nepārsniegtu stāvokli, uz kuru tā dodas.
​
Kad pāreja beidzas, mēs izsaucam citu un tā tālāk. Un tas nešķiet tik grūti īstenojams, bet viens no galvenajiem noteikumiem programmatūras izstrāde ir netērēt laiku lietām, kas jau ir ieviestas. Tātad - mēs izvēlējāmies maza bibliotēka kas ļauj mums bez piepūles izveidot šīs pārejas.
​
Tā mēs izveidojām animētu vilni, kas izskatās kā dzīvs radījums.

Daži vārdi par formu klonēšanu

Kā redzat, The Codest zīmola viļņi nav viena animēta figūra. Tie sastāv no daudzām vienādas formas, bet dažāda izmēra un novietojuma figūrām. Šajā solī apskatīsim, kā šādi dublēt.
​
Tādējādi audekla konteksts ļauj mums mēroga zīmēšanas zona (zem pārsega - var teikt, ka tas reizina visus izmērus, kas nodoti drawable metodēm, ar “k”, kur “k” ir mērogošanas koeficients, kas pēc noklusējuma ir “1”), veikt audekla tulkojumu, tas ir tāpat kā mainīt zīmēšanas apgabala enkurpunktu. Ar šīm metodēm mēs varam arī pāriet starp šiem stāvokļiem: saglabāt un atjaunot.
​
Šīs metodes ļauj mums saglabāt “nulles modifikāciju” stāvokli un pēc tam atveidot noteiktu skaitu viļņu cilpā ar pareizi mērogotu un tulkotu audeklu. Uzreiz pēc tam mēs varam atgriezties saglabātajā stāvoklī. Tas ir viss par figūru klonēšanu. Daudz vieglāk nekā klonēt aitas, vai ne?

Ķirsis virsū

Es minēju, ka vienu no potenciālajiem risinājumiem noraidījām veiktspējas dēļ. Variants ar audeklu ir diezgan ātrs, bet neviens neteica, ka to nevarētu optimizēt vēl vairāk. Sāksim ar to, ka mums īsti nerūp formu pāreja, kad tās atrodas ārpus pārlūkprogrammas skata laukuma.
​
Ir vēl viens pārlūks API ka programmētāji mīlēja - IntersectionObserver. Tas ļauj sekot konkrētiem lapas elementiem un apstrādāt notikumus, kas tiek izsaukti, kad šie elementi parādās vai pazūd no skata laukuma. Šobrīd mums ir diezgan vienkārša situācija - izveidosim redzamības stāvokli, mainīsim to, izmantojot IntersectionObserver notikumu apstrādātājus, un vienkārši ieslēgsim/izslēgsim atveidošanas sistēmu konkrētām formām. Un... bums, veiktspēja ir ievērojami uzlabojusies! Mēs atveidojam tikai tās lietas, kas ir redzamas skatlogā.

Kopsavilkums

Bieži vien ir grūti izvēlēties, kā kaut ko īstenot, jo īpaši tad, ja šķiet, ka pieejamajām iespējām ir līdzīgas priekšrocības un trūkumi. Galvenais, lai izdarītu pareizu izvēli, ir analizēt katru no tiem un izslēgt tos, kurus uzskatām par mazāk izdevīgiem. Ne viss ir skaidrs - kāds no risinājumiem prasa vairāk laika nekā citi, bet, iespējams, tas ir optimizējams vieglāk vai pielāgojamāks.

Lai gan jauns JS bibliotēkas parādās gandrīz katru minūti, ir lietas, ko tās nevar atrisināt. Tāpēc ikvienam front-end inženierim (un ne tikai viņam) ir jāpārzina pārlūkprogrammu API, jāseko līdzi tehniskajām jaunumiem un reizēm vienkārši jāpadomā: “Kā izskatītos šīs bibliotēkas implementācija, ja man būtu jādara tā?”. Iegūstot vairāk zināšanu par pārlūkprogrammām, mēs varam veidot patiešām modernas lietas, pieņemt pareizus lēmumus par izmantojamajiem rīkiem un kļūt pārliecinātāki par savu darbu. kods.

Lasīt vairāk:

- Rubīns 3.0. Ruby un mazāk zināmas privātuma kontroles metodes

- #1: Slēptās izmaksas un reāla elastība produktu izstrādes procesā

- CTO izaicinājumi - programmatūras produktu paplašināšana un izaugsme