Veebibrauseri mootorid – mis need on ja mis need on. Opera kolis just WebKiti. Mis sellest saab

  • Tõlge

Paljude meist arendajate jaoks WebKit – must kast. Me viskame sinna HTML-i, CSS-i, JS-i ja hunniku pilte ning WebKit annab kuidagi... võluväel meile veebilehe, mis näeb välja ja töötab hästi.
Aga tegelikult, kuidas ütleb kolleeg Ilja Grigorik :

Veebikomplekt ei ole must kast. See on valge kast. Ja mitte ainult valge, vaid ka avatud kasti.

Niisiis, proovime välja mõelda mõned asjad:
  • Mis on WebKit?
  • Mis ei ole WebKit?
  • Kuidas WebKiti kasutavad WebKiti brauserid?
  • Miks paljud WebKitid ei ole samad?
Nüüd, eriti pärast uudist, et Opera läks üle WebKitile, ümbritseb meid palju WebKiti brausereid ning on üsna raske öelda, mis neid ühendab ja kuhu nad oma teed lähevad. Allpool loodan, et püüame sellele probleemile veidi valgust heita. Selle tulemusel saate paremini tuvastada brauseri erinevusi, esitada vead õigele jälgijale ja teha brauseritevahelist arendust tõhusamalt.

Standardsed veebibrauseri komponendid

Loetleme mõned kaasaegsete brauserite komponendid:
  • Parsimine (HTML-i, XML-i, CSS-i, Javascripti sõelumine)
  • Paigutus
  • Teksti ja graafika renderdamine
  • Pildi dekodeerimine
  • Koostoimed GPU-ga
  • Juurdepääs võrgule
  • Riistvaraline kiirendus
Millised neist on kõigi WebKiti brauserite jaoks ühised? Peaaegu ainult kaks esimest.

Iga WebKiti port rakendab ülejäänud komponendid erinevalt. Mõelgem välja, mida see tähendab.

WebKiti pordid

WebKiti porte on palju ja ma pakun Ariya Hidayati, WebKiti häkkerit ja tehnikat. Sencha direktoril on õigus sellest rääkida:

Kõige populaarsem seos WebKiti kontseptsiooniga on tavaliselt Apple'i WebKiti versioon, mis töötab operatsioonisüsteemis Mac OS X (esimene ja originaalne WebKiti teek). Nagu võite arvata, on erinevad liidesed juurutatud mitmesuguste Mac OS X-i natiivsete teekide abil, peamiselt fokuseeritud komponendis CoreFoundation. Näiteks kui määrate kindla kontuuriraadiusega värvilise lame nupu, teab WebKit, kuhu ja kuidas see nupp joonistada. Samal ajal nupu lõplik renderdus (pikslitena kasutaja monitoril ) langeb CoreGraphicsile.

Nagu ma eespool mainisin, on kasutatav CoreGraphics iga WebKiti pordi jaoks unikaalne. Näiteks Chrome for Mac kasutab Skiat.

Mingil hetkel "portiti" WebKit erinevatele platvormidele, nii lauaarvutitele kui ka mobiilidele. Seda variatsiooni nimetatakse tavaliselt "WebKiti pordiks". Safari Windowsi jaoks "portis Apple WebKiti" iseseisvalt, et Windowsis töötaks, kasutades selle (piiratud juurutusega) CoreFoundationi teeki.

...vaatamata asjaolule, et Windowsi Safari on nüüd surnud.
Peale selle oli ka palju muid "porte" (vt täielikku nimekirja). Google on loonud oma Chromiumi pordi ja toetab seda jätkuvalt. Samuti on olemas WebKitGtk, mis põhineb Gtk+-l. Nokia (ja nüüd selle välja ostnud Trolltech) toetab WebKit Qt porti, mis on muutunud populaarseks QtWebKiti moodulina.

Mõned WebKiti pordid

  • Safari
    - Safari for OS X ja Safari for Windows on kaks erinevat porti
    - WebKiti öine ehitamine on Maci lähtekoodi "pordi" järg, mida kasutatakse Safari jaoks, ainult uuem.
  • Mobiilne Safari
    - Arendati erafiliaalis, kuid avati hiljem.
    - Chrome iOS-ile (kasutab Apple'i WebView'd; erinevuste kohta lisateavet hiljem)
  • Chrome (Chromium)
    - Chrome Androidile (kasutab otse Chromiumi porti)
    - Chromium on ka brauserite alus: Yandex, Sogou ja peagi ka Opera.
  • Androidi brauser
    - Kasutab uusimat WebKiti lähtekoodi, mis on avaldamise ajal saadaval.
  • Veelgi rohkem porte: Amazon Silk, Dolphin, Blackberry, QtWebKit, WebKitGTK+, The EFL port (Tizen), wxWebKit, WebKitWinCE jne
Erinevad pordid võivad keskenduda erinevatele ülesannetele. Maci pordi fookuses on brauseri ja operatsioonisüsteemi eraldamine ning Obj-C ja C++ sidemete pakkumine renderdusmootori algrakendustesse manustamiseks. Chromiumi pordi fookus on täielikult brauseril. QtWebKit pakub oma porti kasutamiseks koos platvormideülese rakenduse arhitektuuriga renderdusmootorina.

Mis on ühist kõigil WebKiti brauseritel?

Kõigepealt vaatame üldisi funktsioone, mida kasutatakse kõigis WebKiti brauserites:

Teate, et see on naljakas, ma proovisin seda lõiku mitu korda kirjutada. Ja nagu näete, parandasid Chrome'i meeskonna liikmed mind iga kord...

  1. Ja nii, esiteks parsib WebKit HTML-i samal viisil. Noh, välja arvatud see, et Chromium on hetkel ainus port, mis sisaldab HTML-i sõelumise lõimede tuge.
  2. ... Olgu, aga pärast HTML-i sõelumist konstrueeritakse DOM-puu samamoodi. Noh, tegelikult on Shadow DOM lubatud ainult Chromiumi pordi jaoks, mis tähendab, et DOM-i konstruktsioon on erinev. Ka kohandatud elementide jaoks.
  3. …Olgu, WebKit loob akna- ja dokumendiobjektid kõigile ühtemoodi. Tõsi, kuigi nende pakutavad omadused ja konstruktsioonid võivad sõltuda funktsioonilippude kasutamisest.
  4. ... CSS-i sõelumine on sama. CSS-i söömine ja selle CSSOM-iks muutmine on üsna tavaline. Jah, kuigi Chrome toetab ainult -webkit- eesliiteid, kui Apple ja teised brauserid toetavad pärandprefikseid -khtml- ja -apple-.
  5. ...Paigutus...positsioneerimine? See on nagu leib ja või. See on igal pool sama, eks? No juba! Subpikslite paigutus ja rikkaliku paigutuse aritmeetika on WebKiti osa, kuid erinevad porditi.
  6. Super.

Niisiis, see on raske.

Proovime nüüd kokku võtta, mis on WebKiti maailmal ühist...

Mis on ühine iga WebKiti pordi jaoks.

  • DOM, aken, dokument
    Rohkem või vähem
  • CSSOM
  • CSS-i sõelumine, atribuut/väärtus
    erinevused tootja eesliidetes
  • HTML-i sõelumine ja DOM-i loomine
    See on sama, kui unustame veebikomponendid.
  • Paigutus ja positsioneerimine
    Flexbox, Floats, plokkide vormindamise kontekst... kõik on tavaline
  • Kasutajaliidese tööriistad ja arendaja tööriistad, nt Chrome DevTools ehk WebKiti inspektor.
    Kuigi alates eelmise aasta aprillist on Safari kasutanud oma suletud lähtekoodiga mitte-WebKiti Safari Inspectorit.
  • Sellised funktsioonid nagu sisu redigeeritav, pushState, faili API, enamik SVG-d, CSS-i teisendusmatemaatika, veebiheli API, kohalik salvestus
    Kuigi rakendamine võib erineda. Iga port saab kohaliku salvestuse jaoks kasutada oma salvestussüsteemi ja Web Audio API jaoks erinevat heli API-d.
See muutub veidi segaseks, nii et proovime vaadata mõningaid erinevusi.

Nüüd, mis ei ole WebKiti portide jaoks tavaline:

  • Kõik, mis on seotud GPU-ga
    - 3D teisendus
    - WebGL
    - Video dekodeerimine
  • 2D renderdamine ekraanile
    - Antialiase tehnoloogiad
    - SVG ja CSS-i gradientide renderdamine
  • Teksti renderdamine ja sidekriipsutus
  • Võrgutehnoloogiad (SPDY, eelrenderdamine, WebSocket transport)
  • JavaScripti mootor
    - JavaScriptCore mootor asub WebKiti hoidlas. Kuid WebKitis on köited nii selle kui ka V8 jaoks.
  • Vormi elementide renderdamine
  • Video- ja helisiltide käitumine ning kodeki tugi
  • Pildi dekodeerimine
  • Navigeerimine tagasi/edasi
    - osa pushState()
  • SSL-i funktsioonid, nagu range transpordi turvalisus ja avaliku võtme PIN-koodid
Vaatame ühte neist: 2D graafika Olenevalt pordist kasutame ekraanile renderdamiseks täiesti erinevaid teeke:

Või kui minna üksikasjalikumalt, siis hiljuti lisatud funktsioon: CSS.supports() on lubatud kõigi portide jaoks, välja arvatud win ja wincairo, millel pole css3 tingimuslikke funktsioone lubatud.

Nüüd on meil tehniline... aeg pedantseks muutuda. Isegi see, mis eespool öeldi, pole täiesti õige. See on tegelikult WebCore, üldine komponent. WebCore on HTML-i ja SVG paigutuse, renderduse ja DOM-i teek ning see on põhimõtteliselt see, millele inimesed mõtlevad, kui nad ütlevad WebKit. Tõepoolest, "WebKit" on tehniliselt WebCore'i ja "portide" vaheline sidemete kiht, kuigi tavavestluses on see eristamine suures osas ebaoluline.

Diagramm peaks aitama:

Paljud WebKiti komponendid on lülitatavad (näidatud halliga).

Näiteks WebKiti JavaScripti mootor JavaScriptCore on WebKiti vaikemootor. See põhineb algselt KJS-il (KDE-st) aegadest, mil WebKit sai alguse KHTML-i hargina. Samal ajal lülitub Chromiumi port V8 mootorile ja kasutab ainulaadseid DOM-i sidemeid.

Fondid ja teksti renderdamine on platvormi väga suur osa. WebKiti teksti jaoks on kaks erinevat teed: Quick ja Hard. Mõlemad nõuavad platvormipõhist tuge (rakendatud pordi poolel), kuid Fast peab teadma, kuidas kustutada glüüfe (mida WebKit platvormi jaoks vahemällu salvestab), samas kui Complex viib stringi renderdamise täielikult platvormi tasemele ja ütleb lihtsalt "joonista see, palun."

„WebKit on nagu võileib. Muidu on see Chromiumi puhul pigem taco. Maitsev taco veebitehnoloogiatest.
Dmitri Glazkov, Chrome WebKiti häkker. Veebikomponentide meister ja varidom.

Laiendame nüüd ülevaadet ja vaatame mitut porti ja mitut alamsüsteemi. Allpool on viis WebKiti porti, pange tähele, kuidas igaühe tööriistakomplekt erineb hoolimata ühistest komponentidest.

Chrome (OS X) Safari (OS X) QtWebKit Androidi brauser Chrome iOS-ile
Renderdamine Skia CoreGraphics QtGui Android stack/Skia CoreGraphics
Võrgustiku loomine Chromiumi võrgupinn CFNetwork QtNetwork Fork of Chromiumi võrgupinn Kroomi virn
Fondid CoreText Skia kaudu CoreText Qt sisemised osad Androidi virn CoreText
JavaScript V8 JavaScriptCore JSC (V8 kasutatakse mujal Qt-s) V8 JavaScriptCore (ilma JIT-ita) *

* Joonealune märkus iOS-ile mõeldud Chrome'i kohta. See kasutab UIWebView-d, nagu te ilmselt teate. Vastavalt UIWebView võimalustele tähendab see, et see saab kasutada ainult sama renderdusmootorit nagu Mobile Safari, JavaScriptCore (mitte V8) ja ühe lõimega mudelit. Mõni kood on siiski Chromiumilt laenatud, näiteks võrgu alamsüsteem, järjehoidjate sünkroonimise infrastruktuur, omnikastike, mõõdikud ja krahhiaruanded. (Samuti on JavaScript mobiilseadmetes nii harva kitsaskohaks, et JITtingi kompilaatori puudumisel on minimaalne mõju.)

Olgu, kust me tuleme?

Ja nii on kõik WebKitid nüüd täiesti erinevad. Ma kardan.

Ei ole seda väärt! WebKiti "layoutTesti" testide katvus on tohutu. (28 000 testi lõpuks) ja mitte ainult olemasolevate funktsioonide, vaid ka kõigi leitud regressioonide jaoks. Tegelikult, kui õpite uusi või "salajaste" DOM/CSS/HTML-5 funktsioone, on "layoutTesti" testikomplektidel tavaliselt suurepärane minimaalne demo.

Lisaks teeb W3C jõupingutusi testikomplekti standardimiseks. See tähendab, et võime eeldada, et nii WebKiti porte kui ka kõiki teisi brausereid testitakse samade testkomplektidega, mis toob kaasa vähem veidrusi ja koostalitlusvõimelisema veebi. Kõigile, kes pingutavad, osaledes üritusel Test The Web Forward...aitäh!

Opera kolis just WebKiti. Mis sellest saab?

Robert Nyman ja Rob Hawkes on seda teemat juba puudutanud, kuid lisan, et teadaande üks oluline osa oli see, et Opera lülitub üle Chromiumile. See tähendab, et WebGL, Canvas, HTML5 vormid, 2D-graafika rakendamine, kõik need asjad on nüüd Chrome'is ja Operas samad. Sama API ja madala taseme juurutus. Kuna Opera põhineb Chromiumil, võite tunda, et vähendate oma töökoormust, et kontrollida Opera ja Chrome'i ühilduvust.
Peaksin ka seda märkima Kõik Opera brauserid lülitatakse üle Chromiumile. See tähendab, Opera for Windows, Mac, Linux ja Opera Mobile (täisväärtuslik mobiilibrauser). Isegi Opera Mini, õhuke klient, vahetatakse praeguselt Prestol põhinevalt renderdusfarmilt Chromiumil põhinevale renderdusfarmile.

... ja igaõhtune WebKiti ehitamine. Mis see on?

See on WebKit, mis töötab sama koodiga kui Safari (kuigi mõnda sisemist teeki on muudetud). Seda haldab suures osas Apple, nii et käitumine ja funktsioonide komplekt on kooskõlas sellega, mida leiate Safarist. Paljudel juhtudel on Apple konservatiivne, kui on vaja lisada funktsioone, mida teised pordid rakendavad või millega katsetavad. Igatahes, kui kasutada analoogiat, mõelge sellele kui... igaõhtune WebKiti koostamine Safari jaoks on nagu Chromium Chrome'ile.
  • veebibrauserid
  • Veebiarendus
  • Lisa märksõnu

    Selles artiklis vaatleme kolme populaarsel WebKiti mootoril põhinevat brauserit. Veebibrauseri valimisel kipuvad kasutajad vaatama kõige kuulsamaid programme: Google Chrome, Opera, Mozilla Firefox, Internet Explorer. Samas paljud unustavad või ei tea, et Firefox, Chrome ja viimasel ajal ka Opera on loodud avatud lähtekoodiga projektide alusel, mis tähendab, et neid programme saab muuta.

    See võimalus toob kaasa asjaolu, et paljud programmeerijad on loonud mitmeid populaarsete brauserite analooge, mis pakuvad üsna huvitavaid funktsioone. Niisiis, vaatame mitut sellise tarkvara esindajat.

    Seda levitatakse tasuta, sellel on vene liides, see töötab Windowsis, Androidis, Macis, iOS-is. See brauser oli kümme aastat tagasi tuntud kui MyIE2 ja see oli Internet Exploreri täiendus, kuid sellest ajast on palju muutunud ja nüüd kasutab programm vaikimisi Webkiti mootorit.

    Viimases, 4. versioonis pakub brauser mitmeid kasulikke funktsioone, mille hulgas on kõige huvitavam võimalus salvestada teavet pilve. See võimaldab kasutada oma kontot programmis teabe edastamiseks erinevate seadmete vahel, olgu selleks siis Androidi vidin, Apple’i kampaaniatoode või lauaarvuti.

    Kuigi Maxthon Cloud Browseri liides on tehtud Chrome'i stiilis, on sellel palju rohkem funktsioone. Külgribal kuvatakse laiendustele juurdepääsu ikoone. Mugav on, et ühe klõpsuga saate kõik installitud lisandmoodulid keelata või lubada ning uusi saate spetsiaalselt veebisaidilt alla laadida.

    Seda levitatakse tasuta, sellel on vene liides ja see töötab Windowsis. Comodo toode, mis on rohkem tuntud turvatarkvara arendajana. Comodo Dragon pole enam arendus, vaid konstruktsioon, kuna selle funktsionaalsus ei erine Chrome'ist palju.

    Algsest brauserist pole palju erinevusi ja need kõik on seotud turvaprobleemidega. Esimene oluline erinevus Google Chrome'ist on tõeliselt inkognito režiim, Comodo Dragon ei kasuta unikaalset kasutajatunnust ja HTTP-REFERRERit, mis ei võimalda kasutajat võrgus jälgida.

    Teine erinevus seisneb Comodo põhitegevuses – kasutajate turvalisuses. Eeldab oma turvaliste DNS-serverite olemasolu liikluse edastamiseks. Pealegi võib kasutaja soovil neid läbida liiklus mitte ainult Dragonist, vaid ka kõigist teistest rakendustest. Turvalised DNS-serverid blokeerivad automaatselt juurdepääsu saitidele, mille Comodo patenteeritud veebiohtude tuvastamise võrk on märkinud ebausaldusväärseks.

    Seda levitatakse tasuta, sellel on vene liides ja see töötab Windowsis. “Yandex.Browser” on hiljuti välja antud brauser, mis põhineb Chromiumil Vene ettevõttelt Yandex. Selles tootes lisasid arendajad lihtsalt kiirlinkide paneelile Yandexi teenused. Samuti lisati ja täiustati režiimi "Turbo", mis on saadaval Operas. Üldiselt pole see halb brauser, mis on suunatud Yandexi kasutajatele.

    Brauseri mootor on spetsiaalne programm, mis töötab veebilehtedega. See töötleb Internetist alla laaditud HTML-lehte ja teisendab selle koodi kasutajatele tuttavaks esitluseks. Interneti-brauseri mootoreid kasutatakse nii brauserites endis kui ka meiliklientides. Mitte iga veebibrauser pole ehitatud oma ainulaadsele platvormile. Paljud neist kasutavad populaarseid ja ajaproovitud lahendusi. Selles artiklis uuritakse, millised platvormid on olemas brauserite loomiseks ja mille poolest need üksteisest erinevad.

    Renderdusmootorite kasutamisel brauserite loomiseks on palju eeliseid.

    • Muudab koodivigade leidmise ja parandamise lihtsamaks.
    • Mugav võimalus ühe komponendi täiustamiseks mitmes programmis korraga.
    • Rakenduse graafilise liidese muutmise protsess on lihtsustatud.
    • Uute programmide loomise lihtsus vastavalt konkreetse arendaja soovidele või konkreetse kasutaja vajadustele.

    Selliseid lahendusi kasutatakse väga sageli programmeerimisel: videomängude loomisel, keerukate programmide operatsioonisüsteemide jms loomisel. Mõned spetsialistid tegelevad mootori täiustamise ja optimeerimisega, lisavad sellesse uusi funktsioone ja kasulikke funktsioone. Teised tegelevad arendatud platvormi põhjal ise programmide loomisega.

    Ilmekas näide on Microsofti Trident mootor. Seda üksi kasutatakse selle ettevõtte paljudes rakendustes. Sihtasutuse arenedes arenevad ka tuletisprojektid.

    Igal lahendusel on oma plussid ja miinused. Näiteks märkavad paljud kasutajad, et Mozilla Firefox töötab palju paremini, kui avatud on rohkem vahekaarte kui tema konkurendid. See on brauseri aluseks oleva platvormi saavutus.

    Kolmhark

    Kui kasutaja installib uue Windowsi operatsioonisüsteemi, on esimene veebibrauser Internet Explorer. Seetõttu käsitletakse selle mootorit ülevaates esimesena.

    Trident ehk MSHTML on Microsofti poolt oma vajadusteks välja töötatud üsna vana tarkvarakomponent. Projekt on pidevalt arenenud alates 1997. aastast. Kasutatakse Microsofti veebibrauseris - Internet Explorer, Outlooki meiliklient, Windows Explorer (failidega töötamise programm) ja paljud teised selle arendaja rakendused.

    Kasutajad peavad seda üheks kõige ebaõnnestunumaks brauserimootoriks. See ei toeta kolmanda osapoole modulaarseid laiendusi - pistikprogramme, kuvab paljusid Interneti-lehti valesti ja sellel pole kõige kiiremat töökiirust.

    Windows 10 väljalaskmisega arenes platvorm Trident EdgeHTML-iks.Arendajad võtsid aluseks vananenud ebaõnnestunud mootori ja lõid uue, mis vastab kõigile kaasaegsete kasutajate nõuetele. Võrdlusnäitajate (tarkvara jõudluse ja kiiruse test) järgi otsustades on Microsoft Edge (EdgeHTML-i baasil loodud brauser) järele jõudnud ja isegi ületanud populaarseid Google Chrome'i ja Mozilla Firefoxi brauserite loomisel kasutatud programme.

    Geko

    Gecko on mootor, mida kasutatakse populaarses Interneti-brauseris Mozilla Firefox ja paljudes teistes programmides. Programmi lähtekood on vabalt saadaval, st igaüks saab täiesti tasuta luua oma brauseri või meilikliendi Gecko baasil.

    Geko teine ​​eelis on platvormideülene. See töötab enamikus kaasaegsetes operatsioonisüsteemides: nii personaalarvutite kui ka mobiilseadmete jaoks (erinevalt Internet Explorerist, mis töötab ainult Windows OS-is).

    Gecko toetab kõiki kaasaegseid standardeid ja tehnoloogiaid, mida veebisaitide loomiseks kasutatakse. See on üks kahest populaarseimast brauseriplatvormist. Toetab pistikprogrammide ühendamist. Võrdlused ja kasutajate isiklikud kogemused näitavad, et sellel mootoril põhinevad brauserid tarbivad kõige vähem personaalarvuti ressursse ja töötavad usaldusväärselt suure hulga vahekaartidega (näiteks mitusada).

    Geco baasil luuakse populaarne Interneti-brauser Mozilla Firefox, Thunderbirdi meiliklient, Sunbirdi ülesannete planeerija, aga ka anonüümne veebibrauser, millel on sisseehitatud Tor VPN-tehnoloogiate tugi.

    KHTML

    Vähetuntud platvorm, mida kasutatakse KDE failihalduri Konquerori loomiseks. Kasutajate jaoks, kes pole Linuxi perekonna operatsioonisüsteemidega kursis, on huvitav, et selle projekti põhjal loodi maailma populaarseim mootor, mida arutatakse edasi.

    WebKit

    Selle mootori töötas välja maailmakuulus Apple'i korporatsioon, mis põhineb ülalmainitud lahendusel - KHTML. See 2001. aastal välja antud projekt on tohutult arenenud ja muutunud üheks enimkasutatavaks maailmas.

    WebKiti põhjal loodi Safari veebibrauser, mida kasutatakse vaikimisi iOS-i seadmetes ja mis on brauserite seas populaarsuse liider - Google Chrome. Valdav hulk kaasaegseid programme veebilehtede sisu töötlemiseks põhinevad WebKitil. Lisaks kasutatakse seda populaarses Steami rakenduses, mis on mõeldud Valve arvutimängude digitaalseks levitamiseks.

    Sarnaselt Geckole on WebKit platvormideülene ja töötab suurepäraselt kõigil populaarsetel platvormidel. Näitab kõrget stabiilsust ja jõudlust. Selle tohutu populaarsuse tõttu töötatakse selle lahenduse jaoks välja valdav enamus laiendusi. Kasutatakse ka populaarsetel mobiiliplatvormidel, nagu Android ja iOS. See on tasuta mootor, mis tähendab, et igaüks saab seda tasuta kasutada oma rakenduste loomiseks.

    2013. aastal eraldus WebKitist uus Google'ile kuuluv haru Blink. See projekt oli Chrome'i versiooni 28 (ja kõigi järgnevate versioonide) ning selle avatud lähtekoodiga venna Chromiumi aluse. Venemaal populaarse Yandexi brauseri loomiseks kasutati kroomi. Alates versioonist 15 läks ka Opera brauser üle Blinkile.

    Presto

    2003. aastal loodud Presto brauserimootor oli Opera aluseks. Arendatud üle 10 aasta. 2013. aastal otsustasid Opera arendajad loobuda Presto kasutamisest Google'i võimsama ja populaarsema Blinki kasuks. Hetkel on projekti arendus peatatud.

    Kas artikkel oli kasulik?

    Mis on Webkit?

    Mootori põhjal loodi brauserid nagu Midori, Maxthon, Konqueror, Arora jt. Kuid Webkiti ei vali ainult vähetuntud brauserid. Tutvustame teie tähelepanu kahte brauserite maailma "hiiglast" - Apple'i Safari ja Google'i Chrome'i (need brauserid). On ebatõenäoline, et keegi vaidleks, et nendel brauseritel on vähe funktsionaalsust ja madal töökiirus. Lisaks lauaarvuti brauseritele on Webkit tunginud ka mobiiliplatvormidele, mis kinnitab taaskord tasuta tarkvara eeliseid. Seda mootorit kasutab edukalt sama Safari Mobile, mis on välja töötatud iOS-i jaoks. Webkitile on ehitatud ka standardsed brauserid Androidi, HP WebOS-i ja Samsung Bada platvormidele.

    See on mootor, mille põhjal on välja töötatud palju brausereid. See on üsna kiire ja kerge ning saab suurepäraselt hakkama kõigi veebikeskkonnas aktsepteeritud standarditega.

    Kõige selle juures on see mootor vabalt levitatav tarkvara. Need on komponendid, mis võimaldasid sellel brauseri arendajate seas väga populaarseks saada.

    Webkiti ajalugu

    Võib-olla olete mõelnud: "Miks tasuta tarkvara?" Vaatame selle loomise ajalugu. Webkiti vanem on ka vabalt levitatav mootor, mida arendatakse Unixi perekonna süsteemide graafilise keskkonna jaoks. Seda mootorit nimetatakse KDE-ks. 1998. aastal otsustas KDE kallal töötav programmeerijate meeskond selle graafilise keskkonna jaoks oma brauseri välja anda.

    Sellise brauseri lasid välja ja andsid sellele nime Konquerori loojad. Selle brauseri aluseks oleva mootori nimi oli KHTML. 3 aastat hiljem, 2001. aastal, otsustas Apple luua oma brauseri, mille jaoks kasutas KHTML-i allikaid, aga ka KJS JavaScripti mootorit. Selle sünteesi tulemusena loodi Webkiti projekt Apple'i "tiiva" all. Selle põhjal ilmus 2003. aasta alguses Apple'i brauseri esimene versioon - .

    Ka teine ​​infotehnoloogiamaailma “koletis”, Google, võttis oma brauseri loomisel Webkiti aluseks. Ja see on veel üks pluss mootori eelistele. Kuna Google otsustas, et ta on nende jaoks õige, ütleb see palju. Arendajad ise väitsid, et jalgratast otsustati mitte uuesti leiutada, sest Webkit vastab täielikult ettevõtte kõrgetele veebikeskkonnastandardite toetamise nõuetele ja ka üsna suurele töökiirusele.

    Tänapäeval jätkab mootor aktiivset arengut ja sellel on suured väljavaated. See pole ime, sest nii Apple kui ka Google töötavad selle täiustamise nimel. Ja see on lisaks ametlikele mootoriarendajatele. Need omakorda teatasid, et neil on käsil töö, mille tulemuseks on nende toote teise põlvkonna väljalaskmine, mille eripäraks on eraldi protsesside sisseehitatud arhitektuur (täna on see rakendatud ainult aastal).

    • Tõlge

    Paljude meist arendajate jaoks WebKit – must kast. Me viskame sinna HTML-i, CSS-i, JS-i ja hunniku pilte ning WebKit annab kuidagi... võluväel meile veebilehe, mis näeb välja ja töötab hästi.
    Aga tegelikult, kuidas ütleb kolleeg Ilja Grigorik :

    Veebikomplekt ei ole must kast. See on valge kast. Ja mitte ainult valge, vaid ka avatud kasti.

    Niisiis, proovime välja mõelda mõned asjad:
    • Mis on WebKit?
    • Mis ei ole WebKit?
    • Kuidas WebKiti kasutavad WebKiti brauserid?
    • Miks paljud WebKitid ei ole samad?
    Nüüd, eriti pärast uudist, et Opera läks üle WebKitile, ümbritseb meid palju WebKiti brausereid ning on üsna raske öelda, mis neid ühendab ja kuhu nad oma teed lähevad. Allpool loodan, et püüame sellele probleemile veidi valgust heita. Selle tulemusel saate paremini tuvastada brauseri erinevusi, esitada vead õigele jälgijale ja teha brauseritevahelist arendust tõhusamalt.

    Standardsed veebibrauseri komponendid

    Loetleme mõned kaasaegsete brauserite komponendid:
    • Parsimine (HTML-i, XML-i, CSS-i, Javascripti sõelumine)
    • Paigutus
    • Teksti ja graafika renderdamine
    • Pildi dekodeerimine
    • Koostoimed GPU-ga
    • Juurdepääs võrgule
    • Riistvaraline kiirendus
    Millised neist on kõigi WebKiti brauserite jaoks ühised? Peaaegu ainult kaks esimest.

    Iga WebKiti port rakendab ülejäänud komponendid erinevalt. Mõelgem välja, mida see tähendab.

    WebKiti pordid

    WebKiti porte on palju ja ma pakun Ariya Hidayati, WebKiti häkkerit ja tehnikat. Sencha direktoril on õigus sellest rääkida:

    Kõige populaarsem seos WebKiti kontseptsiooniga on tavaliselt Apple'i WebKiti versioon, mis töötab operatsioonisüsteemis Mac OS X (esimene ja originaalne WebKiti teek). Nagu võite arvata, on erinevad liidesed juurutatud mitmesuguste Mac OS X-i natiivsete teekide abil, peamiselt fokuseeritud komponendis CoreFoundation. Näiteks kui määrate kindla kontuuriraadiusega värvilise lame nupu, teab WebKit, kuhu ja kuidas see nupp joonistada. Samal ajal nupu lõplik renderdus (pikslitena kasutaja monitoril ) langeb CoreGraphicsile.

    Nagu ma eespool mainisin, on kasutatav CoreGraphics iga WebKiti pordi jaoks unikaalne. Näiteks Chrome for Mac kasutab Skiat.

    Mingil hetkel "portiti" WebKit erinevatele platvormidele, nii lauaarvutitele kui ka mobiilidele. Seda variatsiooni nimetatakse tavaliselt "WebKiti pordiks". Safari Windowsi jaoks "portis Apple WebKiti" iseseisvalt, et Windowsis töötaks, kasutades selle (piiratud juurutusega) CoreFoundationi teeki.

    ...vaatamata asjaolule, et Windowsi Safari on nüüd surnud.
    Peale selle oli ka palju muid "porte" (vt täielikku nimekirja). Google on loonud oma Chromiumi pordi ja toetab seda jätkuvalt. Samuti on olemas WebKitGtk, mis põhineb Gtk+-l. Nokia (ja nüüd selle välja ostnud Trolltech) toetab WebKit Qt porti, mis on muutunud populaarseks QtWebKiti moodulina.

    Mõned WebKiti pordid

    • Safari
      - Safari for OS X ja Safari for Windows on kaks erinevat porti
      - WebKiti öine ehitamine on Maci lähtekoodi "pordi" järg, mida kasutatakse Safari jaoks, ainult uuem.
    • Mobiilne Safari
      - Arendati erafiliaalis, kuid avati hiljem.
      - Chrome iOS-ile (kasutab Apple'i WebView'd; erinevuste kohta lisateavet hiljem)
    • Chrome (Chromium)
      - Chrome Androidile (kasutab otse Chromiumi porti)
      - Chromium on ka brauserite alus: Yandex, Sogou ja peagi ka Opera.
    • Androidi brauser
      - Kasutab uusimat WebKiti lähtekoodi, mis on avaldamise ajal saadaval.
    • Veelgi rohkem porte: Amazon Silk, Dolphin, Blackberry, QtWebKit, WebKitGTK+, The EFL port (Tizen), wxWebKit, WebKitWinCE jne
    Erinevad pordid võivad keskenduda erinevatele ülesannetele. Maci pordi fookuses on brauseri ja operatsioonisüsteemi eraldamine ning Obj-C ja C++ sidemete pakkumine renderdusmootori algrakendustesse manustamiseks. Chromiumi pordi fookus on täielikult brauseril. QtWebKit pakub oma porti kasutamiseks koos platvormideülese rakenduse arhitektuuriga renderdusmootorina.

    Mis on ühist kõigil WebKiti brauseritel?

    Kõigepealt vaatame üldisi funktsioone, mida kasutatakse kõigis WebKiti brauserites:

    Teate, et see on naljakas, ma proovisin seda lõiku mitu korda kirjutada. Ja nagu näete, parandasid Chrome'i meeskonna liikmed mind iga kord...

    1. Ja nii, esiteks parsib WebKit HTML-i samal viisil. Noh, välja arvatud see, et Chromium on hetkel ainus port, mis sisaldab HTML-i sõelumise lõimede tuge.
    2. ... Olgu, aga pärast HTML-i sõelumist konstrueeritakse DOM-puu samamoodi. Noh, tegelikult on Shadow DOM lubatud ainult Chromiumi pordi jaoks, mis tähendab, et DOM-i konstruktsioon on erinev. Ka kohandatud elementide jaoks.
    3. …Olgu, WebKit loob akna- ja dokumendiobjektid kõigile ühtemoodi. Tõsi, kuigi nende pakutavad omadused ja konstruktsioonid võivad sõltuda funktsioonilippude kasutamisest.
    4. ... CSS-i sõelumine on sama. CSS-i söömine ja selle CSSOM-iks muutmine on üsna tavaline. Jah, kuigi Chrome toetab ainult -webkit- eesliiteid, kui Apple ja teised brauserid toetavad pärandprefikseid -khtml- ja -apple-.
    5. ...Paigutus...positsioneerimine? See on nagu leib ja või. See on igal pool sama, eks? No juba! Subpikslite paigutus ja rikkaliku paigutuse aritmeetika on WebKiti osa, kuid erinevad porditi.
    6. Super.

    Niisiis, see on raske.

    Proovime nüüd kokku võtta, mis on WebKiti maailmal ühist...

    Mis on ühine iga WebKiti pordi jaoks.

    • DOM, aken, dokument
      Rohkem või vähem
    • CSSOM
    • CSS-i sõelumine, atribuut/väärtus
      erinevused tootja eesliidetes
    • HTML-i sõelumine ja DOM-i loomine
      See on sama, kui unustame veebikomponendid.
    • Paigutus ja positsioneerimine
      Flexbox, Floats, plokkide vormindamise kontekst... kõik on tavaline
    • Kasutajaliidese tööriistad ja arendaja tööriistad, nt Chrome DevTools ehk WebKiti inspektor.
      Kuigi alates eelmise aasta aprillist on Safari kasutanud oma suletud lähtekoodiga mitte-WebKiti Safari Inspectorit.
    • Sellised funktsioonid nagu sisu redigeeritav, pushState, faili API, enamik SVG-d, CSS-i teisendusmatemaatika, veebiheli API, kohalik salvestus
      Kuigi rakendamine võib erineda. Iga port saab kohaliku salvestuse jaoks kasutada oma salvestussüsteemi ja Web Audio API jaoks erinevat heli API-d.
    See muutub veidi segaseks, nii et proovime vaadata mõningaid erinevusi.

    Nüüd, mis ei ole WebKiti portide jaoks tavaline:

    • Kõik, mis on seotud GPU-ga
      - 3D teisendus
      - WebGL
      - Video dekodeerimine
    • 2D renderdamine ekraanile
      - Antialiase tehnoloogiad
      - SVG ja CSS-i gradientide renderdamine
    • Teksti renderdamine ja sidekriipsutus
    • Võrgutehnoloogiad (SPDY, eelrenderdamine, WebSocket transport)
    • JavaScripti mootor
      - JavaScriptCore mootor asub WebKiti hoidlas. Kuid WebKitis on köited nii selle kui ka V8 jaoks.
    • Vormi elementide renderdamine
    • Video- ja helisiltide käitumine ning kodeki tugi
    • Pildi dekodeerimine
    • Navigeerimine tagasi/edasi
      - osa pushState()
    • SSL-i funktsioonid, nagu range transpordi turvalisus ja avaliku võtme PIN-koodid
    Vaatame ühte neist: 2D graafika Olenevalt pordist kasutame ekraanile renderdamiseks täiesti erinevaid teeke:

    Või kui minna üksikasjalikumalt, siis hiljuti lisatud funktsioon: CSS.supports() on lubatud kõigi portide jaoks, välja arvatud win ja wincairo, millel pole css3 tingimuslikke funktsioone lubatud.

    Nüüd on meil tehniline... aeg pedantseks muutuda. Isegi see, mis eespool öeldi, pole täiesti õige. See on tegelikult WebCore, üldine komponent. WebCore on HTML-i ja SVG paigutuse, renderduse ja DOM-i teek ning see on põhimõtteliselt see, millele inimesed mõtlevad, kui nad ütlevad WebKit. Tõepoolest, "WebKit" on tehniliselt WebCore'i ja "portide" vaheline sidemete kiht, kuigi tavavestluses on see eristamine suures osas ebaoluline.

    Diagramm peaks aitama:

    Paljud WebKiti komponendid on lülitatavad (näidatud halliga).

    Näiteks WebKiti JavaScripti mootor JavaScriptCore on WebKiti vaikemootor. See põhineb algselt KJS-il (KDE-st) aegadest, mil WebKit sai alguse KHTML-i hargina. Samal ajal lülitub Chromiumi port V8 mootorile ja kasutab ainulaadseid DOM-i sidemeid.

    Fondid ja teksti renderdamine on platvormi väga suur osa. WebKiti teksti jaoks on kaks erinevat teed: Quick ja Hard. Mõlemad nõuavad platvormipõhist tuge (rakendatud pordi poolel), kuid Fast peab teadma, kuidas kustutada glüüfe (mida WebKit platvormi jaoks vahemällu salvestab), samas kui Complex viib stringi renderdamise täielikult platvormi tasemele ja ütleb lihtsalt "joonista see, palun."

    „WebKit on nagu võileib. Muidu on see Chromiumi puhul pigem taco. Maitsev taco veebitehnoloogiatest.
    Dmitri Glazkov, Chrome WebKiti häkker. Veebikomponentide meister ja varidom.

    Laiendame nüüd ülevaadet ja vaatame mitut porti ja mitut alamsüsteemi. Allpool on viis WebKiti porti, pange tähele, kuidas igaühe tööriistakomplekt erineb hoolimata ühistest komponentidest.

    Chrome (OS X) Safari (OS X) QtWebKit Androidi brauser Chrome iOS-ile
    Renderdamine Skia CoreGraphics QtGui Android stack/Skia CoreGraphics
    Võrgustiku loomine Chromiumi võrgupinn CFNetwork QtNetwork Fork of Chromiumi võrgupinn Kroomi virn
    Fondid CoreText Skia kaudu CoreText Qt sisemised osad Androidi virn CoreText
    JavaScript V8 JavaScriptCore JSC (V8 kasutatakse mujal Qt-s) V8 JavaScriptCore (ilma JIT-ita) *

    * Joonealune märkus iOS-ile mõeldud Chrome'i kohta. See kasutab UIWebView-d, nagu te ilmselt teate. Vastavalt UIWebView võimalustele tähendab see, et see saab kasutada ainult sama renderdusmootorit nagu Mobile Safari, JavaScriptCore (mitte V8) ja ühe lõimega mudelit. Mõni kood on siiski Chromiumilt laenatud, näiteks võrgu alamsüsteem, järjehoidjate sünkroonimise infrastruktuur, omnikastike, mõõdikud ja krahhiaruanded. (Samuti on JavaScript mobiilseadmetes nii harva kitsaskohaks, et JITtingi kompilaatori puudumisel on minimaalne mõju.)

    Olgu, kust me tuleme?

    Ja nii on kõik WebKitid nüüd täiesti erinevad. Ma kardan.

    Ei ole seda väärt! WebKiti "layoutTesti" testide katvus on tohutu. (28 000 testi lõpuks) ja mitte ainult olemasolevate funktsioonide, vaid ka kõigi leitud regressioonide jaoks. Tegelikult, kui õpite uusi või "salajaste" DOM/CSS/HTML-5 funktsioone, on "layoutTesti" testikomplektidel tavaliselt suurepärane minimaalne demo.

    Lisaks teeb W3C jõupingutusi testikomplekti standardimiseks. See tähendab, et võime eeldada, et nii WebKiti porte kui ka kõiki teisi brausereid testitakse samade testkomplektidega, mis toob kaasa vähem veidrusi ja koostalitlusvõimelisema veebi. Kõigile, kes pingutavad, osaledes üritusel Test The Web Forward...aitäh!

    Opera kolis just WebKiti. Mis sellest saab?

    Robert Nyman ja Rob Hawkes on seda teemat juba puudutanud, kuid lisan, et teadaande üks oluline osa oli see, et Opera lülitub üle Chromiumile. See tähendab, et WebGL, Canvas, HTML5 vormid, 2D-graafika rakendamine, kõik need asjad on nüüd Chrome'is ja Operas samad. Sama API ja madala taseme juurutus. Kuna Opera põhineb Chromiumil, võite tunda, et vähendate oma töökoormust, et kontrollida Opera ja Chrome'i ühilduvust.
    Peaksin ka seda märkima Kõik Opera brauserid lülitatakse üle Chromiumile. See tähendab, Opera for Windows, Mac, Linux ja Opera Mobile (täisväärtuslik mobiilibrauser). Isegi Opera Mini, õhuke klient, vahetatakse praeguselt Prestol põhinevalt renderdusfarmilt Chromiumil põhinevale renderdusfarmile.

    ... ja igaõhtune WebKiti ehitamine. Mis see on?

    See on WebKit, mis töötab sama koodiga kui Safari (kuigi mõnda sisemist teeki on muudetud). Seda haldab suures osas Apple, nii et käitumine ja funktsioonide komplekt on kooskõlas sellega, mida leiate Safarist. Paljudel juhtudel on Apple konservatiivne, kui on vaja lisada funktsioone, mida teised pordid rakendavad või millega katsetavad. Igatahes, kui kasutada analoogiat, mõelge sellele kui... igaõhtune WebKiti koostamine Safari jaoks on nagu Chromium Chrome'ile. Lisa märksõnu