window.pipedriveLeadboosterConfig = { base: 'leadbooster-chat.pipedrive.com', companyId: 11580370, playbookUuid: '22236db1-6d50-40c4-b48f-8b11262155be', version: 2, } ;(funktion () { var w = vindue if (w.LeadBooster) { console.warn('LeadBooster findes allerede') } else { w.LeadBooster = { q: [], on: function (n, h) { this.q.push({ t: 'o', n: n, h: h }) }, trigger: function (n) { this.q.push({ t: 't', n: n }) }, } } })() Udvikling af skræddersyet software. En kort historie om brandbølger - The Codest
Codest
  • Om os
  • Serviceydelser
    • Udvikling af software
      • Frontend-udvikling
      • Backend-udvikling
    • Staff Augmentation
      • Frontend-udviklere
      • Backend-udviklere
      • Dataingeniører
      • Cloud-ingeniører
      • QA-ingeniører
      • Andet
    • Det rådgivende
      • Revision og rådgivning
  • Industrier
    • Fintech og bankvirksomhed
    • E-commerce
    • Adtech
    • Sundhedsteknologi
    • Produktion
    • Logistik
    • Biler
    • IOT
  • Værdi for
    • ADMINISTRERENDE DIREKTØR
    • CTO
    • Leder af levering
  • Vores team
  • Casestudier
  • Ved hvordan
    • Blog
    • Møder
    • Webinarer
    • Ressourcer
Karriere Tag kontakt til os
  • Om os
  • Serviceydelser
    • Udvikling af software
      • Frontend-udvikling
      • Backend-udvikling
    • Staff Augmentation
      • Frontend-udviklere
      • Backend-udviklere
      • Dataingeniører
      • Cloud-ingeniører
      • QA-ingeniører
      • Andet
    • Det rådgivende
      • Revision og rådgivning
  • Værdi for
    • ADMINISTRERENDE DIREKTØR
    • CTO
    • Leder af levering
  • Vores team
  • Casestudier
  • Ved hvordan
    • Blog
    • Møder
    • Webinarer
    • Ressourcer
Karriere Tag kontakt til os
Pil tilbage GÅ TILBAGE
2021-02-10
Udvikling af software

Udvikling af skræddersyet software. En kort historie om brandbølger

Codest

Bartosz Slysz

Software Engineer

En af de ting, der gjorde os forvirrede, da vi byggede vores nye hjemmeside, var morfede bølger, som man kan se forskellige steder på siderne. Vi havde mange ideer til, hvordan vi kunne implementere dem på den rigtige måde uden den store indsats. Men de fleste af løsningerne var langsomme, og vi var nødt til at bygge noget op fra bunden, som ville være hurtigere end allerede eksisterende biblioteker.

Forslag til løsninger

Vi startede med et almindeligt SVG-objekt, som blev animeret med forskellige biblioteker. Da vi gerne ville have tre objekter på én side, var resultatet ikke så tilfredsstillende. Alle animationerne var bare langsomme - alle baner i et enkelt SVG-objekt skulle opdateres på meget kort tid, hvilket gjorde hele siden langsom som en snegl. Vi var nødt til at afvise løsningen med ren SVG indsat i et dokument. Det efterlod os med to andre løsninger at vælge imellem.

Den video element var den anden mulighed. Vi startede med to problemer:

- gennemsigtig baggrund, som ikke kan anvendes med de mest populære videoformater som .mp4 eller .webm,

- responsivitet, hvilket var et reelt problem, fordi videoer ikke er skalerbare som sådan.
​
Vi besluttede at holde denne løsning i baghånden - "hvis vi ikke finder noget andet, vælger vi denne".

Den sidste mulighed var at bruge Lærred med WebGL gengivelse. Det var sådan en usædvanlig mulighed, fordi vi var nødt til at designe alle gengivelsesmekanikkerne selv. Det skyldes, at de morfiske bølger, vi havde, var brugerdefinerede - det tvang os til at designe en brugerdefineret løsning, og det var den mulighed, vi gerne ville følge og virkelig fokusere på.

Løsningens arkitektur

Lad os starte helt fra bunden. Hvad var det for et materiale, vi skulle bruge til at bygge disse bølger? Ideen var, at alle bølgerne var en SVG-fil i størrelsen 1×1 og specifikke stier placeret rundt om dette område. Animationen af denne SVG blev opbygget af nogle former for tilstande i denne fil. Så alle animationerne blev repræsenteret som et sæt filer, der indeholdt stadierne for at flytte en form.

Se nærmere på, hvad tilstandene er - alle stierne er bare en slags matrix med specifikke værdier placeret i en bestemt rækkefølge. Hvis man ændrer disse værdier i bestemte positioner inden for denne matrix, ændres formen i dens specifikke dele. Vi kan forenkle dette med følgende eksempel:


tilstand 1: [1, 50, 25, 40, 100].
tilstand 2: [0, 75, -20, 5, 120]
tilstand 3: [5, 0, -100, 80, 90]

Så vi kan antage, at den form, vi ønsker at gengive, består af et array med 5 elementer, der ændrer sig med den lineære lempelse i bestemte tidsperioder. Når animationen er færdig med det sidste trin, starter den igen med det første for at give os indtryk af en uendelig animation.

Men... vent - hvad er egentlig det array, der præsenteres ovenfor? Som jeg nævnte, er det en sti, der er ansvarlig for at vise en bestemt form. Al magien er inkluderet i d egenskab af SVG's sti. Denne egenskab indeholder et sæt "kommandoer" til at tegne en form, og hver kommando har en slags argumenter. Ovennævnte array består af alle de værdier (argumenter), der er knyttet til disse kommandoer.

Den eneste forskel mellem disse "tilstandsfiler" var værdier for specifikke kommandoer, da rækkefølgen af kommandoer var den samme. Så al magien bestod i at hente alle værdierne og animere dem.

Guiden hedder Fysik

I afsnittet ovenfor nævnte jeg, at det eneste magiske ved at animere et objekt er at skabe overgange mellem alle faser af en form. Spørgsmålet er, hvordan man gør det med canvas?
​
Den funktion, som alle, der arbejdede med Lærred bør vide er anmodningAnimationFrame. Hvis du ser dette for første gang, synes jeg oprigtigt, at du skal starte med at læse dette. Så det, vi er interesserede i med denne funktion, er argumentet - DOMHighResTimeStamp. Det ser virkelig skræmmende ud, men i praksis er det ikke så svært at forstå. Vi kan sige, at det er et tidsstempel for den tid, der er gået fra den første gengivelse.

Ok, men hvad kan vi gøre med det? Som den anmodningAnimationFrame funktion skal kaldes rekursivt, kan vi få adgang til et tidsdelta mellem dens kald. Og så er vi i gang med videnskaben! ⚛️ (ok, måske ikke raketvidenskab ... endnu)
​
Fysikken lærer os, at deltaet for en afstand er lig med deltaet for tiden ganget med hastigheden. I vores tilfælde er hastigheden konstant, fordi vi ønsker at nå slutpunktet inden for et bestemt tidsrum. Så lad os se på, hvordan vi kan repræsentere det med ovenstående tilstande:

Lad os sige, at vi ønsker at skifte mellem disse tilstande på tusind millisekunder, så hastighedsværdierne vil være følgende:


delta: [ -1, 25, -45, -35, 20].
hastighed: [-1/1000, 25/1000, -45/1000, -35/1000, 20/1000].

Hastigheden ovenfor fortæller os: For hvert millisekund øger vi værdien med -1/1000. Og her er det punkt, hvor vi kan gå tilbage til vores anmodningAnimationFrame og tidsdelta. Værdien af en bestemt position, som vi ønsker at øge med, er tidsdelta ganget med positionens hastighed. Endnu en ting, man kan opnå uden problemer, er at begrænse værdien, så den ikke overstiger den tilstand, den er på vej til.
​
Når overgangen slutter, kalder vi på en ny og så videre. Og det ser ikke ud til at være så svært at implementere, men en af hovedreglerne i softwareudvikling er ikke at bruge tid på ting, der allerede er implementeret. Så vi valgte en lille bibliotek der giver os mulighed for at skabe disse overgange på en ubesværet måde.
​
Sådan skabte vi en animeret bølge, der ligner et levende væsen.

Et par ord om kloning af figurer

Som du kan se, er Codest-mærkets bølger ikke en enkelt animeret figur. De består af mange figurer med samme form, men forskellig størrelse og position. I dette trin ser vi hurtigt på, hvordan man duplikerer på en sådan måde.
​
Så lærredskonteksten giver os mulighed for at skaleret tegneområde (under motorhjelmen - vi kan sige, at den multiplicerer alle dimensioner, der sendes til drawable-metoder, med "k", hvor "k" er en skaleringsfaktor, der som standard er sat til "1"), gør lærredet oversatDet er som at ændre ankerpunktet for et tegneområde. Og vi kan også springe mellem disse tilstande med disse metoder: gemme og genoprette.
​
Disse metoder giver os mulighed for at gemme tilstanden "nul modifikationer" og derefter gengive et bestemt antal bølger i loopet med korrekt skaleret og oversat lærred. Lige efter dette kan vi gå tilbage til den gemte tilstand. Det er alt om figurkloning. Det er meget nemmere end at klone får, ikke sandt?

Kirsebær på toppen

Jeg nævnte, at vi afviste en af de potentielle løsninger på grund af ydeevnen. Løsningen med canvas er ret hurtig, men ingen sagde, at den ikke kunne optimeres endnu mere. Lad os starte med det faktum, at vi egentlig er ligeglade med at overføre figurer, når de er uden for browserens visningsport.
​
Der er et andet browser-API, som programmørerne elskede. KrydsObserver. Det giver os mulighed for at følge specifikke elementer på siden og håndtere hændelser, der fremkaldes, når disse elementer vises eller forsvinder fra visningsvinduet. Lige nu har vi en ret nem situation - lad os skabe en synlighedstilstand, ændre den ved hjælp af IntersectionObserver event handlers og simpelthen slå renderingssystemet til og fra for bestemte figurer. Og ... bum, ydelsen er blevet meget bedre! Vi gengiver kun de ting, der er synlige i viewporten.

Sammenfatning

At vælge en måde at implementere ting på er ofte et svært valg, især når de tilgængelige muligheder ser ud til at have de samme fordele og ulemper. Nøglen til at træffe et korrekt valg er at analysere hver enkelt af dem og udelukke dem, vi ser som mindre fordelagtige. Ikke alt er klart - nogle løsninger kræver mere tid end de andre, men de er måske nemmere at optimere eller tilpasse.

Selvom der kommer nye JS-biblioteker næsten hvert minut, er der ting, de ikke kan løse. Og derfor bør alle frontend-ingeniører (og ikke kun dem) kende browser-API'er, holde sig ajour med tekniske nyheder og nogle gange bare tænke "hvordan ville min implementering af dette bibliotek se ud, hvis jeg skulle gøre dette?". Med mere viden om browsere kan vi bygge virkelig smarte ting, træffe gode beslutninger om de værktøjer, vi bruger, og blive mere sikre på vores Kode.

Læs mere om det:

– Ruby 3.0. Ruby og mindre kendte metoder til kontrol af privatlivets fred

– Hold kæft og tag dine penge #1: Skjulte omkostninger og ægte agilitet i produktudviklingsprocessen

– CTO-udfordringer - opskalering og vækst af softwareprodukter

Relaterede artikler

Udvikling af software

Byg fremtidssikrede webapps: Indsigt fra The Codest's ekspertteam

Oplev, hvordan The Codest udmærker sig ved at skabe skalerbare, interaktive webapplikationer med banebrydende teknologier, der leverer sømløse brugeroplevelser på tværs af alle platforme. Lær, hvordan vores ekspertise driver digital transformation og...

DENKODEST
Udvikling af software

Top 10 Letlands-baserede softwareudviklingsvirksomheder

Læs om Letlands bedste softwareudviklingsvirksomheder og deres innovative løsninger i vores seneste artikel. Find ud af, hvordan disse teknologiledere kan hjælpe med at løfte din virksomhed.

thecodest
Løsninger til virksomheder og scaleups

Grundlæggende om Java-softwareudvikling: En guide til succesfuld outsourcing

Udforsk denne vigtige guide til vellykket outsourcing af Java-softwareudvikling for at forbedre effektiviteten, få adgang til ekspertise og skabe projektsucces med The Codest.

thecodest
Udvikling af software

Den ultimative guide til outsourcing i Polen

Den voldsomme stigning i outsourcing i Polen er drevet af økonomiske, uddannelsesmæssige og teknologiske fremskridt, der fremmer it-vækst og et erhvervsvenligt klima.

TheCodest
Løsninger til virksomheder og scaleups

Den komplette guide til IT-revisionsværktøjer og -teknikker

IT-revisioner sikrer sikre, effektive og kompatible systemer. Lær mere om deres betydning ved at læse hele artiklen.

Codest
Jakub Jakubowicz CTO og medstifter

Tilmeld dig vores vidensbase, og hold dig opdateret om ekspertisen fra it-sektoren.

    Om os

    The Codest - International softwareudviklingsvirksomhed med tech-hubs i Polen.

    Storbritannien - Hovedkvarter

    • Kontor 303B, 182-184 High Street North E6 2JA
      London, England

    Polen - Lokale teknologiske knudepunkter

    • Fabryczna Office Park, Aleja
      Pokoju 18, 31-564 Kraków
    • Hjerneambassaden, Konstruktorska
      11, 02-673 Warszawa, Polen

      Codest

    • Hjem
    • Om os
    • Serviceydelser
    • Casestudier
    • Ved hvordan
    • Karriere
    • Ordbog

      Serviceydelser

    • Det rådgivende
    • Udvikling af software
    • Backend-udvikling
    • Frontend-udvikling
    • Staff Augmentation
    • Backend-udviklere
    • Cloud-ingeniører
    • Dataingeniører
    • Andet
    • QA-ingeniører

      Ressourcer

    • Fakta og myter om at samarbejde med en ekstern softwareudviklingspartner
    • Fra USA til Europa: Hvorfor beslutter amerikanske startups sig for at flytte til Europa?
    • Sammenligning af Tech Offshore-udviklingsknudepunkter: Tech Offshore Europa (Polen), ASEAN (Filippinerne), Eurasien (Tyrkiet)
    • Hvad er de største udfordringer for CTO'er og CIO'er?
    • Codest
    • Codest
    • Codest
    • Privacy policy
    • Vilkår for brug af hjemmesiden

    Copyright © 2025 af The Codest. Alle rettigheder forbeholdes.

    da_DKDanish
    en_USEnglish de_DEGerman sv_SESwedish nb_NONorwegian fiFinnish fr_FRFrench pl_PLPolish arArabic it_ITItalian jaJapanese ko_KRKorean es_ESSpanish nl_NLDutch etEstonian elGreek da_DKDanish