Átruházás

Sokan közülünk fejlesztők, WebKit - fekete doboz... HTML-t, CSS-t, JS-t és egy csomó képet dobunk bele, és a WebKit valahogy ... varázslatként egy olyan weboldalt ad nekünk, amely jól néz ki és jól működik.
De tényleg hogyan - mondja Ilya Grigorik kollégám :

Webkészlet nem fekete doboz. Ez egy fehér doboz. És nem csak fehér, hanem nyisd ki doboz.

Tehát próbáljunk kitalálni néhány dolgot:

Mi a WebKit?
Mi nem a WebKit?
Hogyan használják a WebKit-et a WebKit böngészők?
Miért nem ugyanaz a sok WebKits?

Most, főleg azok után a hírek után, hogy az Opera átállt WebKit-re, sok WebKit-böngésző vesz körül minket, és nehéz megmondani, mi egyesíti őket, és merre haladnak a saját útjukon. Az alábbiakban remélem, hogy megpróbálunk fényt deríteni erre a kérdésre. Ennek eredményeként jobban felismerheti a böngészőbeli különbségeket, hibákat küldhet a megfelelő nyomkövetőhöz, és hatékonyabban képes a böngészők közötti fejlesztésre.

Normál webböngésző-összetevők

Soroljunk fel néhány összetevőt a modern böngészőkből:

Elemzés (HTML, XML, CSS, Javascript elemzése)
Elrendezés
Szöveg és grafika renderelése
Képek dekódolása
GPU interakciók
Hálózati hozzáférés
Hardveres gyorsítás

Melyik a közös az összes WebKit böngészőben? Nagyjából csak az első kettő.

Minden WebKit "port" más összetevőket valósít meg a maga módján. Nézzük, mit jelent ez.

WebKit portok

Sok a WebKit "portja", és én biztosítom Aria Hidayat-ot, a WebKit hackert és azokat. a Sencha igazgatójának joga van elmondani róla:

A WebKit legnépszerűbb társítása általában az Apple WebKitje, amely Mac OS X-en (az első és az eredeti WebKit könyvtár) fut. Mint sejteni lehet, a különféle interfészeket különféle natív Mac OS X könyvtárak segítségével valósítják meg, többnyire összpontosítva a CoreFoundation komponensben Például, ha színes lapos gombot definiál egy speciális körvonal sugárral, akkor a WebKit tudja, hogy hol és hogyan kell felhívni azt a gombot, míg a gomb végleges megjelenítése (pixelként a felhasználó monitorján) a CoreGraphicsra esik.

Mint fent említettem, a használt CoreGraphics minden WebKit port esetében egyedi. A Chrome for Mac például a Skia szoftvert használja.

Valamikor a WebKit-et különböző platformokra "portolták", asztali és mobil platformokra egyaránt. Ezt a variációt általában "WebKit portnak" nevezik. A Safari Windows esetében az Apple a (korlátozott megvalósítású) CoreFoundation könyvtár segítségével önállóan is „portolta a WebKit-et” a Windows rendszeren történő futtatásra.

... annak ellenére, hogy a Safari for Windows már nem működik.

Ettől eltekintve sok más "port" is létezett (lásd a teljes listát). A Google létrehozta és továbbra is fenntartja Chromium portját. Van a WebKitGtk is, amely a Gtk + alapú. A Nokia (és most a Trolltech, aki megvette) fenntartja a WebKit Qt portot, amely QtWebKit modulként vált népszerűvé.

A WebKit egyes portjai

Szafari
- Safari OS X alatt és Safari Windows alatt két különböző port
- A WebKit Nightly Build a Safarihoz használt Mac "port" forráskódjának összeállítása, csak újabb
Mobil Safari
- Magán fiókban fejlesztették ki, de később megnyitották.
- Chrome iOS rendszerhez (az Apple WebView alkalmazását használja; kicsit később a különbségről)
Króm (króm)
- Chrome Androidhoz (közvetlenül használja a Chromium "portot")
- A Chromium az alapja a böngészőknek is: Yandex ,, Sogou, és hamarosan az Opera.
Android böngésző
- A kiadáskor rendelkezésre álló legújabb WebKit forráskódot használja.
Még több port: Amazon Silk, Dolphin, Blackberry, QtWebKit, WebKitGTK +, Az EFL port (Tizen), wxWebKit, WebKitWinCE stb.

A különböző portok különböző feladatokra összpontosíthatnak. A Mac port középpontjában a böngésző és az operációs rendszer közötti elkülönítés áll, valamint az Obj-C és C ++ kötések biztosítása a renderelő motor natív alkalmazásokba történő beágyazásához. A Chromium port teljes mértékben a böngészőn van. A QtWebKit kínálja portját a platformokon átívelő alkalmazás-architektúrával renderelő motorként használni.

Mi minden WebKit böngészőben közös

Először vessünk egy pillantást az összes WebKit böngészőben használt közös szolgáltatásokra:

Tudod, hogy ez vicces, többször próbáltam megírni ezt a bekezdést. És valahányszor a Chrome csapat tagjai kijavítottak, amint látni fogod ...

És így először is a WebKit ugyanúgy elemzi a HTML-t. Nos, kivéve, hogy a Chromium az egyetlen olyan port, amely jelenleg engedélyezi a HTML elemzés streaming támogatását.
... Ok, de a HTML elemzése után a DOM fa ugyanúgy felépül. Nos, a Shadow DOM valójában csak a Chromium portnál engedélyezett, így a DOM felépítése változó. Egyedi elemekhez is.
... Rendben, a WebKit mindenki számára egyforma ablak- és dokumentumobjektumokat hoz létre. Igaz, bár az általuk nyújtott tulajdonságok és konstrukciók a jellemző zászlók használatától függhetnek.
... A CSS elemzése ugyanaz. A CSS megevése és CSSOM-ba konvertálása meglehetősen szokásos. Igen, bár a Chrome csak az -webkit- előtagokat támogatja, míg az Apple és más böngészők az elavult -khtml- és -apple- előtagokat.
… Elrendezés… pozicionálás? Olyan, mint a kenyér és a vaj. Mindenhol ugyanaz, igaz? Hát már! Az alpixeles elrendezés és a gazdag elrendezésű aritmetika a WebKit része, de portonként eltérő.
Szuper.

Tehát ez nehéz.

Most próbáljuk meg összefoglalni, mi jellemző a WebKit világban ...

Mi a közös az egyes WebKit portoknál.

DOM, ablak, dokumentum
többé-kevésbé
CSSOM
CSS tulajdonság / érték elemzése
különbségek a gyártói előtagokban
A HTML elemzése és a DOM felépítése
Ugyanez, ha megfeledkezünk a webkomponensekről.
Elrendezés és elhelyezés
Flexbox, Floats, blokk-formázó kontextus ... minden közös
A felhasználói felület eszközei és a fejlesztői eszközök, például a Chrome DevTools más néven WebKit inspector.
Bár tavaly április óta a Safari saját, nem WebKit ellenőrzőjét használja, zárt forráskódú.
Olyan funkciók, mint a contenteditable, a pushState, a File API, a legtöbb SVG, a CSS transzformációs matematika, a Web Audio API, a localStorage
A megvalósítás azonban eltérhet. Minden port a saját tárhelyét használhatja a localStorage számára, és a Web Audio API-hoz más audio API-t is használhat.

Ez kissé zavaros, ezért próbáljuk meg megvizsgálni a különbségeket.

Ami nem jellemző a WebKit portokra:

Bármi, ami GPU-val kapcsolatos
- 3D transzformációk
- WebGL
- Video dekódolás
2D rajzolása a képernyőre
- Aliasing technológiák
- SVG és CSS színátmenetek renderelése
Szöveg és elválasztás renderelése
Hálózati technológiák (SPDY, pre-rendering, WebSocket transport)
JavaScript motor
- A JavaScriptCore motor a WebKit adattárban található. De vannak olyan kötések a WebKit-ben, mind a V8-hoz, mind a V8-hoz.
Forma elemek renderelése
Videó és hangcímke viselkedése és kodek támogatás
Képek dekódolása
Vissza / előre navigáció
- A pushState () rész
Az SSL funkciók, például a szigorú közlekedésbiztonság és a nyilvános kulcsok

Vessünk egy pillantást egyikükre: 2D-s grafika a porttól függ, teljesen más könyvtárakat használunk a képernyőn történő megjelenítéshez:

Vagy részletesebben: a közelmúltban hozzáadott funkció: a CSS.supports () minden portnál engedélyezve volt, kivéve a win és a wincairo, amelyeknél nincsenek engedélyezve a css3 feltételes funkciók.

Most belemerülünk a technikai részletekbe ... ideje pedánssá válni. Még a fentiek sem teljesen helytállóak. Valójában ez a WebCore, ez egy általános összetevő. A WebCore egy elrendezés, megjelenítő és DOM könyvtár a HTML és az SVG számára, és alapvetően az emberek gondolkodnak, amikor azt mondják, hogy WebKit. Valójában a "WebKit" technikailag a WebCore és a "portok" közötti kötések rétege, bár a normál beszélgetés során ez a megkülönböztetés lényegében lényegtelen.

A diagram segít:

Számos WebKit komponens kapcsolható (szürke színnel látható).

Például a WebKit JavaScript-motorja, a JavaScriptCore az alapértelmezett motor a WebKit-ben. Eredetileg a KJS-en (a KDE-n) alapszik, azoktól az időktől kezdve, amikor a WebKit a KHTML villájaként indult. Ugyanakkor a Chromium port V8 motorra vált és egyedi DOM összerendeléseket használ.

A betűtípusok és a szövegmegjelenítés a platform nagyon nagy része. A WebKitben 2 külön út van a szöveghez: Gyors és Kemény. Mindkettő platformspecifikus támogatást igényel (a port oldalán valósul meg), de a Fast-nak csak azt kell tudnia, hogyan kell kitörölni a karakterjeleket (amelyeket a WebKit a gyorsítótárban tárol), amikor a Bonyolult teljesen a karakterláncok renderelését a platform szintjére tolja, és csak annyit mond, hogy ezt rajzolja meg kérem.

„A WebKit olyan, mint egy szendvics. Egyébként a Chromium esetében ez inkább taco. Finom tacók a webes technológiákból.
Dmitri Glazkov, a Chrome WebKit hacker. A Web Componets bajnoka és az árnyékdom.

Most bővítsük áttekintésünket, és nézzünk meg néhány portot és néhány alrendszert. Az alábbiakban bemutatjuk a WebKit öt portját, és vegye észre, hogy az eszközkészlet hogyan különbözik mindegyiknél a közös összetevők ellenére:

	Chrome (OS X)	Safari (OS X)	QtWebKit	Android böngésző	Chrome iOS rendszerhez
Rendering	Skia	CoreGraphics	QtGui	Android verem / Skia	CoreGraphics
Hálózatépítés	Chromium hálózati verem	CFNetwork	QtNetwork	Villa a Chromium hálózati vereméből	Króm verem
Betűtípusok	CoreText a Skia-n keresztül	CoreText	Qt belső részek	Android verem	CoreText
JavaScript	V8	JavaScriptCore	JSC (a V8-ot a Qt másutt használják)	V8	JavaScriptCore (JITting nélkül) *

* Lábjegyzet az IOS Chrome-ról. UIWebView-t használ, amint valószínűleg tudja. Az UIWebView képességeivel összhangban ez azt jelenti, hogy csak ugyanazt a megjelenítési motort tudja használni, mint a Mobile Safari, a JavaScriptCore (nem V8) és egyetlen szálas modellt. Néhány kódot azonban kölcsönvettek a Chromiumtól, például a hálózatot, a könyvjelzők szinkronizálási infrastruktúráját, a cím- és keresősávot, a mutatókat és a hibajelentéseket. (Ezenkívül a JavaScript olyan ritkán jelent szűk keresztmetszetet a mobilon, hogy a JITting fordító hiányának minimális hatása van.)

Oké, akkor hova jöttünk?

Így minden WebKit teljesen más. Félek.

Nem éri meg! A WebKit layoutTest lefedettsége óriási. (28 000 teszt az utolsó számláláskor), és nemcsak a meglévő funkciókra, hanem az összes talált regresszióra is. Valójában, amikor új vagy "titkos" DOM \u200b\u200b/ CSS / HTML-5 szolgáltatásokat tanul, a "layoutTest" tesztkészletek általában nagyon minimális demóval rendelkeznek.

Ezenkívül a W3C erőfeszítéseket tesz a tesztkészlet egységesítésére. Ez azt jelenti, hogy mind a WebKit portok, mind az összes többi böngésző tesztelésére számíthatunk ugyanazzal a tesztcsomaggal, ami csökkenteni fogja a furcsaságokat és az interoperábilisabb webet. Mindazok számára, akik erőfeszítéseket tettek a Test The Web Forward rendezvényen való részvételre ... köszönöm!

Az Opera a WebKit-re költözött. Mi lesz belőle?

Robert Nyman és Rob Hawkes már foglalkozott ezzel a témával, de hozzáteszem, hogy a bejelentés egyik fontos része az volt, hogy Az Opera Chromiumra vált... Ez azt jelenti, hogy a WebGL, a Canvas, a HTML5 űrlapok, a 2D-s grafika megvalósul, mindezek a Chrome-ban és az Operában most már ugyanazok lesznek. Ugyanaz az API és alacsony szintű megvalósítás. Mivel az Opera Chromium-alapú, úgy érezheti, mintha visszavágná a munkáját az Opera és a Chrome kompatibilitásának ellenőrzésével.
Ezt is meg kell jegyeznem minden Az Opera böngészőket lefordítják Chromiumra. Vagyis az Opera Windows, Mac, Linux és Opera Mobile (teljes értékű mobil böngésző) számára. Még a vékony kliens Opera Mini is átkerül a jelenlegi Presto-alapú renderelő farmról egy másik Chromium-alapúra.

... és a WebKit éjszakai felépítése. Mi az?

Ez a WebKit, amely ugyanazon a kódon fut, mint a Safari (bár néhány belső könyvtárat módosítottak). Leginkább az Apple futtatja, így a viselkedés és a szolgáltatáskészlet megegyezik azzal, amit a Safari-ban találhat. Sok esetben az Apple konzervatív, amikor olyan funkciókat engedélyez, amelyeket más portok implementálnak vagy kísérleteznek. Egyébként az analógiák használatához gondoljon arra, hogy ... a Safari WebKit éjszakai felépítése olyan, mint a Chromium a Chrome-hoz. Címkék hozzáadása

Android és iPhone - böngészőháborúk

1. rész: A WebKit segítségre siet

A hálózati állapot felügyeletéért felelős böngésző alkalmazás fejlesztése

Tartalomsorozat:

Összességében az iPhone és az Android platformon több mint 100 000 alkalmazás tölthető le különféle forrásokból. Ez "natív" alkalmazásokra, azaz. alkalmazások, amelyeket a megfelelő SDK használatával fejlesztenek és építenek, majd mobileszközre telepítenek. Az ilyen „natív” alkalmazások lehetővé teszik a mobileszköz technikai képességeinek hatékony megvalósítását, ideértve a vezeték nélküli hálózatok, a Bluetooth és az adattárolás, a gyorsulásmérő vagy az iránytű funkcióinak támogatását, valamint egyéb technológiai csodákat és újításokat, amelyek a mobil eszközöket olyan vonzóvá teszik a felhasználók számára. Az iPhone és az Android platformon a "natív" alkalmazások népszerűsége rendkívül magas, de emellett a mobil eszközök bőséges lehetőséget nyújtanak a webalkalmazások fejlesztésére. A mobil technológiák már régen kimentek a gyermekkorból, és velük együtt a mobil internet is elérte bizonyos érettségét.

Ez a cikk az első egy kétrészes sorozatban, amely az iPhone és az Android platformok böngészőalkalmazásainak fejlesztéséről szól. Ennek a sorozatnak az a célja, hogy megismertesse az olvasót a saját mobil webalkalmazások felépítésének alapelveivel. A mobilalkalmazások nem korlátozódnak egy weboldal futtatására mobileszközön. Megvizsgáljuk a mobil alkalmazások fejlesztésében alkalmazott alapvető technológiákat és megközelítéseket, amelyek lehetővé teszik a szoftverfejlesztés ezen szakaszának különálló, önálló tudományágba történő kiemelését.

A webes platform népszerűsége annak köszönhető, hogy használata lehetővé teszi számos olyan probléma megoldását, amely hagyományosan sújtja a fejlesztőket és a rendszergazdákat. Közöttük:

Telepítési problémák: A webalkalmazások telepítése egyszerű - egyszerűen telepítse vagy másolja azokat a szerverre, és mondja el ügyfeleinek, hogy melyik URL-t kell megadnia a böngészőben.
Méretezési kérdések: A webalkalmazások könnyen méretezhetők át egy nagy teljesítményű adatközpont kiszolgálóira, és az alkalmazások kiszolgálásához dobozon kívüli webhelykezelő eszközöket használnak.
Adatarchiválási és helyreállítási kihívások: A webalkalmazások központosított adattárolót használnak, ezáltal egyszerűsítve a katasztrófa utáni helyreállítást.
A felhasználói felület szempontjai: A HTML, a Cascading Style Sheets (CSS), a JavaScript és a grafika kombinációja olyan gazdag felhasználói felületet hoz létre, amely funkcionalitása és megjelenése szempontjából jóval jobb, mint a natív SDK-val kifejlesztett interfészek. Ez utóbbiak általában nem képesek teljes körű jelenlét-hatást biztosítani a játékalkalmazások számára, és nem garantálják az interaktív információs terminálok szükséges funkcionalitását.
Könnyű használat: A legtöbb alkalmazáshoz egyszerű, könnyen használható felhasználói felület elemekre van szükség a mindennapi műveletek megkönnyítése érdekében.

Az internetes alkalmazás-terjesztési modell legvonzóbb szempontja, hogy a szoftvert egyfajta előfizetési szolgáltatássá alakítja, ami kölcsönösen előnyös módszer a szoftverek kézbesítésére. "Hogyan?" - kérdezed. Vizsgáljuk meg közelebbről ezt a kérdést.

A webalapú szoftverterjesztési modell lehetővé teszi az ügyfelek számára, hogy vásárlás előtt kipróbálják a terméket minimális kockázat és minimális költség mellett. Ha az ügyfélnek tetszett a próbaverzió, akkor a szoftvertermék további használatához csak az szükséges, hogy hitelkártyával (vagy a PayPal rendszer segítségével) fizessen a vásárlásért. Sőt, a szoftver mint szolgáltatás (SaaS) modell kényelmes és jövedelmező módot kínál a felhasználók számára a szoftverek vásárlásához jelentős előzetes költségek nélkül, garantálva a befektetés megtérülését a használat első hónapjában, nem pedig a távoli jövőben.

A tény az, hogy a mobil eszközökön lévő böngészők gyakorlatilag nem voltak támogatottak. A helyzet drámai módon megváltozott a WebKit nevű technológia megjelenésével, amely az iPhone-nak köszönhetően magabiztosan elfoglalta helyét a mobil eszközök terén.

Néhány év alatt az iPhone platform a világ első számú webes kliensévé vált. Miért? Mivel a WebKit megbízható internetkapcsolattal párosulva sokkal hatékonyabban tette lehetővé a webszolgáltatások mobileszközökön történő használatát, mint bármely más modern böngészőben. Más mobil játékosok is felfigyeltek az új technológiára, és most az egész piac felosztható a WebKit használó vállalatokra, a WebKit használni fogó cégekre és azokra a cégekre, amelyek kifogásokkal állnak elő, hogy nem használják a WebKit.

Mi tehát a WebKit?

WebKit és HTML5

A WebKit egy olyan böngészőmotor, amelyet egyszerre támogatnak a Mobile Safari böngészőhöz az iPhone platformon, és hogy támogassák a böngészőt az Android platformon. Természetesen a WebKit más mobil eszközökön is használatos, de e cikk alkalmazásában az iPhone és az Android platformok figyelembe vételére szorítkozunk.

A WebKit egy nyílt forráskódú projekt, amely a K Desktop Environment (KDE) fejlesztéséből származik. A WebKit projektnek köszönhetik születésüket a modern, mobil eszközökhöz készült webalkalmazások. A mobileszköz technológiai és tervezési jellemzői minden bizonnyal fontos szerepet játszanak, de a mobilfelhasználókat elsősorban a tartalom érdekli. Ha egy mobil eszköz az internetes tartalomnak csak egy kis részére nyújt hozzáférést, akkor nem valószínű, hogy bejutna a legnépszerűbb eszközök listájára.

Legtöbben inkább kielégítő életet élnek: ha otthon ülve nyitunk egy webhelyet egy laptopon, akkor azt várjuk, hogy ugyanazt a tartalmat látjuk, amikor a vonaton meglátogatjuk az adott webhelyet. A mobilalkalmazásokkal a fő probléma a tartalom. Nem számít, hol vagyunk és mit csinálunk, hozzáférésre van szükségünk az érdekelt adatokhoz. A WebKit technológia gazdag tartalmat szolgáltat iPhone és Android platformokon.

Érdemes megjegyezni, hogy a WebKit asztali számítógépeken is használatos, például a Safari böngészőben, amely a Mac OS X platform fő böngészője. Függetlenül attól, hogy asztali verziót vagy böngészőmotort terveznek az iPhone vagy az Android számára, a WebKit továbbra is a legfejlettebb technológia. HTML és CSS támogatása. Valójában a WebKit olyan CSS-stílusokat támogat, amelyeket más motorok böngészői még nem renderelnek - példaként megadhat számos olyan tulajdonságot, amelyet a HTML5 specifikáció határoz meg.

A HTML5 egy olyan előzetes műszaki specifikáció, amely olyan böngészőalapú technológiákat határoz meg, mint például az ügyféloldali adattárolás SQL támogatással, áthelyezés, átalakítás stb. A HTML5 specifikáció még nem teljes, de amint az alapok egyértelműen megfogalmazódnak és megvalósításra kerülnek a böngészőkben a legtöbb platformon, a webalkalmazások szerény kezdetei elfelejtett múltvá válnak. A webalkalmazások fejlesztése a szoftverfejlesztés jelentős részét fogja elfoglalni, és nemcsak az asztali böngészőkhöz, hanem a mobil böngészőkhöz kapcsolódó alkalmazásokról is van szó. Melléktermékként a mobilalkalmazások a webes alkalmazások piacán általános áruvá válnak.

A mobil webalkalmazások fejlesztésének tervezési jellemzői

Miután eldöntötte a webfejlesztési technológiák elsajátítását, nagyon kevés eszköz áll rendelkezésére. Először is, egy alkalmazás közvetlenül a szerveren hozható létre HTML, CSS és JavaScript kódot tartalmazó fájlként. Ebben az esetben a HTML-tartalom statikus HTML-fájlként szállítható, vagy dinamikusan generálható a szerveroldalon működő különféle technológiák, például PHP, ASP.NET, Java Servlet stb. Használatával. Mindenesetre a ponttól Az ebben a cikkben tárgyalt kérdések szempontjából mindez a HTML-kódra vonatkozik, és itt a legfontosabb szempont számunkra az, hogy a WebKit technológia lehetővé teszi a böngészők számára a HTML-fájlok megjelenítését mobil eszközökön.

Webes alkalmazás futtatásához mobil eszközön (iPhone vagy Android) a felhasználónak el kell indítania egy böngészőt, és be kell írnia a megfelelő szolgáltatás URL-jét, például: http://vállalkozásneved.com/applicationurl.

Ugyanakkor a kínált mobil webalkalmazások köre meglehetősen széles: a szokásos weboldaltól a kifejezetten egy adott mobilplatformhoz kifejlesztett mobil webalkalmazásig.

Normál webhelyek megjelenítése

A WebKit motor az iPhone és az Android platform intuitív és felhasználóbarát kezelőfelületével kombinálva lehetővé teszi, hogy gyakorlatilag bármely webhelyet megtekinthessen mobileszközén. A weboldalak teljesen helyesen jelennek meg, ellentétben az előző generációs mobil böngészőkkel, amelyek önkényesen szállítottak tartalmat vagy egyáltalán nem jelenítették meg őket. Amikor az oldalakat egy WebKit-kompatibilis böngészőbe töltik be, az oldal tartalma általában méretarányos. Ebben az esetben a méretarányt úgy választják meg, hogy az egész oldal elférjen a képernyőn, bár nagymértékben csökkentett, gyakran olvashatatlan formában, amint az az 1. ábrán látható. Mindazonáltal az oldal görgethető, nagyítható, áthelyezhető, kényelmes hozzáférést biztosítva az összes tartalmi elemhez ... Alapértelmezés szerint a böngésző 980 képpontos széles ablakot használ.

Míg a weboldal teljes megjelenítése egy böngészőablakban önmagában is jelentős előrelépés az előző generációs böngészők használatának tapasztalataihoz képest, a modern mobil technológiák képességei nem korlátozódnak erre.

Mobilbarát weboldalak

Ha azt szeretné, hogy weblapja hozzáférhető legyen a mobil felhasználók, valamint az általános webfelhasználók számára, a mobil webes alkalmazások számára számos más optimalizálási lehetőséget kell figyelembe venni.

Bár a WebKit helyesen tudja megjeleníteni a weboldalt a mobileszközök képernyőjén, különbség van az egeret használó eszközök (például laptop vagy asztali számítógép) és az érintőkészülékek, például az iPhone vagy az Android okostelefonok között. Az érintőeszközök megkülönböztethetők a "kattintás" terület fizikai méretével, a kurzor bármely elem fölé viselésének funkciójának hiányával és egy másik eseménysorral. Így, ha olyan weboldalt szeretne létrehozni, amely kényelmes mind az általános, mind a mobil felhasználók számára, figyelembe kell vennie a mobileszközök alábbi jellemzőit:

Az iPhone és az Android böngészők képesek az egész weboldalt meglehetősen olvasható formában megjeleníteni - ezeknek a böngészőknek a megjelenítési minősége jóval magasabb, mint a szokásos mobil böngészőké -, ezért ne legyen túl gyors a webhelytervezés egyszerűsítéséhez.
Az ujjbegyek mérete sokkal nagyobb, mint az egérmutató mérete. Vegye figyelembe ezt a tényezőt a webhely navigációs elemeinek megtervezésekor. Ne helyezzen linkeket túl közel egymáshoz, különben a felhasználó nem tud kattintani egy linkre anélkül, hogy elütné a szomszédot.
Az egérmutatón megjelenített elemek nem fognak működni mobileszközökön. A felhasználó egyszerűen nem "mutathatja" az ujját egyetlen elem felett sem, ugyanúgy, mint az egér kurzor.
Az egérgomb lenyomásával és nyomva tartásával, az egérrel történő húzással stb. Meghatározott eseményeket az érintőképernyőkön más módon valósítják meg. Ezen események némelyike \u200b\u200bműködhet mobileszközökön, de általában nem szabad elvárni, hogy a mobilböngésző és az asztali böngésző ugyanazt a műveletsort hajtsa végre.

Ezeknek a szempontoknak a részletes tárgyalását a „ iPhone működés közben"(Lásd a szakaszt). Ebben a cikkben a WebKit előnyeinek megvitatására szorítkozunk, nem pedig hátrányaira.

Vessünk egy pillantást arra a legnyilvánvalóbb problémára, amellyel az iPhone vagy Android felhasználók szembesülnek a webhelyek elérésekor, a korlátozott képernyőmérettel. Valójában egy modern mobil eszköz képernyője 320x480 vagy 480x320, feltéve, hogy a felhasználó a webtartalmat fekvő konfigurációban szeretné megtekinteni. Amint az 1. ábrán látható, a WebKit képes a szokásos asztali számítógépekhez tervezett weboldal megfelelő megjelenítésére. Ha azonban egy weblapot kicsinyítenek, akkor a szöveg túl kicsi lehet az olvasáshoz, ezért a felhasználónak görgetnie, pásztáznia és nagyítania kell, mielőtt elolvassa a szöveget. Hogyan kezelhető ez a korlátozás?

A mobilböngésző és az asztali böngészőablakban egyaránt jól megjelenő oldal létrehozásának legegyszerűbb módja egy egyedi metacímke használata nézetablak.

A metacímke egy HTML címke, amelyet a HTML dokumentum fejébe helyeznek. A nézetablak-címke használatának legegyszerűbb példája így néz ki: ... Amikor hozzáadja ezt a metacímkét egy HTML-oldalhoz, annak megjelenítése a mobil böngésző ablakában a legoptimálisabb módon skálázódik (lásd a 2. ábrát). Azok a böngészők, amelyek nem támogatják a nézetablakot, egyszerűen figyelmen kívül hagyják ezt a címkét.

Bizonyos esetekben hasznos előre meghatározni az ablak méretezési paramétereit, amint azt a 3. ábra mutatja.

Konkrét méretezési beállítások megadásához adja meg a nézetablak metacímke tartalmi attribútumának pontos értékét: ... A kezdeti skála paraméterének megváltoztatásával a kép kicsinyíthető vagy nagyítható. IPhone és Android platformoknál jobb, ha 1,0 és 1,3 közötti értékeket használunk. A nézetablak metacímke támogatja a min és max méretezést is, ami korlátozza a felhasználó képességét az oldal méretezésére betöltés közben.

Míg az iPhone tervezési jellemzői, különös tekintettel a 320x480-as képernyő méretére, megalakulása óta gyakorlatilag változatlanok maradtak, az Android platformon lévő eszközök paraméterei meglehetősen széles skálán mozognak, mivel az ezen a platformon található mobileszközöket különböző gyártók gyártják, és a legkülönbözőbb felhasználói csoportoknak szánják őket. Ezért, ha azt szeretné, hogy webalkalmazása népszerű legyen a mobil felhasználók körében, tisztában kell lennie az Android-eszközök képernyőméretének, felbontásának és kialakításának lehetséges eltéréseivel.

A tapasztalatok azt mutatják, hogy a különféle Android mobil eszközök közötti tervezési különbségek mellett az Android szoftver maga is megpróbálja módosítani a betöltött weboldal beállításait a mobil eszköz böngészőjének tulajdonságai alapján. A stabilitás mellett az Android platform folyamatosan változó funkciókkal és képességekkel rendelkezik. Egy adott Android-eszköz beállításai valószínűleg eltérnek az Ön fejlesztői környezetében beállítottaktól, az SDK verziójától és az eszköz gyártójától függően. A 4. ábra a böngésző konfigurációs képernyőjét mutatja a V1.6 Android Emulator alkalmazásban. A képernyőbeállítások lehetővé teszik a felhasználó számára, hogy meghatározza a kép nagyítási szintjét a képernyőn (távoli, közeli, közepes), vagy kiválassza az automatikus oldalméretezési módot.

A mobil eszközök világában a változás a legállandóbb, ezért figyelembe kell venni a mobil szoftverek piacának fejlődését és megújulását. Például a Sprint Hero böngészőbeállításai olyan opciókat tartalmaznak, amelyek teljesen eltérnek a weboldal betöltésekor használt alapértelmezett beállításoktól. A Hero böngésző az Android V1.5 platformra épül, a HTC számos módosításával. Szerencsére a nézetablak metacímke használatakor a hősspecifikus beállítások figyelmen kívül maradnak.

Eddig azt láttuk, hogy a WebKit elég jól tudja kezelni a weboldal betöltését, jóllehet jelentősen csökkentett és nehezen olvasható formában. Ezután a nézetablak metacímke használatával kiterjesztettük az oldal mobil képernyőn történő megjelenítésének ellenőrzését. A megjelenített oldal már sokkal könnyebben olvasható és navigálható. De ez még mindig nem elég ahhoz, hogy oldalunk úgy nézzen ki és működjön, mint egy webalkalmazás.

Mobileszközökhöz készült

Térjünk át arra, hogy megvizsgáljuk a weblap tervezési jellemzőit a mobil közönség számára. Konkrét példaként vegyük figyelembe a Google e-mail regisztrációs oldalát a GMail számára.

Így néz ki ez az oldal egy asztali böngésző ablakában:

Az asztali böngészőablak információs tartalmat jelenít meg a bal oldalon, maga a regisztrációs ablak pedig a jobb oldali ablaktáblában található. A mobil böngészőablakban ugyanaz az oldal teljesen más megjelenést mutat.

A 6. ábrán látható oldal mindenképpen a mobilfelhasználókat célozza. A képernyőn csak azok az oldalelemek jelennek meg, amelyek a felhasználó számára szükségesek a további munkához - nincs szükség további görgetésre, elmozdításra vagy méretezésre.

Most nézzük meg a Gmail mobil verziójának e-mail megjelenítőjét. Mivel az alkalmazás számára rendelkezésre álló képernyőtér nagyon korlátozott, az üzenetnézegető további gombokkal és navigációs elemekkel rendelkezik. Ebben az esetben a megjelenített navigációs elemek átfedik az ablakot az üzenetek megtekintéséhez. Ne használjon túl sok keretet vagy görgető divet, ha elkerülheti. A Gmail mobil verziója megoldja ezt a problémát egy előugró menü használatával, amely megjelenik, amint a felhasználó befejezi az oldal görgetését. Az előugró menü 3 gombot tartalmaz: Archívum, Töröl és Több... A gomb megnyomásával Több további menüpontok jelennek meg (lásd 7. ábra).

Ez valóban egy mobileszközökhöz tervezett alkalmazás.

Nem szabad megfeledkezni arról, hogy nem akarjuk szándékosan elszegényíteni a dizájnt és csökkenteni azoknak a mobil felhasználóknak a tapasztalatait, akik többfunkciós böngészőket fejlesztettek ki az iPhone és az Android platformokra. Ebből a szempontból hasznos észrevenni a Gmail oldal alján megjelenő elemet (lásd: 8. ábra):

Ha a felhasználó az asztali verzió kibővített funkcióit részesíti előnyben, akkor adja meg az oldal megfelelő verziójának letöltését.

Most vegye figyelembe azt az esetet, amikor olyan alkalmazást szeretne létrehozni, amely webes technológiákat használ, de natív mobilalkalmazásnak tűnik.

Platformspecifikus tartalom

A következő lépés egy adott mobil platformra jellemző tartalom fejlesztése. Ez úgy határozza meg az oldal formátumát és felületét, hogy az eredményül kapott oldal egy adott platform natív alkalmazásának nézzen ki, nem pedig egy szabványos nyilvános webhelynek. Mit értünk "natív" alkalmazás alatt?

Mielőtt belevetném magunkat a vitába, hogy miként lehet egy webalkalmazást minél hasonlóbbá tenni egy adott platform natív alkalmazásához, hagyjuk figyelmen kívül az iPhone és az Android böngészők közös tulajdonságait, és röviden foglalkozzunk a platformok közötti vizuális különbségekkel.

Az iPhone-alkalmazások saját külsővel és interfésszel rendelkeznek. Mutasson meg valakinek egy képernyőképet az iPhone-ról, és ha ez a személy szó szerint nem esett le a Holdról a minap, akkor szinte biztosan azonnal azt mondja, hogy ez egy iPhone. Mutassa meg ugyanannak a személynek az Android-mobileszköz képernyőképét, és a válasz már nem lesz ilyen egyértelmű. Mi az ok? Számos lehetséges magyarázat létezik. Először is, az iPhone sokkal korábban jelent meg a piacon, mint az Android készülékek, és rengeteg rajongót sikerült megszereznie. Gondoljon azokra az emberekre, akik sorban állnak, hogy sok pénzt fizessenek a V1 iPhone korlátozott képességeiért. Akár tetszik az iPhone, akár nem, ez az Apple termék jelenleg a piacvezető. Mi a helyzet az Androiddal?

Az Android platform egy viszonylag új termék, és sok szempontból az iPhone ellentéteként működik, mivel elsősorban a nyitott közösség számára készült. Az Android platformot sokféle eszközben használják (telefonok és egyéb háztartási gépek). A vita megkönnyítése érdekében ez a cikk az Android mobiltelefonokon történő használatára korlátozódik.

Idővel az Android-eszközök száma a világon meghaladja az iPhone-ok számát. Az Android-eszközöket ugyanis számos vállalat gyártja, és sokféle adathálózat fogja támogatni. Ilyen jelentős számú szereplővel az Android mobilpiacon kétségtelen, hogy az eszközök megjelenése és paraméterei alapján bizonyos piaci széttagoltságra kell számítani. Ez a tendencia nyilvánvaló a HTC SenseUI-jában. Ezt a vonzó megjelenést és támogatást az alap Android SDK nem támogatja, és nem kompatibilis más Android-eszközökkel. A Motorola, a Google és a Verizon összefogtak egy új Android-alapú DROID eszköz kifejlesztésében. Ez az első kereskedelmi termék az Android 2.0 platformon.

Hasonlítsa össze az Android rendszerek sokszínűségét az iPhone egységes megjelenésével és hangulatával. Az iPhone az Apple különösen értékes tulajdonsága. Az iPhone-alkalmazások megjelenése az idő múlásával kissé megváltozhat, de ezek a kisebb változások valószínűleg nem hasonlíthatók össze az androidos rendszerek különféle verzióival, amelyek száma még most is meglehetősen nagy, amikor a platform nagyon korai szakaszában van.

Tehát mit kell tenni annak érdekében, hogy az alkalmazás megjelenése és felülete a lehető legközelebb álljon a "natív" programokhoz?

Ha ez lenne a kihívás a Web 2.0 előtt, akkor az igazán nagy probléma lenne. A több ügyfélböngésző (mobil és asztali) támogatásának korai kísérletei számos megközelítést támasztottak alá, például:

Teljesen párhuzamos telephelyek fejlesztése
Dinamikus tartalom létrehozása a userAgent paramétertől függően
Olyan proxy szerverek használata, amelyek az egyes eszközöktől függően átalakíthatják a tartalmat. Ezt a technológiát a RIM sikeresen alkalmazta az e-mail elérésének biztosítására az ügyfél mobileszközéről.

Az ilyen megközelítések meglehetősen elfogadhatóak lehetnek olyan esetekben, amikor a fejlesztést nagy, jól finanszírozott csapatok végzik. És mi van a világ többi részével? Nem mindenki rendelkezik jelentős pénzügyi forrásokkal, magasan képzett szakemberekkel és korlátlan idővel az ilyen stratégiák megvalósításához. Ezenkívül, amint azt már megjegyeztük, az előző generációs böngészők mobilinternetét nem lehet kényelmesnek vagy népszerűnek nevezni, ezért semmiképpen sem szabad elidőzni az elavult módszereken és megközelítéseken.

Szerencsére ezt nem kell megtennünk. A WebKit és a CSS korszakában a különböző mobileszközök megjelenésében és stílusában mutatkozó különbség áthidalható a stíluslapok és a média lekérdezések használatával, amelyek lehetővé teszik a különböző stílusok használatát az adott eszköz típusától függően. A média lekérdezések technológiája lehetővé teszi, hogy információkat szerezzen az ügyfélről. Hagyományosan a böngésző egy userAgent értéket küld a kiszolgálónak, amely lehetővé teszi a kiszolgáló számára, hogy azonosítson egy adott böngészőt és meghatározza az ügyfél számára kiszolgált tartalmat. Média lekérdezéssel a böngésző képességei alapján választja meg az oldalstílust. A következő példa bemutatja az okostelefonok stíluslapjának kiválasztását: ... És ez a lekérdezés meghatároz egy stíluslapot az asztali számítógépekhez: .

Internet Explorer V6

Az írás idején az Internet Explorer V6 nagyjából 20-30% -os részesedéssel rendelkezik a böngészők teljes piacán, de az IE V6 meghaladja a cikk kereteit.

A média lekérdezésekről részletesebb információkat talál a specifikáció tervezetében (lásd a szakaszt).

Vegyünk egy példát a média lekérdezések használatára a hálózati szerverek állapotát megjelenítő alkalmazás kifejlesztésére.

Hálózatfigyelő program

Az alkalmazás célja több szerver működésének figyelemmel kísérése. A független szoftvergyártóknak gyakran több alkalmazást kell támogatniuk több szerveren. Ha jelentős ideig fejlesztett szoftvereket, akkor valószínűleg már találkozott különböző típusú szerverekkel és különböző típusú alkalmazásokkal. Mindez azt jelenti, hogy teljesen lehetséges egy olyan helyzet, amikor egyetlen eszközzel sem tudja nyomon követni az összes szükséges alkalmazás munkáját. Ebben az esetben van értelme mobilalkalmazást használni a hálózati megfigyeléshez (netmon). Az alkalmazás biztosítja az összes szükséges funkciót, miközben rugalmas és könnyen elérhető mobil eszközről.

A netmon alkalmazás tartalmazza a figyelni kívánt szerverek listáját. A legfontosabb teljesítménymutatókat (KPI) minden kiszolgálóra összegyűjtjük. A KPI az elsődleges eszköz, amelyet az MBA hallgatók hosszú évek óta használnak egy vállalkozás jelenlegi állapotának felmérésére. A webalkalmazások tárolása tekintetében a következő mutatók használhatók KPI-ként:

Tranzakciók száma az elmúlt időszakban
- Rendelések
- Könyvtárkérések
- E-mail üzenetek
- Oldalmegtekintések
A legutóbbi tranzakció óta eltelt idő
- Rendelés
- Elektronikus adatcsere
- Üzenetek egy üzleti partnertől
- A fájlok feltöltése a szállítótól FTP-n keresztül
Elérhető-e az adatbázis
Utolsó biztonsági mentés dátuma
Átlagos rendelési összeg (USD)
Szabad lemezterület
Sávszélesség az utolsó órára, napra, hónapra

A fenti mutatók és más hasonló működési paraméterek lehetővé teszik egy adott rendszer vagy alkalmazás állapotának felmérését. Például az ünnepi szezonban felülvizsgáljuk az egyes webhelyeinken leadott megrendelések számát. Ha az adatok nem mutatják óránként a megrendelések számának folyamatos növekedését, részletesebb elemzést készítünk a helyzetről.

Mivel egy adott alkalmazás saját feltételeket és erőforrásokat igényel, a netmonnak elég rugalmasnak kell lennie ahhoz, hogy alkalmazkodjon az egyes alkalmazások sajátosságaihoz. Ennek a rugalmasságnak a biztosítása érdekében kezdjük azzal, hogy meghatározzuk a legáltalánosabb adatstruktúrát az egyes rendszerek állapotának megfelelően. A 2. részben közelebbről megvizsgáljuk, honnan származnak és hogyan frissülnek ezek az adatok. Egyelőre a következő információkra korlátozódunk:

Webhely neve
Webhely (kezdőlap) URL
URL a frissítések letöltéséhez
Állapot: OK vagy sem
Röviden: A szerver állapotának leírása, amely vagy rendben lesz, vagy tartalmaz egy szöveges karakterláncot, amely jelzi a kiszolgáló legsúlyosabb problémáját
Elemek: Ez a név / érték pár halmaza, amelyet kommunikálnunk kell az adott webhely aktuális KPI értékeivel.

Alkalmazásunk az eredményül kapott teljesítménymutatókat könnyen kezelhető módon jeleníti meg, a lehető legtöbbet kihasználva a CSS, a jQuery és a WebKit erejét, hogy felhívja a felhasználó figyelmét a problémás területekre. Mint már említettük, az alkalmazás fejlesztése során az a fő cél, hogy az iPhone, Android platformon és az asztali számítógépen futtatható legyen a Safari böngészőben.

Hálózatfigyelő alkalmazások fejlesztése

A modern weboldalakat deklaratív módon kell létrehozni, amely meghatározza az oldal szervezeti felépítését és tartalmát. Az oldal pozícionálása és formázása lépcsőzetes CSS stíluslapok használatával, és a legtöbb esetben JavaScript használatával történik. Valójában a JavaScript könyvtárak annyira népszerűek lettek, hogy használatuk ma inkább szabály, mint kivétel. A cikkben tárgyalt alkalmazáshoz a népszerű JavaScript könyvtár jQuery-t fogjuk használni. Alkalmazásunk az iPhone, az Android és az asztali platformokon fog futni. Ez ugyanazt a HTML-kódot fogja használni, és végrehajtja a szükséges eltéréseket a stíluslapokban. Itt kell megjegyezni, hogy szándékosan nem tettünk jelentős erőfeszítéseket az alkalmazás vonzó megjelenésének kialakítása érdekében. Sőt, a hátteret szándékosan fülbemászónak, egymással összhangban lévőnek választották, hogy az olvasó további figyelmet fordítson a stíluslapok rendszerezésére. A 2. részben némileg javítjuk az alkalmazás megjelenését, de HTML-je most úgy néz ki, mint az 1. listában.

Felsorolás 1. Alkalmazás HTML kódja

Saját hálózati erőforrások

Saját felhasználói ügynök

A javasolt HTML-kód gyors pillantása a következő főbb jellemzőket tárja fel:

A kód két külső JavaScript fájlt használ: egy jQuery könyvtár fájlt és egy segítő fájlt alkalmazásunkhoz.
A kód a nézetablak metacímkéjével méretezi a megjelenített tartalmat.
A fő stíluslapot a netmon.css fájl határozza meg.
A userAgent paraméter segítségével definiálható a kiegészítő stíluslap. Értékétől függően egy stíluslap kerül betöltésre iPhone, Android vagy asztali böngészőhöz.
Az oldal betöltése során a jQuery és a netmon.js fájlban definiált segítő funkció használható az adatok megjelenítésére.
Az oldal főkódjában több div tag is szerepel.
Végül a kódban található egy link egy oldalra, amely megmutatja a userAgent karakterláncot. Ennek a linknek semmi köze az alkalmazáshoz, és kizárólag demonstrációs célokra használható.

Mielőtt részletesen áttekintenénk a stíluslapokat és a netmon.js fájlt, amelyek valóban meghatározzák az alkalmazás alapvető működését, vessünk egy pillantást alkalmazásunk jelenlegi állapotára. Megjegyezzük még egyszer, hogy három különböző stíluslapot használunk, egyet a három támogatott platformhoz. Az alkalmazásfejlesztési folyamat vizuálisabbá tétele érdekében minden táblázat meghatározza a saját háttérszínét. A 9. ábrán oldalunk nyitva van az Asztali Safari alkalmazásban, és kék háttérrel rendelkezik.

A 11. ábra mutatja az alkalmazás megjelenését egy iPhone böngészőablakban (a háttér színe zöld).

A netmon.js fájlban tárolt fő stíluslap a 2. listában látható.

Felsorolás 2. Fő stíluslap

törzs (szín: # 888888; font-család: Helvetica; betűméret: 14 kép; margó: 0 kép; kitöltés: 0;). részletek (margó: 0 kép; kitöltés: 0 kép; háttérszín: fehér; szegély: folytonos; szegély -szélesség: 1px; -webkit-border-bal-bal felső sugár: 8px; -webkit-border-jobb-jobb-sugár: 8px; -webkit-border-bal-bal oldali sugár: 8px; -webkit-border-bottom -right-radius: 8px;) .OK (color: # 000000;). BAD (color: # ff0000;) .odd (background-image: -webkit-gradient (lineáris, bal felső, jobb alsó, a (#ccc) ), to (# 999));) .even. (háttérkép: -webkit-gradiens (lineáris, bal felső, jobb alsó, (# 999) - (#ccc));). szerverentry a (float: jobbra; szín: #ffffff;). serveritems (szín: # 000;) # fejléc h1 (margó: 0; kitöltés: 0; szöveg igazítás: közép; szín: # 000;)

Egyéni stíluslap használata minden platformon lehetővé teszi a következő feladatok végrehajtását:

Módosítsa az oldal színvilágát. Ez lehetővé teszi egyrészt a stíluslap szerepének vizuális bemutatását, másrészt annak megmutatását, hogy mennyire egyszerű kiválasztani a kívánt stíluslapot a userAgent paraméter értékétől függően.
Különböző betűméreteket állíthat be mobil és asztali platformokhoz.
Nézze meg a megfelelő WebKit szolgáltatásokat. Ez akkor lenne jelentős, ha az alkalmazás WebKit-támogatás nélküli böngészőben futtatna, például Firefox.

A 3. lista az iphone.css fájl kódját mutatja.

Felsorolás 3. Az iphone.css fájl

törzs (háttérszín: # 00ff00;) .serverentry (-webkit-border-bal-bal felső sugár: 8px; -webkit-border-jobb-felső-jobb sugár: 8px; -webkit-border-alsó-bal-sugár: 8px; -webkit-border-bottom-right-radius: 8px;) .name (font-size: 2em;) .summary (font-size: 1.5em;) .serverentry a (font-size: 1.5em;)

Mint láthatjuk, a törzscímke háttérszíne zöld (# 00ff00), és a betűméretet a jobb olvashatóság érdekében állítják be a mobileszköz képernyőjén. Végül vessünk egy pillantást a netmon.js fájlra, amely meghatározza a kiszolgálók listáját és egy olyan funkciót, amely minden kiszolgáló számára adatokat ad ki (a 4. listában használatos). A rövidség kedvéért a fájlkód egy részét kihagyták; teljes szövege a szakaszban érhető el).

Listázás 4. A netmon.js fájl

var netmon \u003d (inicializálás: function () (), erőforrások: [(név: "msiservices.com", homeurl: "http://msiservices.com", pingurl: "http://msiservices.com/netmon.php ", állapot:" OK ", összefoglaló:" OK ", elemek: [(név:" DiskSpace ", érték:" 22,13 GB "), (név:" Adatbázis fent? ", értéke:" Igen ")]), (név: "2. szerver", homeurl: "http: // someurl", pingurl: "http: //someurl/netmon.jsp", állapot: "OK", összefoglaló: "OK", elemek: [(név: "DiskSpace", értéke: "100,8 GB"), (név: "Adatbázis felfelé?", Érték: "Igen")]), // további rövidítés céljából kivágott bejegyzések], render: function (index, itm) (try ( var ret \u003d "; ret + \u003d"

"; ret + \u003d" "+ itm.név +" Előadás
"; if (itm.status! \u003d" OK ") (ret + \u003d" - "+ itm.summary +"
";) ret + \u003d"

"; jQuery.each (itm.items, function (j, itemdetail) (ret + \u003d"\u003e "+ itemdetail.name +" \u003d "+ itemdetail.value +"
";)); ret + \u003d"

"; ret + \u003d"

"; vissza ret;) fogás (e) (vissza"

Hiba történt az [[+ itm.név + "]" + e + "elem renderelésekor

"; } } };

Ha valamelyik kiszolgáló állapotsora nincs rendben, akkor a megfelelő kiszolgálói rekord piros színnel jelenik meg, amint azt a CSS fájl osztálydefiníciója mutatja. Ezenkívül, ha a szerver állapotának ellenőrzése problémákat tár fel (az állapot nem egyenlő az OK-val), akkor a probléma rövid leírása is megjelenik. A 9-11. Ábrákon láthatja, hogy a 4. szerverben kevés a szabad lemezterület. Amikor rákattint a szerver sorára, megjelenik a problémáról szóló részletes üzenet (lásd: 12. ábra).

Kattintson a linkre előadás a kiszolgáló nevétől jobbra megnyílik a szerver kezdőlapja. Az ilyen link birtoklása két okból is nagyon kényelmes: egyrészt megtakarítja az összes szerver URL-jének memorizálásával járó problémát, másrészt pedig még annál is frusztrálóbb igényt rejt az URL-cím beírása a mobil billentyűzetén ( akár a legkényelmesebb).

Tehát, ha sikeresen tudjuk futtatni a netmont mobileszközön, akkor a szervertámogatási feladat nem okozhat problémát.

Következtetés

Ez a cikk bemutatja az iPhone és az Android webalkalmazások WebKit technológiával történő fejlesztésének alapelveit. A 2. részben az alkalmazás Ajax hívásokkal történő frissítéséhez szükséges funkciók hozzáadásával bővítjük alkalmazásunk képességeit.

Átruházás

Webkészlet nem fekete doboz. Ez egy fehér doboz. És nem csak fehér, hanem nyisd ki doboz.

Tehát próbáljunk kitalálni néhány dolgot:

Mi a WebKit?
Mi nem a WebKit?
Hogyan használják a WebKit-et a WebKit böngészők?
Miért nem ugyanaz a sok WebKits?

Normál webböngésző-összetevők

Soroljunk fel néhány összetevőt a modern böngészőkből:

Elemzés (HTML, XML, CSS, Javascript elemzése)
Elrendezés
Szöveg és grafika renderelése
Képek dekódolása
GPU interakciók
Hálózati hozzáférés
Hardveres gyorsítás

Melyik a közös az összes WebKit böngészőben? Nagyjából csak az első kettő.

Minden WebKit "port" más összetevőket valósít meg a maga módján. Nézzük, mit jelent ez.

WebKit portok

Sok a WebKit "portja", és én biztosítom Aria Hidayat-ot, a WebKit hackert és azokat. a Sencha igazgatójának joga van elmondani róla:

A WebKit legnépszerűbb társítása általában az Apple WebKitje, amely Mac OS X-en (az első és az eredeti WebKit könyvtár) fut. Mint sejteni lehet, a különféle interfészeket különféle natív Mac OS X könyvtárak segítségével valósítják meg, többnyire összpontosítva a CoreFoundation komponensben Például, ha színes lapos gombot definiál egy speciális körvonal sugárral, akkor a WebKit tudja, hogy hol és hogyan kell felhívni azt a gombot, míg a gomb végleges megjelenítése (pixelként a felhasználó monitorján) a CoreGraphicsra esik.

Mint fent említettem, a használt CoreGraphics minden WebKit port esetében egyedi. A Chrome for Mac például a Skia szoftvert használja.

Valamikor a WebKit-et különböző platformokra "portolták", asztali és mobil platformokra egyaránt. Ezt a variációt általában "WebKit portnak" nevezik. A Safari Windows esetében az Apple a (korlátozott megvalósítású) CoreFoundation könyvtár segítségével önállóan is „portolta a WebKit-et” a Windows rendszeren történő futtatásra.

... annak ellenére, hogy a Safari for Windows már nem működik.

Ettől eltekintve sok más "port" is létezett (lásd a teljes listát). A Google létrehozta és továbbra is fenntartja Chromium portját. Van a WebKitGtk is, amely a Gtk + alapú. A Nokia (és most a Trolltech, aki megvette) fenntartja a WebKit Qt portot, amely QtWebKit modulként vált népszerűvé.

A WebKit egyes portjai

Szafari
- Safari OS X alatt és Safari Windows alatt két különböző port
- A WebKit Nightly Build a Safarihoz használt Mac "port" forráskódjának összeállítása, csak újabb
Mobil Safari
- Magán fiókban fejlesztették ki, de később megnyitották.
- Chrome iOS rendszerhez (az Apple WebView alkalmazását használja; kicsit később a különbségről)
Króm (króm)
- Chrome Androidhoz (közvetlenül használja a Chromium "portot")
- A Chromium az alapja a böngészőknek is: Yandex ,, Sogou, és hamarosan az Opera.
Android böngésző
- A kiadáskor rendelkezésre álló legújabb WebKit forráskódot használja.
Még több port: Amazon Silk, Dolphin, Blackberry, QtWebKit, WebKitGTK +, Az EFL port (Tizen), wxWebKit, WebKitWinCE stb.

Mi minden WebKit böngészőben közös

Először vessünk egy pillantást az összes WebKit böngészőben használt közös szolgáltatásokra:

Tudod, hogy ez vicces, többször próbáltam megírni ezt a bekezdést. És valahányszor a Chrome csapat tagjai kijavítottak, amint látni fogod ...

És így először is a WebKit ugyanúgy elemzi a HTML-t. Nos, kivéve, hogy a Chromium az egyetlen olyan port, amely jelenleg engedélyezi a HTML elemzés streaming támogatását.
... Ok, de a HTML elemzése után a DOM fa ugyanúgy felépül. Nos, a Shadow DOM valójában csak a Chromium portnál engedélyezett, így a DOM felépítése változó. Egyedi elemekhez is.
... Rendben, a WebKit mindenki számára egyforma ablak- és dokumentumobjektumokat hoz létre. Igaz, bár az általuk nyújtott tulajdonságok és konstrukciók a jellemző zászlók használatától függhetnek.
... A CSS elemzése ugyanaz. A CSS megevése és CSSOM-ba konvertálása meglehetősen szokásos. Igen, bár a Chrome csak az -webkit- előtagokat támogatja, míg az Apple és más böngészők az elavult -khtml- és -apple- előtagokat.
… Elrendezés… pozicionálás? Olyan, mint a kenyér és a vaj. Mindenhol ugyanaz, igaz? Hát már! Az alpixeles elrendezés és a gazdag elrendezésű aritmetika a WebKit része, de portonként eltérő.
Szuper.

Tehát ez nehéz.

Most próbáljuk meg összefoglalni, mi jellemző a WebKit világban ...

Mi a közös az egyes WebKit portoknál.

DOM, ablak, dokumentum
többé-kevésbé
CSSOM
CSS tulajdonság / érték elemzése
különbségek a gyártói előtagokban
A HTML elemzése és a DOM felépítése
Ugyanez, ha megfeledkezünk a webkomponensekről.
Elrendezés és elhelyezés
Flexbox, Floats, blokk-formázó kontextus ... minden közös
A felhasználói felület eszközei és a fejlesztői eszközök, például a Chrome DevTools más néven WebKit inspector.
Bár tavaly április óta a Safari saját, nem WebKit ellenőrzőjét használja, zárt forráskódú.
Olyan funkciók, mint a contenteditable, a pushState, a File API, a legtöbb SVG, a CSS transzformációs matematika, a Web Audio API, a localStorage
A megvalósítás azonban eltérhet. Minden port a saját tárhelyét használhatja a localStorage számára, és a Web Audio API-hoz más audio API-t is használhat.

Ez kissé zavaros, ezért próbáljuk meg megvizsgálni a különbségeket.

Ami nem jellemző a WebKit portokra:

Bármi, ami GPU-val kapcsolatos
- 3D transzformációk
- WebGL
- Video dekódolás
2D rajzolása a képernyőre
- Aliasing technológiák
- SVG és CSS színátmenetek renderelése
Szöveg és elválasztás renderelése
Hálózati technológiák (SPDY, pre-rendering, WebSocket transport)
JavaScript motor
- A JavaScriptCore motor a WebKit adattárban található. De vannak olyan kötések a WebKit-ben, mind a V8-hoz, mind a V8-hoz.
Forma elemek renderelése
Videó és hangcímke viselkedése és kodek támogatás
Képek dekódolása
Vissza / előre navigáció
- A pushState () rész
Az SSL funkciók, például a szigorú közlekedésbiztonság és a nyilvános kulcsok

Vessünk egy pillantást egyikükre: 2D-s grafika a porttól függ, teljesen más könyvtárakat használunk a képernyőn történő megjelenítéshez:

A diagram segít:

Számos WebKit komponens kapcsolható (szürke színnel látható).

„A WebKit olyan, mint egy szendvics. Egyébként a Chromium esetében ez inkább taco. Finom tacók a webes technológiákból.
Dmitri Glazkov, a Chrome WebKit hacker. A Web Componets bajnoka és az árnyékdom.

	Chrome (OS X)	Safari (OS X)	QtWebKit	Android böngésző	Chrome iOS rendszerhez
Rendering	Skia	CoreGraphics	QtGui	Android verem / Skia	CoreGraphics
Hálózatépítés	Chromium hálózati verem	CFNetwork	QtNetwork	Villa a Chromium hálózati vereméből	Króm verem
Betűtípusok	CoreText a Skia-n keresztül	CoreText	Qt belső részek	Android verem	CoreText
JavaScript	V8	JavaScriptCore	JSC (a V8-ot a Qt másutt használják)	V8	JavaScriptCore (JITting nélkül) *

Oké, akkor hova jöttünk?

Így minden WebKit teljesen más. Félek.

Az Opera a WebKit-re költözött. Mi lesz belőle?

... és a WebKit éjszakai felépítése. Mi az?

Ez a WebKit, amely ugyanazon a kódon fut, mint a Safari (bár néhány belső könyvtárat módosítottak). Leginkább az Apple futtatja, így a viselkedés és a szolgáltatáskészlet megegyezik azzal, amit a Safariban talál. Sok esetben az Apple konzervatív, amikor olyan funkciókat engedélyez, amelyeket más portok implementálnak vagy kísérleteznek. Egyébként az analógiák használatához gondoljon arra, hogy ... a Safari WebKit éjszakai felépítése olyan, mint a Chromium a Chrome-hoz.

webböngészők

webfejlesztés

Címkék hozzáadása

A böngészőmotor egy speciális program, amely weblapokkal működik. Feldolgozza az internetről letöltött HTML oldalt, és kódját átalakítja a felhasználók számára ismert reprezentációvá. Az internetes böngészőmotorokat maguk a böngészők, valamint az e-mail kliensek használják. Nem minden webböngésző a saját egyedi platformjára épül. Közülük sokan népszerű és idővel bevált megoldásokat alkalmaznak. Ez a cikk azt tárgyalja, hogy milyen platformok léteznek a böngészők felépítéséhez, és miben különböznek egymástól.

A Rendering motor használatával böngészők létrehozásához számos előnye van:

Megkönnyíti a kódhibák keresését és kiküszöbölését.
Kényelmes lehetőség egyetlen komponens javítására több programban egyszerre.
Megkönnyíti az alkalmazás grafikus felületének megváltoztatását.
Könnyű új programokat létrehozni egy adott fejlesztő vagy egy felhasználó kívánságai szerint.

Az ilyen megoldásokat nagyon gyakran használják a programozásban: videojátékok létrehozásakor, operációs rendszerek komplex programokhoz stb. Egyes szakemberek a motor fejlesztésén és optimalizálásán dolgoznak, új funkciókat és hasznos funkciókat vezetnek be benne. Mások maguk is részt vesznek a programok létrehozásában a kidolgozott platform alapján.

Kiváló példa a Microsoft Trident motorja. Egyedül az adott vállalat sokféle alkalmazásában használják. A bázis fejlődik - származékos projektek is fejlődnek.

Minden megoldásnak megvannak a maga előnyei és hátrányai. Például sok felhasználó észreveszi, hogy a Mozilla Firefox sokkal jobban teljesít a nyitottabb fülekkel, mint a verseny. Ez annak a platformnak az eredménye, amelyre a böngésző épül.

Háromágú szigony

Amikor a felhasználó új Windows operációs rendszert telepít, az első webböngésző az Internet Explorer. Ezért motorját tekintik először a felülvizsgálat során.

A Trident vagy MSHTML egy meglehetősen régi szoftverkomponens, amelyet a Microsoft fejlesztett ki saját szükségleteire. A projekt 1997 óta folyamatosan fejlődik. A Microsoft webböngészőjében használják - Internet Explorer, Outlook levelező kliens, Windows Explorer (fájlkezelő program) és a fejlesztő számos más alkalmazásában.

A felhasználók az egyik legsikertelenebb böngészőmotornak tekintik. Nem támogatja a harmadik féltől származó moduláris kiterjesztéseket - a beépülő modulok sok internetes oldalt hibásan jelenítenek meg, nem a leggyorsabb sebességgel.

A Windows 10 megjelenésével a Trident platform EdgeHTML-vé fejlődött, egy elavult, meghibásodott motort vett alapul, és létrehozott egy újat, amely megfelel a mai felhasználók minden igényének. A referenciaértékek (szoftver teljesítmény és sebesség tesztek) alapján a Microsoft Edge (az EdgeHTML-re épülő böngésző) utolérte, sőt felülmúlta a Google Chrome és a Mozilla Firefox böngészők létrehozásához használt népszerű programokat.

Gekkó

A Gecko az a motor, amelyet a népszerű internetes böngésző, a Mozilla Firefox és sok más program használ. A program forráskódja szabadon elérhető, vagyis mindenki teljesen ingyenesen létrehozhatja saját böngészőjét vagy e-mail kliensét a Gecko alapján.

A Gecko másik előnye a cross-platform. A modern operációs rendszerek túlnyomó többségén működik: mind a személyi számítógépek, mind a mobil eszközök számára (ellentétben az Internet Explorerrel, amely csak Windows rendszeren fut).

A Gecko támogatja a weboldal fejlesztés során alkalmazott összes modern szabványt és technológiát. Ez a két legnépszerűbb böngészőplatform egyike. Támogatja a plugins kapcsolatot. A felhasználók teljesítményértékelései és személyes tapasztalatai azt mutatják, hogy ezen a motoron található böngészők a legkevesebb erőforrást fogyasztják a személyi számítógép számára, és stabilan működnek nagyszámú fül mellett (például több száz).

A Gecko alapján létrejön a népszerű internetes böngésző, a Mozilla Firefox, a Thunderbird levelező kliens, a Sunbird feladatütemező és egy névtelen webböngésző, beépített támogatással a VPN-technológiákhoz.

KHTML

Homályos platform a Konqueror, a KDE környezet fájlkezelőjének felépítéséhez. Azoknak a felhasználóknak, akik nem ismerik a Linux család operációs rendszereit, érdekes, mert e projekt alapján elkészült a világ legnépszerűbb motorja, amelyről később lesz szó.

WebKit

Ezt a motort a világhírű Apple vállalat fejlesztette ki a fent említett megoldás - KHTML - alapján. A 2001-ben kiadott projekt óriási fejlődésen ment keresztül, és a világ egyik leggyakrabban használtá vált.

A WebKit alapján létrehozták a Safari webböngészőt, amelyet alapértelmezés szerint használnak az iOS-eszközök, és a böngészők körében a legnépszerűbb - Google Chrome. A weboldalak tartalmának feldolgozására szolgáló modern programok túlnyomó többsége a WebKit-en alapul. A népszerű Steam alkalmazásban is használják a Valve PC-játékainak digitális terjesztésére.

Geckóhoz hasonlóan a WebKit is több platformon fut, és minden népszerű platformon kiválóan működik. Nagy stabilitást és teljesítményt mutat. A hatalmas népszerűség miatt a kiterjesztések túlnyomó többségét erre a megoldásra fejlesztik. Olyan népszerű mobil platformokon is használják, mint az Android és az iOS. Ez egy ingyenes motor, vagyis bárki ingyen használhatja saját alkalmazások létrehozására.

2013-ban a Google vállalathoz tartozó új fiók, a Blink elszakadt a WebKit-től. Ez a projekt képezte a Chrome 28. verziójának (és minden későbbi verziójának) alapját, valamint nyílt forráskódú unokatestvérét - a Chromiumot. A krómot az Oroszországban népszerű Yandex böngésző létrehozására használják. A 15. verziótól kezdve az Opera böngésző is Blinkre váltott.

Gyors

A 2003-ban elindított Presto böngészőmotort használták az Opera alapjául. 10 éve fejlődik. 2013-ban az Opera fejlesztői úgy döntöttek, hogy elárasztják a Presto-t a Google erőteljesebb és legnépszerűbb Blinkje mellett. Jelenleg a projekt fejlesztése leáll.

Hasznos volt ez a cikk?

Ebben a cikkben három böngészőt tekintünk meg a népszerű WebKit motoron. A webböngésző kiválasztásakor a felhasználók általában a leghíresebb programok felé néznek: Google Chrome, Opera, Mozilla Firefox, Internet Explorer. Ugyanakkor sokan elfelejtik vagy nem tudják, hogy ugyanaz a Firefox, Chrome és újabban az Opera nyílt forráskódú projektek alapján jön létre, ami azt jelenti, hogy ezek a programok módosíthatók.

Ez a lehetőség oda vezet, hogy sok programozó a népszerű böngészők számos analógját hozta létre, amelyek meglehetősen érdekes funkciókat kínálnak. Tehát nézzük meg az ilyen szoftverek több képviselőjét.

Ingyenesen terjesztik, orosz felülettel rendelkezik, Windows, Android, Mac, iOS rendszereken működik. Ez a böngésző tíz évvel ezelőtt MyIE2 néven volt ismert, és az Internet Explorer kiegészítője volt, de azóta sok minden megváltozott, és most a program alapértelmezés szerint a Webkit motort használja.

A legújabb, 4. verzióban a böngésző számos hasznos funkciót kínál, amelyek közül a legérdekesebb az információ tárolása a "felhőben". Ez lehetővé teszi egy fiók használatát a programban információk átadására a különböző eszközök között, legyen szó Android modulról, Apple kampánytermékről vagy álló PC-ről.

A Maxthon Cloud Browser kezelőfelülete, bár a Chrome stílusában készült, sokkal több funkcióval rendelkezik. Az oldalsávon ikonok jelennek meg a kiterjesztések eléréséhez. Kényelmes, hogy egy kattintással letilthatja vagy engedélyezheti az összes telepített bővítményt, és újakat letölthet egy speciális webhelyről.

Ingyenesen terjesztik, orosz felülettel rendelkezik, Windows rendszeren működik. A Comodo terméke, amely ismertebb nevén biztonsági szoftverfejlesztő. A Comodo Dragon már nem fejlesztés, hanem összeállítás, mivel a funkcionalitás szempontjából nem sokban különbözik a Chrome-tól.

Nincs sok különbség az eredeti böngészővel szemben, és mindegyik biztonsági kérdésekre vonatkozik. Az első legfontosabb különbség a Google Chrome-tól az inkognitómód, a Comodo Dragon nem használ egyedi felhasználói azonosítót és HTTP-REFERRER-t, ami nem teszi lehetővé a felhasználó nyomon követését a hálózaton.

A második különbség a Comodo alaptevékenységében, a felhasználói biztonságban rejlik. Feltételezi, hogy saját biztonságos DNS-kiszolgálókkal rendelkezik a forgalom továbbításához. Sőt, a felhasználó kérésére nemcsak a Dragonból, hanem az összes többi alkalmazásból származó forgalom is átmehet rajtuk. A biztonságos DNS-kiszolgálók automatikusan blokkolják a hozzáférést azokhoz a webhelyekhez, amelyeket nem megbízhatóként jelöltek meg a Comodo saját Web Threat Definition Network-jén.

Ingyenesen terjesztik, orosz felülettel rendelkezik, Windows rendszeren működik. A Yandex Browser egy nemrég megjelent Chromium-alapú böngésző az orosz Yandex cégtől. Ebben a termékben a fejlesztők egyszerűen hozzáadták a Yandex szolgáltatásokat a gyorshivatkozások panelhez. Hozzáadta és továbbfejlesztette az Operában megtalálható "Turbo" módot is. Általában kiderült, hogy nem egy rossz böngésző, amelyet a Yandex-felhasználóknak szántak.