Share
I denne tredje delen av vår Chrome Utviklerverktøy-serie, vurderer vi hvordan du endrer og feilsøker JavaScript. Optimalisering er en viktig del av utviklingsprosessen, spesielt for ytelseskritiske applikasjoner. Vi diskuterer også teknikker for å identifisere potensielle flaskehalser i vår kode.
Som i de to foregående artiklene vil jeg fokusere på funksjonene som finnes i Chrome Canary-bygningen (versjon 26.0, av denne artikkelen). Jeg vil dekke kildene og tidslinjepanelene.
Kilden panelet er go-to plass for JavaScript feilsøking. Dette panelet, kombinert med konsollpanelet, gir et ekstremt kraftig verktøy! Det er et punkt-og-klikk-grensesnitt som lar deg pause JavaScript-kjøring og inspisere alle variablene og objektene i det nåværende omfanget.
Du kan finne det nyttig å redigere CSS og JavaScript i Developer Tools.
Accentsconagua
dette søkeord på de ulike stadiene av et JavaScript-program, kan du se de dette søkeord for å se sine forskjellige verdier over tid. Klikk på add-knappen for å legge til et uttrykk, og hvis et uttrykk ikke oppdateres, klikk på knappen for liten oppdatering ved siden av tilleggsknappen.Kategorien Kilder viser ressurser gruppert av underdomenet de blir servert fra. Hver ressurs har en kontekstmeny (avslørt ved å høyreklikke på ressursen) med et sett med vanlige alternativer. Ett alternativ er imidlertid veldig interessant: Lokale modifikasjoner, som vi ser på senere.
Merk: Du kan vise kildefillisten som en flat liste (dvs. ikke inneholdt i mapper gruppert av underdomene) ved å fjerne merket for "Vis mapper" i Innstillinger> Generelt.
Hvis du klikker på en ressurs, vises den i hovedinnholdsruden. Ikke glem å aktivere ganske utskriftsmodus for minifiserte ressurser, ettersom noen minifatorer omdøper variabler for å gjøre koden vanskeligere å forstå. Forhåpentligvis vil flere utviklere generere kildekart i fremtiden, noe som gjør det enklere å jobbe med minifisert kode.
Du kan redigere de fleste filer i hovedinnholdsruden, og disse endringene gjenspeiles umiddelbart i nettleseren. Når du har endret en ressurs, gir kontekstmenyen deg muligheten til å lagre (om ikke permanent) eller Lagre som (sparer en ny versjon lokalt). Når du arbeider med dine egne lokale nettsteder, kan det hende du finner det nyttig å redigere CSS og JavaScript i Developer Tools i stedet for IDE. Lagring av endringer, i dette tilfellet, endrer den faktiske kildefilen. Verktøy som Tincr eller Chrome-devtools-autosave kan hjelpe til med å automatisere denne arbeidsflyten.
Resursens kontekstmeny gir også muligheten til å avsløre ressursen i nettverkspanelet.
En revisjon er et nytt punkt innenfor en ressurs levetid, som den har blitt endret på. Redigering og lagring av kode fra kildepanelet skaper en ny revisjon, og stilendringer som gjøres i elementpanelet utløser faktisk en ny revisjon!
Etter at du har gjort noen endringer, kan du høyreklikke på ressursen og velge Lokale modifikasjoner. Dette åpner en ny lokal endringspanel som inneholder en diff av de opprinnelige og redigerte filene. I ruten Lokale modifikasjoner kan vi returnere en endret kildefil i sin helhet (nyttig for når du har gjort mange uønskede endringer) ved å klikke på "tilbakestill" ved siden av filnavnet.
Utviklerverktøy er snill nok til å varsle oss om potensielle optimaliseringer.
Hovedinnholdsruten har mange av funksjonene du vil finne i grunnleggende kodeditorer: linjenumre, syntaksutheving, muligheten til å lage tabulatorer og 'angre' funksjonalitet. Selv om det ikke samsvarer med en fullverdig IDE, er det ikke dårlig for rask redigering.
Breakpoints lar oss stoppe JavaScript-kjøring og inspisere det nåværende miljøet. For eksempel: anta at vi har en enkel til sløyfe som skyver elementer på en matrise. Vårt mål er å nøyaktig forstå de indre arbeidene innen hver iterasjon av løkken. Vi kunne veldig enkelt bruke console.log å logge på variablene vi vil inspisere. Mens denne teknikken gir deg de ønskede resultatene, er det absolutt ikke den mest effektive feilsøkingen. Ved å bruke breakpoints kan vi stoppe kodekjøring mens du er inne i til loop og inspiser alle variabler innenfor kontekstens omfang.
var ar = []; for (var i = 0; i < 3; i++) var num = i; arr.push(num);
For å legge til et brytepunkt, klikk på linjenummeret; Du kan også høyreklikke på linjenummeret og velge alternativet "Add Breakpoint". Etter at du har satt inn brytpunktet, oppdater siden og legg merke til at brytepunktene varer mellom sidelaster. Hvis koden ennå ikke skal utføres (for eksempel ble bruddpunktet satt inn i en klikkhendelseshåndterer), så kan du starte kodekjøringen uten en sideoppdatering.
Du kan vanskelig kode et brytepunkt i koden din ved å bruke debugger; uttalelse i koden din. Utviklerverktøy (og de fleste JavaScript-debuggere) gjenkjenner dette som et bruddpunkt.
Når du når et brytepunkt, teller siden grå og linjen med kode lyser blå. På dette punktet kan vi treffe escape-tasten for å vise konsollpanelet. Det som er interessant er at koden som er skrevet og utført i konsollen (mens den er pauset på et pausepunkt), faktisk utføres i den nåværende pausede konteksten! Vanligvis er dette søkeord refererer til den globale vindu gjenstand; mens visning dette i en klikk Hendelseshåndterer viser verdien som hendelsesmålet (et element).
I skjermbildet over er den grå delen selve dokumentet, og Utviklerverktøy markerte gjeldende linje med JavaScript. I konsollen ser du resultatene av inspeksjon av noen få variabler. Og til høyre for innholdsruten er "Scope Variables" -ruten, hvor du kan inspisere alle variablene og objektene i det nåværende omfanget.
Betingede bruddpunkter lar deg bryte når en viss tilstand er sant.
I ruten til høyre i panelet Kilder merker du XHR-brytepunkt-fanen. Klikk på "Add XHR Breakpoint" på ditt favoritt Ajax-aktiverte nettsted. Hvis du forlater feltet "URL inneholder", er tomme pauser på noen XHR be om.
Dette gir utviklere nye og kraftige muligheter. Vi kan navigere til et nettsted vi ikke har bygget, eller har hatt noe med, og bare start feilsøkingskode basert på visse hendelser og kriterier. Så pauser på Ajax-forespørsler er fint, men hvilke andre hendelser kan vi bryte på?
Kilden panelet har et pek og klikk-grensesnitt for å sette breakpoints som matcher bestemte hendelse lyttere. Vær oppmerksom på at brudd på en bestemt hendelse bare virker når den aktuelle siden lytter etter den hendelsen. Hvis vi bryter på Kontroll> Endre størrelse arrangement, som har kode som følgende, sikrer at koden bryter når hendelsen brenner:
window.onresize = funksjon (e) console.log (e); ;
Så, når bryter på bestemte hendelser som er nyttige?
Breakpoints fortsetter mellom sidelaster.
DOM Breakpoints-fanen viser breakpoints for DOM. En enkel måte å se dette på, er å finne et element som for eksempel når det er klikket, har det klassenavn eiendom endret. Finn elementet i element-panelet, høyreklikk det og gå til Bryt på> Egenskaper Modifikasjoner. Koden vil nå brytes når elementets attributters verdier endres.
document.querySelector ('# button'). onclick = funksjon () this.setAttribute ('noen', 'ting'); ; De ved trykk Hendelseshåndterer over teller som en attributtmodifisering, noe som presenterer noe som ligner dette:
Andre alternativer inkluderer:
element.remove ().Merk: Chrome ser ut til å ha implementert fjernmetoden (). Noen nettlesere støtter ikke denne metoden. så, removeChild () må brukes i stedet.
Tidslinjepanelet er hvor du undersøker webappens ytelsesproblemer. Tidslinjepanelets primære formål er (når det skrives) for visning av informasjon, i motsetning til de andre panelene som lar deg utføre ødeleggende handlinger på siden.
Tider du kanskje vil bruke Timeline-panelet inkluderer:
Du kan vanskelig kode et brytepunkt i koden din ved å bruke
debugger;uttalelse i koden din.
I del 2 kan du huske hvordan vi begynte å ta opp nettverksinformasjon før siden lastet for å fange så mange nettverksforespørsler som mulig. Vi gjør det ikke i tidslinjepanelet; Det er bedre å registrere korte og spesifikke hendelser. Vi trenger ikke nødvendigvis * gjøre * noe. Vi kunne legge det innspillingen for å se hva som skjer når brukeren er inaktiv, eller om noen timere kan kjøre i bakgrunnen.
Hendelsene, rammene og minnekortene er fylt under opptak; så vær sikker på å se gjennom dem for å finne de dataene du trenger. Minneseksjonen kan hjelpe deg med å fange potensielle minnelekkasjer.
Opptak vises under og etter opptak. En god del data blir tatt inn i postene, som vist i det følgende bildet.
Dette skjermbildet viser noen nettverksforespørsler (blå), og noen "omberegne stiler" (lilla). Style omberegninger kan skje av en rekke årsaker. De gule postene er skript, og den grønne representerer sidegengivelse.
Hvis du klikker på eller svever over en plate, vises mer informasjon. For eksempel kan sveve over en "maling" -plate vise deg den delen av siden som ble malt.
Utviklerverktøy vil noen ganger koble en plate til et annet panel. For eksempel leder et bildes kobling til ressurspanelet med bildet i fokus, og en XHR-plate kan knytte til den tilsvarende oppføringen i nettverkspanelet.
Utviklerverktøy er snill nok til å varsle oss om potensielle optimaliseringer. Legg merke til det lille varselikonet til høyre for noen av postene i bildet nedenfor. Hvis det er bleknet, må du bore ned for å finne den faktiske platen som inneholder den nyttige informasjonen.
Popovers inneholder noen ganger en kobling til linjen med kode som forårsaket at posten skal vises. Men et advarselsvarsel: pen utskrift vil ikke alltid hjelpe - spesielt når man ser på tredjepartskode. Et alternativ er å sette et bruddpunkt på linjen du er tatt til. Når debuggeren har stoppet, kan du se variabelenes innhold for bedre å forstå kodeksens hensikt.
Hvis du er som meg, ender du alltid med å fange opp mer data enn du trenger, men du kan danne et valg over de vertikale linjene (rammer) som bare viser postene som svarer til den valgte delen.
Hvis du bare bryr deg om lange poster, så sett et filter for å bare vise de lange postene. Du kan gjøre dette nederst på tidslinjepanelet.
Hvis rulling ikke føles så glatt som det burde, bør du vurdere å ekskludere 'Loading' (for eksempel nettverksposter). Når det blir sagt, hvis du vet at nettverksforespørsler brukes til å laste inn data på en side som brukerne uendelig ruller, vil du holde 'Laste inn' merket.
Ikke bruk filtrering bare fordi dataene vises for intense først. Ta deg tid til å forstå og undersøke hva dev-verktøyene viser deg. Du vil bruke tidslinjen for å bekrefte hvor avmatningene forekommer og sikte på å få de vertikale strekkene så tomme som mulig (hvitt mellomrom / tomgangstid).
Hovedinnholdsruten har mange av funksjonene du vil finne i grunnleggende kodeditorer.
Vet du om andre nyttige ressurser? Nevn det i kommentarene!
