WebKit fejlesztői szemmel

2013. március 2. 13:57, magyaropera.blog.hu

Megjegyzés: A cikk az eredeti, Paul Irish által írt cikk fordítása. (forrás) Sokaknak a WebKit egyfajta fekete doboz. Dobunk neki egy kis HTML-t, CSS-t, JS-t és egyéb eszközöket, majd a WebKit valahogyan, varázslatosan átalakítja azt egy weblappá, ami jól néz ki és működik. De igazság szerint, hogy kollégám, Ilya Grigorik szavaival éljek… A WebKit nem egy fekete doboz. Hanem egy fehér doboz. Pontosabban egy nyílt, fehér doboz. Akkor most álljunk meg egy pillanatra és vegyünk át pár dolgot: Mi a WebKit? Mi nem a WebKit? Hogyan használják a WebKit-et a WebKit-alapú böngészők? WebKit-en belüli különbségek? Most, különösképpen a következő írást alapul véve: Opera has moved to WebKit, van számos WebKit-alapú böngésző, de elég nehéz megérteni, hogy mely elemek közösek és mely részeikben vállnak el egymástól. A most következő írás elolvasása után remélhetőleg sok minden világosabb lesz. Továbbá könnyebben képes leszel különbséget tenni a böngésző egyes részei között, majd a hibákat, tapasztalt problémákat a megfelelő helyen jelenteni és jobban megérteni a specifikus böngészők fejlesztésének mikéntjét. Hagyományos Webböngésző Komponensek Lássuk, milyen komponensekből tevődik össze egy mai modern böngésző: Parsing (HTML, XML, CSS, JavaScript) (feldolgozás, elemzés) Layout (kirajzolás, elrendezés) Text and graphics rendering (szövegek és grafikai elemek megjelenítése) Image decoding (képek dekódolása) GPU interaction (GPU interakciók) Network access (Hálózati hozzáférés) Hardware acceleration (Hardveres gyorsítás) Ezek közül melyek közösek a WebKit-alapú böngészőkben? Nagyjából csak az első kettő.A többi önállóan kerül kezelésre az egyes WebKit portokban. Nézzük, mit is jelent ez… A WebKit Portok A WebKitnek vannak különböző “portjai”, de hadd idézzem Ariya Hidayat, WebKit hacker és a Sencha műszaki igazgatójának magyarázatát: A népszerű "WebKit" kifejezés alatt általában az Apple saját WebKit fejlesztését értjük, amely Mac OSX-en fut és (az első és eredeti WebKit library). Mint kitalálhatod, a különböző, natív libeken alapuló különféle interfészek legtöbbje Mac OSX-en a CoreFoundation köré szerveződik. Például ha csinálsz egy sima, színes gombot specifikus border-radius használatával, a WebKit tudni fogja hova és hogyan rajzolja ki az a gombot. Azonban a gomb kirajzolásának végső felelőssége (mint a felhasználó monitorján lévő pixelek) már a CoreGraphics hatáskörébe tartoznak. Ahogy fentebb is említettem, a CoreGraphic használata a Mac-es port sajátja. A Chrome Mac-es változata már Skia-t használ. Idővel a WebKit portolásra került különböző platformokra, desktopon és mobilon belül. Ezeket gyakran hívják "WebKit port"-nak. A Windows-os Safari esetében az Apple saját maga portolta a WebKitet Windows alá, mindezt a saját CoreFoundation library-jának (limitált változatának) Windows verziójával. … bár a Windows-os Safari most már halott. Emellett volt sok más egyéb port is (lásd a teljes listát). A Chromium portot a Google hozta létre és tartja fenn. Van WebKitGTK amely GTK+-on alapul. A Nokia (a Trolltech-en keresztül, melyet felvásárolt) pedig a Webkit Qt portjáért felel, azaz a QtWebKit module-ért. A WebKit néhány portja Safari Az OSX-es Safari és a Windows-os Safari két különböző port A WebKit nightly a Safari által is használt Mac-es port instabil ága. Bővebb információ az írás további részében… Mobile Safari Egy magán ág szárnyai alatt, de az utóbbi időben being upstreamed(?) Chrome iOS változata (az Apple WebView-ját használja; a különbségekről később a cikkben) Chrome (Chromium) Chrome Android-ra (közvetlenül a Chromium portot használja) A Chromium alapjául szolgál a Yandex Browser-nek, 360 Browser-nek, Sogou Browser-nek, és hamarosan az Operának. Android Browser A legújabb WebKit forrást használja További portok: Amazon Silk, Dolphin, Blackberry, QtWebKit, WebKitGTK+, The EFL port (Tizen), wxWebKit, WebKitWinCE, stb. A különböző portok különböző területekre koncentrálnak. A Mac-es port megoszlik a böngésző és az operációs rendszer között és Objective-C és C++ nyelveket használ, hogy beágyazza a megjelenítő motort a natív alkalmazásokba. A Chromium középpontjában tisztán a böngésző áll. A QtWebKit pedig alkalmazások számára kínálja portját futtatókörnyezetként vagy megjelenítő motorként kereszt-platformos GUI architektúrára. Mi az, ami közös minden WebKit böngészőben? Először is vegyük szemügyre közös vonásokat az összes WebKit portban. Tudod, ez vicces. Próbáltam már erről írni párszor. Minden alkalommal kijavítottak a Chrome csapat tagjai, mint látni fogod… Először is a WebKit a HTML-t ugyanazon a módon értelmezi, dolgozza fel. Jó, a Chromium kivételével, ami az egyetlen port, ami rendelkezik threaded HTML parsing támogatással. … Oké, de a feldolgozás után a DOM fa szerkezete ugyanaz. Nos, igazából a Shadow DOM csak a Chromium portban van bekapcsolva, tehát a DOM szerkezet különbözik. Ugyanez a helyzet az egyéni elemekkel. … Oké, a WebKit létrehoz egy window objektumot és egy document objektumot mindenkinél. Igaz, bár a tulajdonságok és konstrukciók lehetnek feltételesek egyes portokban függően az engedélyezett feature flag-ektől. … A CSS elemzése egyforma. Csak fogja a CSS-t és átalakítja csini szabványos formára. Igen, bár a Chrome csak a -webkit- prefixeket fogadja el miközben az Apple és egyéb portok a hagyományos prefixeket, mint -khtml- és -apple-. … Elrendezés (layout).. pozicionálás? Akárcsak a kenyér és a vaj. Ugyanazok, nemde? Ugyan már! A sub-pixel layout és a saturated layout arithmetic része ugyan a WebKitnek, de portról-portra különböznek. Szuper. Tehát ez így kicsit bonyolult. Csakúgy, mint ahogyan a Flickr és a Github implementál tulajdonságokat egyes flag-ek mögött, a WebKit ugyanazt teszi. Lehetővé teszi a portok számára, hogy engedélyezzünk/letiltsunk mindenféle funkcionalitást a WebKit fordítás-idejű Feature Flag-jeinek használatával. A tulajdonságok használhatók futásidejű flagekként is, vagy parancssori kapcsolókként (lásd: Chromium) vagy konfigurációs beállításként, lásd: about:flags. Rendben, akkor próbáljuk újra megfogalmazni mi azonos a WebKit-világban… Mi a közös minden WebKit portban? A DOM, window, document többé-kevésbé A CSSOM CSS elemzés, tulajdonságok/értékek kezelése vendor prefix-ek nélküli kezelés HTML elemzés és DOM szerkezet ugyanaz, ha kizárjuk a Web Components-t Minden elrendezés és pozicionálás Flexbox, Floats, block formatting kontextusok… minden ugyanaz A Chrome DevTools azaz WebKit Inspector eszközkészlete és felhasználói interfésze. Bár 2012 áprilisa óta a Safari a saját, nem-WebKit, zárt-forráskódú UI-ját használja a Safari Inspector számára Tulajdonságok, mint contenteditable, pushState, File API, SVG legtöbbje, CSS Transform math, Web Audio API, localStorage Bár a backend-ek változók. Egyes portok talán eltérő storage layer-t használnak localStorage-hoz és eltérő audio API-kat a Web Audio API-hoz. Számos egyéb tulajdonság és funkcionalitás Kezd egy kicsit homályos lenni egyes területeken. Próbáljunk felsorolni pár különbséget, ami kevésbé homályos. Mi az ami nem közös a WebKit portokban: Bármi, ami kapcsolatos a GPU-val 3D Transforms-mal WebGL-lel Video dekódolással 2D kirajzolása a képernyőre Antialiasing megközelítések SVG & CSS gradient rajzolás Szöveg megjelenítés és elválasztás Network stack (SPDY, prerendering, WebSocket transport) JavaScript motor JavaScriptCore van a WebKit repóban. Vannak kötődései a WebKit-hez ennek is és a V8-nak is egyaránt Űrlap vezérlők megjelenítése elemek viselkedése (és a codec támogatása) Képek dekódolása Előre/vissza navigáció A navigáció a pushState() része SSL tulajdonságok, mint Strict Transport Security és Public Key Pins Nézzük az alábbit: 2D graphics Az adott porttól függ, különböző libeket használ, hogy a képernyőre rajzolást kezelje: Vagy hogy még mélyebbre ássunk… egy nemrég landolt funkció: CSS.supports() engedélyezve lett mindegyik portban, kivéve win és wincairo, melyekben nincsenek engedélyezve a css3 feltételes tulajdonságok. Most, hogy a technikai részéhez értünk.. ideje, hogy pontosabban fogalmazzunk. Még a fenti rész sem teljesen helytálló. Igazából a WebCore az, ami megosztott. A WebCore egy elrendező, renderelő és Document Object Model (DOM) library a HTML és SVG részére, és általában az emberek erre gondolnak, mikor WebKitről beszélnek. A valóságban azonban a “WebKit” technikailag a kötőréteg a WebCore és a portok között, bár alkalmi beszélgetésekben ez a különbségtétel általában elhanyagolható. Ez a diagram talán érthetőbbé teszi: Sok komponens a WebKit-en belül felcserélhető (a szürke színnel jelöltek). Példaként, a WebKit JavaScript motorja a JavaScriptCore, ami az alapértelmezett a WebKitben. (Eredetileg a KJS-en (KDE fejlesztés) alapul még azokból az időkből, mikor a WebKit kinőtt a KHTML forkjaként). Eközben a Chromium port lecserélte V8-ra és egyedi DOM kötéseket használ, hogy feltérképezze a dolgokat. A fontok és a szöveg renderelése a platform nagy része. Két különböző szöveg útvonal van WebKitben: Fast és Complex. Mindkettő platform-specifikus (port-oldali) támogatást igényel, de a Fast-nak csak a karakterek feldolgozásában kell "segítség" (amelyet a WebKit gyorsítótáraz a platformon) és a complex igazából átadja az egész string-et a platform layer-nek és utasítja: “rajzold ki, kérlek”. “A WebKit olyan, mint egy szendvics. Bár a Chromium esetében sokkal inkább egy taco. Egy finom, web-platform taco.” Dimitri Glazkov, Chrome WebKit hacker. A Web Components és a Shadow DOM bajnoka Most szélesítsük látókörünket és nézzünk meg néhány portot és néhány alrendszert. Lejjebb ötféle WebKit portot láthatsz; melyek egyúttal példázzák, mennyire különbözők lehetnek, a közös WebCore ellenére. Chrome (OS X) Safari (OS X) QtWebKit Android Browser Chrome for iOS Renderelés: Skia CoreGraphics QtGui Android stack/Skia CoreGraphics Hálózatkezelés: Chromium network stack CFNetwork QtNetwork Fork of Chromium’s network stack Chromium stack Szövegkezelés: CoreText via Skia CoreText Qt internals Android stack CoreText JavaScript V8 JavaScriptCore JSC (V8 is used elsewhere in Qt) V8 JavaScriptCore (without JITting) * * Egy megjegyzés a Chrome for iOS-re vonatkoztatva: UIWebView-et használ. Az UIWebView korlátai képességei miatt ez azt jelenti, hogy (csak) ugyanazt a renderelő layer-t használ(hat)ja, mint a Mobile Safari, valamint a JavaScriptCore-t (V8 helyett) és single-process model-t. Mégis jelentős Chrome-oldali kód maradt benne, mint network layer, a szinkronizáció és a könyvjelző infrastruktúra, omnibox, metrics és hibajelentő. (Továbbá érdemes megjegyezni, hogy mobilon a JavaScript ritkán jelenti a szűk keresztmetszetet, így a JIT Compiler hiánya minimális negatív hatással van rá) Rendben, tehát akkor hová jutottunk?   Ezek szerint minden WebKit teljesen különbözik. Megrémültem. Ne tedd! A layoutTest lefedettség WebKit-ben hatalmas (28,000 layoutTest és folyamatosan bővül), nem csak a létező funkciók, hanem bármilyen regresszió. Igazából bármit felfedezel, valami új ezoterikus DOM/CSS/HTML5-y fícsört, a layoutTest-ek gyakran fantasztikus minimális demókkal rendelkeznek a teljes webplatformon. Ezen túl, a W3C nagy erőfeszítéseket tesz a conformance suite testing érdekében. Ez azt jelenti, hogy bár különböző WebKit portok különböznek, de ugyanazokon a teszteken kell átmenniük, ami kevesebb quirk-módhoz és több szabványossághoz, egységességhez vezet. Mindazok számára, akik segítették ezt az erőfeszítést a Test The Web Forward event-en való részvételükkel… köszönöm! Az Opera is WebKitre fog váltani. Hogyan fog ezek után működni? Robert Nyman és Rob Hawkes már pedzegette a témát, de én hozzáadom egy jelentős részét az Opera bejelentésének, miszerint Az Opera adoptálja a Chromium-ot. Ez azt jelenti, hogy a WebGL, Canvas, HTML5 formok, 2D graphics implementációk-és minden ehhez hasonló cucc ugyanaz lesz Chrome-ban és Operában. Ugyanazok az API-k és ugyanaz a backend implementáció. Mikortól az Opera Chromium-alapú lesz, magabiztos lehetsz, hogy az általad fejlesztett weboldal Chrome és Opera alatt is ugyanúgy fog kinézni és működni. Az szintén megjegyzendő, hogy az összes Opera böngészőa Chromium-ot adoptálja. Tehát az Opera Windowsra, Mac-re, Linuxra, az Opera Mobile (a teljeskörű mobilböngésző). Még az Opera Mini is, a vékonykliens is kicseréli a szerveroldali renderelő farmját Presto-ról Chromium alapúra. .. és a WebKit nightly, az micsoda? Az a WebKit mac port-ja, ugyanazt a binárist használja, mint a Safari (néhány mögöttes libet kicseréltek benne). Tehát a viselkedése és a tulajdonságai megegyeznek a Safariéval. Egyszerűbb példával élve, gondolj rá úgy, hogy a… WebKit Nightly ugyanaz a Safarinak, mint a Chromium a Chrome-nak. Chrome Canaryis a legújabb WebKit forrást használja maximum pár napos késéssel. Ha szeretnél többet tudni a WebKit belsejéről, lásd a következő prezentációt: További olvasnivaló: WebKit internals technical articles | webkit.org WebKit: An Objective View | Robert Nyman & Rob Hawkes your webkit port is special (just like every other port) | Ariya Hidayat Getting Started With the WebKit Layout Code | Adobe Web Platform Blog WebKit Documentation Overview | Arun Patole Rendering in WebKit, by Eric Seidel | YouTube web performance for the curious | Ilya Grigorik Remélhetőleg ez a cikk kicsit részletesebben elmagyarázta a WebKit belsejét és megvilágította, hogy hol végződik a WebKit és hol kezdődnek a WebKit-portok.A cikk áttekintve Peter Beverloo (Chrome) és Eric Seidel (WebKit) által. Frissíteni fogom további korrekciókkal és módosításokkal.

Tovább a teljes cikkre...

Keresés