Tīmekļa pārlūka motori - kādi tie ir un kādi tie ir. Kas ir WebKit un kā tas ir saistīts ar CSS

  • Pārskaitījums

Daudziem no mums izstrādātājiem WebKit - melnā kaste... Mēs tajā iemetam HTML, CSS, JS un ķekaru attēlu, un WebKit kaut kā ... maģiski dod mums tīmekļa lapu, kas izskatās un darbojas labi.
Bet tiešām kā saka mans kolēģis Iļja Grigoriks :

Tīmekļa komplekts nav melnā kaste. Šī ir balta kaste. Un ne tikai balts, bet arī atvērts lodziņā.

Tātad, mēģināsim noskaidrot dažas lietas:
  • Kas ir WebKit?
  • Kas nav WebKit?
  • Kā WebKit izmanto WebKit pārlūkprogrammas?
  • Kāpēc daudzi WebKits nav vienādi?
Tagad, it īpaši pēc ziņām, ka Opera ir pārgājusi uz WebKit, mūs ieskauj daudz WebKit pārlūku, un ir diezgan grūti pateikt, kas viņus vieno un kur viņi iet savu ceļu. Tālāk es ceru, ka mēs centīsimies nedaudz apgaismot šo jautājumu. Tā rezultātā jūs varēsiet labāk noteikt pārlūkprogrammu atšķirības, iesniegt kļūdas pareizajam izsekotājam un efektīvāk attīstīt pārlūkprogrammas.

Standarta tīmekļa pārlūka sastāvdaļas

Uzskaitīsim dažus mūsdienu pārlūkprogrammu komponentus:
  • Parsēšana (HTML, XML, CSS, Javascript parsēšana)
  • Izkārtojums
  • Teksta un grafikas atveidošana
  • Atkodējiet attēlus
  • GPU mijiedarbība
  • Piekļuve tīklam
  • Aparatūras paātrinājums
Kuras no tām ir kopīgas visām WebKit pārlūkprogrammām? Diezgan tikai pirmie divi.

Katru WebKit "portu" pārējos komponentus ievieš savā veidā. Apskatīsim, ko tas nozīmē.

WebKit porti

Ir daudz WebKit "pieslēgvietu", un es piedāvāju Aria Hidayat, WebKit hakeri un citus. Sencha direktoram ir tiesības par to pastāstīt:

Populārākā WebKit asociācija parasti ir Apple sava veida WebKit, kas darbojas uz Mac OS X (pirmā un oriģinālā WebKit bibliotēka). Kā jūs varētu uzminēt, dažādas saskarnes tiek ieviestas, izmantojot dažādas vietējās Mac OS X bibliotēkas, galvenokārt koncentrējoties uz komponentā CoreFoundation Piemēram, ja definējat krāsainu plakanu pogu ar īpašu kontūras rādiusu, WebKit zina, kur un kā šo pogu uzzīmēt, savukārt pogas galīgā atveidošana (kā pikseļi lietotāja monitorā) ietilpst CoreGraphics.

Kā jau minēju iepriekš, izmantotā CoreGraphics ir unikāla katram WebKit portam. Piemēram, pārlūkā Chrome Mac tiek izmantota Skia.

Kādā brīdī WebKit tika pārnests uz dažādām platformām - gan datoriem, gan mobilajām ierīcēm. Šo variantu parasti sauc par “WebKit portu”. Operētājsistēmai Safari Windows Apple arī patstāvīgi "portēja WebKit", lai palaistu operētājsistēmā Windows, izmantojot tās (ierobežotas ieviešanas) CoreFoundation bibliotēku.

... neskatoties uz to, ka Safari operētājsistēmai Windows tagad ir miris.
Bez tam bija arī daudzas citas "ostas" (skatīt pilnu sarakstu). Google ir izveidojis un turpina uzturēt savu Chromium portu. Ir arī WebKitGtk, kas balstīts uz Gtk +. Nokia (un tagad Trolltech, kas to iegādājās) uztur WebKit Qt portu, kas ir kļuvis populārs kā QtWebKit modulis.

Dažas WebKit porti

  • Safari
    - Safari operētājsistēmā OS X un Safari operētājsistēmā Windows divas dažādas ostas
    - WebKit Nightly Build ir Mac "porta" avota koda apkopojums, ko izmanto tikai Safari.
  • Mobilais Safari
    - Izstrādāts privātā filiālē, bet vēlāk tika atvērts.
    - Chrome operētājsistēmai iOS (izmanto Apple WebView; nedaudz vēlāk par atšķirību)
  • Chrome (hroms)
    - Chrome Android ierīcēm (tieši izmanto Chromium "portu")
    - Hroms ir arī pamats pārlūkprogrammām: Yandex ,, Sogou un drīz Opera.
  • Android pārlūks
    - Izmanto jaunāko WebKit avota kodu, kas pieejams izlaišanas laikā.
  • Vēl vairāk portu: Amazon Silk, Dolphin, Blackberry, QtWebKit, WebKitGTK +, EFL ports (Tizen), wxWebKit, WebKitWinCE utt.
Dažādas ostas var koncentrēties uz dažādiem uzdevumiem. Mac porta uzmanības centrā ir pārlūka un operētājsistēmas nošķiršana un Obj-C un C ++ saistījumu nodrošināšana renderēšanas motora iegulšanai vietējās lietojumprogrammās. Chromium porta uzmanība pilnībā tiek pievērsta pārlūkprogrammai. QtWebKit piedāvā savu portu izmantot kopā ar starpplatformu lietojumprogrammu arhitektūru kā renderēšanas motoru.

Kas ir kopīgs visās WebKit pārlūkprogrammās

Vispirms apskatīsim kopīgās funkcijas, kas tiek izmantotas visās WebKit pārlūkprogrammās:

Jūs zināt, ka tas ir smieklīgi, es vairākkārt mēģināju uzrakstīt šo rindkopu. Un katru reizi, kad Chrome komandas locekļi mani laboja, kā redzēsiet ...

  1. Tātad, pirmkārt, WebKit parsē HTML tāpat. Nu, izņemot to, ka Chromium ir vienīgais ports, kurā pašlaik ir iespējots HTML parsēšanas straumēšanas atbalsts.
  2. ... Labi, bet pēc HTML parsēšanas DOM koks tiek veidots tāpat. Nu, faktiski Shadow DOM ir iespējots tikai Chromium pieslēgvietai, tāpēc DOM konstrukcija atšķiras. Arī pielāgotajiem elementiem.
  3. ... Labi, WebKit izveido logu un dokumentu objektus visiem vienādi. Tiesa, lai arī to piedāvātās īpašības un konstrukcijas var būt atkarīgas no iezīmju karodziņu izmantošanas.
  4. ... CSS parsēšana ir vienāda. Ēst CSS un pārveidot to CSSOM ir diezgan standarta. Jā, kaut arī pārlūks Chrome atbalsta tikai prefiksus -webkit-, savukārt Apple un citas pārlūkprogrammas atbalsta novecojušos prefiksus -khtml- un -apple.
  5. ... Izkārtojums ... pozicionēšana? Tas ir kā maize un sviests. Tas ir vienādi visur, vai ne? Nu jau! Apakšpikseļu izkārtojums un bagātīga izkārtojuma aritmētika ir WebKit sastāvdaļa, taču katrā ostā tā atšķiras.
  6. Super.

Tāpēc tas ir grūti.

Tagad mēģināsim apkopot WebKit pasaulē izplatīto ...

Kas ir kopīgs katrai WebKit ostai.

  • DOM, logs, dokuments
    vairāk vai mazāk
  • CSSOM
  • Parsējot CSS rekvizītu / vērtību
    ražotāja prefiksu atšķirības
  • Parsējot HTML un izveidojot DOM
    Tas pats, ja aizmirstam par tīmekļa komponentiem.
  • Izkārtojums un pozicionēšana
    Flexbox, Floats, bloka formēšanas konteksts ... viss kopīgais
  • Lietotāja saskarnes rīki un izstrādātāju rīki, piemēram, Chrome DevTools jeb WebKit inspector.
    Lai gan kopš pagājušā gada aprīļa Safari izmanto savu Safari inspektoru, kas nav WebKit, ir slēgts avots.
  • Tādas funkcijas kā contenteditable, pushState, File API, lielākā daļa SVG, CSS transformācijas matemātika, Web Audio API, localStorage
    Tomēr ieviešana var atšķirties. Katrs ports var izmantot savu krātuvi vietnei LocalStorage un Web Audio API var izmantot citu audio API.
Tas kļūst mazliet mulsinoši, tāpēc mēģināsim aplūkot dažas atšķirības.

Kas nav izplatīts WebKit portiem:

  • Viss, kas saistīts ar GPU
    - 3D transformācijas
    - WebGL
    - Video dekodēšana
  • 2D vilkšana uz ekrāna
    - Anti-aliasing tehnoloģijas
    - SVG un CSS gradientu renderēšana
  • Teksta renderēšana un defise
  • Tīkla tehnoloģijas (SPDY, pirmrenderēšana, WebSocket transports)
  • JavaScript dzinējs
    - JavaScriptCore dzinējs atrodas WebKit repozitorijā. Bet WebKit ir saites gan tai, gan V8.
  • Formas elementu renderēšana
  • Video un audio tagu uzvedība un kodeku atbalsts
  • Attēlu dekodēšana
  • Navigācija atpakaļ / uz priekšu
    - pushState () daļa
  • SSL funkcijas, piemēram, stingra transporta drošība un publiskās atslēgas piespraudes
Apskatīsim vienu no tiem: 2D grafika atkarīgs no porta, renderēšanai uz ekrāna mēs izmantojam pilnīgi citas bibliotēkas:

Vai arī, lai iedziļinātos sīkāk, nesen pievienotā funkcija: CSS.supports () ir iespējots visām ostām, izņemot Win un Wincairo, kurās nav iespējotas nosacītās CSS3 funkcijas.

Tagad mēs iedziļināmies tehniskajās detaļās ... laiks kļūt pedantiskam. Pat iepriekšminētais nav pilnīgi pareizs. Patiesībā tas ir WebCore, tas ir kopīgs komponents. WebCore ir izkārtojums, renderēšana un DOM bibliotēka HTML un SVG, un būtībā to domā cilvēki, sakot WebKit. Patiešām, "WebKit" tehniski ir saistījumu slānis starp WebCore un "portiem", lai gan parastās sarunās šī atšķirība lielākoties nav būtiska.

Diagrammai vajadzētu palīdzēt:

Daudzi WebKit komponenti ir pārslēdzami (parādīti pelēkā krāsā).

Piemēram, WebKit JavaScript dzinējs JavaScriptCore ir WebKit noklusējuma dzinējs. Sākotnēji tā pamatā ir KJS (no KDE) kopš tiem laikiem, kad WebKit sāka darboties kā KHTML dakša. Tajā pašā laikā Chromium ports tiek pārslēgts uz V8 motoru un tiek izmantots unikāls DOM stiprinājums.

Fonti un teksta renderēšana ir ļoti liela platformas daļa. WebKit tekstam ir 2 atsevišķi ceļi: ātra un cieta. Abiem ir nepieciešams platformas specifisks atbalsts (ieviests ostas pusē), taču Fast ir jāzina tikai tas, kā izlaist glifus (kurus WebKit kešatmiņā platformai), kad sarežģītais pilnībā virza virkņu atveidošanu platformas līmenī un vienkārši saka, ka uzzīmējiet to, lūdzu.

“WebKit ir kā sviestmaize. Pretējā gadījumā hroma gadījumā tas ir vairāk kā tako. Garšīgi tako no tīmekļa tehnoloģijām.
Dmitrijs Glazkovs, Chrome WebKit hakeris. Tīmekļa komponentu čempions un ēnu dom.

Tagad paplašināsim mūsu pārskatu, lai apskatītu dažas ostas un dažas apakšsistēmas. Zemāk ir redzamas piecas WebKit porti. Ņemiet vērā, kā katram no tiem atšķiras rīku kopa, neskatoties uz kopīgajiem komponentiem:

Chrome (OS X) Safari (OS X) QtWebKit Android pārlūks Chrome operētājsistēmai iOS
Atveidošana Skia CoreGraphics QtGui Android kaudze / Skia CoreGraphics
Tīklošana Hroma tīkla kaudze CFTīkls QtNetwork Hroma tīkla kaudzes dakša Hroma kaudze
Fonti CoreText caur Skia CoreText Qt iekšējie Android kaudze CoreText
JavaScript V8 JavaScriptCore AS (V8 lieto citur Qt) V8 JavaScriptCore (bez JITting) *

* Zemsvītras piezīme par pārlūku Chrome IOS. Tas, kā jūs droši vien zināt, izmanto UIWebView. Saskaņā ar UIWebView iespējām tas nozīmē, ka tas var izmantot tikai to pašu renderēšanas dzinēju kā Mobile Safari, JavaScriptCore (nevis V8) un vienu vītņotu modeli. Tomēr daži kodi ir aizgūti no Chromium, piemēram, tīklošana, grāmatzīmju infrastruktūras sinhronizācija, universālais lodziņš, metrika un avāriju pārskati. (Arī JavaScript ir tik reti mobilā tālruņa sastrēgums, ka JITting kompilatora trūkumam ir minimāla ietekme.)

Labi, tad kur mēs nonācām?

Un tagad viss WebKit ir pilnīgi atšķirīgs. Esmu nobijies.

Nav tā vērts! WebKit's layoutTest pārklājums ir milzīgs. (28 000 testi beidzot skaitīti), un ne tikai attiecībā uz esošajām funkcijām, bet arī uz visām atrastajām regresijām. Faktiski ikreiz, kad uzzināt jaunas vai “slepenas” DOM / CSS / HTML-5 funkcijas, testa “suiteTest” komplektiem parasti ir lieliska minimāla demonstrācija.

Turklāt W3C cenšas standartizēt testu komplektu. Tas nozīmē, ka mēs varam sagaidīt, ka gan WebKit porti, gan visas citas pārlūkprogrammas tiks pārbaudītas ar vienu un to pašu testu komplektu, kas ļaus mums samazināt dīvainības un savietojamāku tīmekli. Visiem tiem, kas pielika pūles, lai apmeklētu Test The Web Forward pasākumu ... paldies!

Opera tikko pārcēlās uz WebKit. Kas no tā sanāks?

Roberts Nimans un Robs Hokess jau ir skāruši šo tēmu, taču es piebildīšu, ka viena no nozīmīgajām paziņojuma daļām bija tā, ka Opera pāriet uz Chromium... Tas nozīmē WebGL, Canvas, HTML5 veidlapas, 2D grafikas ieviešanu, visas šīs lietas tagad Chrome un Opera būs vienādas. Tā pati API un zema līmeņa ieviešana. Tā kā Opera pamatā ir Chromium, jūs varat justies kā samazināt savu darbu, pārbaudot saderību Opera un Chrome.
Man arī tas būtu jāatzīmē visi Opera pārlūkprogrammas tiks tulkotas pārlūkā Chromium. Tas ir, Opera operētājsistēmām Windows, Mac, Linux un Opera Mobile (pilnvērtīgs mobilais pārlūks). Pat mazais klients Opera Mini tiks pārslēgts no pašreizējās Presto bāzes renderēšanas fermas uz citu Chromium bāzes.

... un iknedēļas WebKit veidošana. Kas tas ir?

Tas ir WebKit, kas darbojas ar to pašu kodu kā Safari (lai gan dažas iekšējās bibliotēkas ir modificētas). Pārsvarā Apple to vada, tāpēc uzvedība un funkciju kopa atbilst tam, ko atradīsit pārlūkprogrammā Safari. Daudzos gadījumos Apple ir konservatīva attiecībā uz tādu funkciju iespējošanu, kuras citas ostas ievieš vai eksperimentē. Jebkurā gadījumā, lai izmantotu analoģijas, domājiet, ka ... WebKit iknedēļas veidošana Safari ir kā Chromium pārlūkam Chrome. Pievienojiet tagus

Android un iPhone - pārlūkprogrammu kari

1. daļa. WebKit steidz palīgā

Pārlūka lietojumprogrammas izstrāde, kas atbild par tīkla statusa uzraudzību

Satura sērija:

Kopumā iPhone un Android platformās ir pieejami vairāk nekā 100 000 lietojumprogrammu, kuras var lejupielādēt no dažādiem avotiem. Tas attiecas uz "vietējām" lietojumprogrammām, ti. lietojumprogrammas, kuras tiek izstrādātas un izveidotas, izmantojot atbilstošo SDK, un pēc tam instalētas mobilajā ierīcē. Šādas “vietējās” lietojumprogrammas ļauj efektīvi īstenot mobilās ierīces tehniskās iespējas, tostarp atbalstu bezvadu tīkliem, Bluetooth un datu glabāšanu, akselerometra vai kompasa funkcijas, kā arī citus tehnoloģiskus brīnumus un jauninājumus, kas mobilās ierīces padara tik pievilcīgas lietotājiem. "Vietējo" lietojumprogrammu popularitāte iPhone un Android platformām ir ārkārtīgi augsta, taču turklāt mobilās ierīces sniedz plašas iespējas tīmekļa lietojumprogrammu izstrādei. Mobilās tehnoloģijas jau sen ir izgājušas no bērnības, un līdz ar tām mobilais internets ir sasniedzis noteiktu briedumu.

Šis raksts ir pirmais divu daļu sērijā par pārlūka lietotņu izstrādi iPhone un Android platformām. Šīs sērijas mērķis ir iepazīstināt lasītāju ar saviem mobilo tīmekļa lietojumprogrammu veidošanas pamatprincipiem. Mobilo lietojumprogrammu iespējas neaprobežojas tikai ar vietnes pārvaldīšanu mobilajā ierīcē. Mēs apsvērsim mobilo lietojumprogrammu izstrādē izmantotās pamattehnoloģijas un pieejas, kas ļauj šo programmatūras izstrādes sadaļu izdalīt atsevišķā neatkarīgā disciplīnā.

Tīmekļa platformas popularitāte ir saistīta ar faktu, ka tās izmantošana ļauj atrisināt daudzas problēmas, kuras tradicionāli piemeklē izstrādātājus un sistēmu administratorus. Starp viņiem:

  • Instalācijas problēmas: Web lietojumprogrammu instalēšana ir vienkārša - vienkārši instalējiet vai nokopējiet tās serverī un pastāstiet klientiem, kuru URL norādīt pārlūkprogrammā.
  • Problēmas ar mērogošanu: tīmekļa lietojumprogrammas viegli mērogojas uz serveru kopu augstas veiktspējas datu centrā un lietojumprogrammu apkalpošanai izmanto vietņu pārvaldības rīkus.
  • Datu arhivēšanas un atkopšanas izaicinājumi: Tīmekļa lietojumprogrammas izmanto centralizētu datu krātuvi, tādējādi vienkāršojot katastrofu atkopšanas uzdevumu.
  • Lietotāja saskarnes apsvērumi: HTML, kaskādes stila lapu (CSS), JavaScript un grafikas kombinācija ļauj izveidot bagātīgu lietotāja saskarni, kas pēc funkcionalitātes un izskata ir ievērojami pārāka par saskarnēm, kas izstrādātas ar vietējo SDK. Pēdējie parasti nespēj nodrošināt spēļu lietojumprogrammām pilnvērtīgu klātbūtnes efektu un negarantē interaktīvo informācijas termināļu nepieciešamo funkcionalitāti.
  • Lietošanas ērtums: Lai ikdienas darbība būtu vienkārša, lielākajai daļai lietojumprogrammu nepieciešami vienkārši un viegli lietojami lietotāja interfeisa elementi.

Interneta lietojumprogrammu izplatīšanas modeļa vispievilcīgākais aspekts ir tas, ka tā programmatūru pārvērš par sava veida abonēšanas pakalpojumu, kas ir abpusēji izdevīgs programmatūras piegādes veids. - Kā? - tu jautā. Apskatīsim šo jautājumu tuvāk.

Tīmekļa programmatūras izplatīšanas modelis ļauj klientiem pirms iegādes izmēģināt produktu ar minimālu risku un minimālām izmaksām. Ja klientam patika izmēģinājuma versija, tad viss, kas no viņa tiek prasīts turpmākai programmatūras produkta izmantošanai, ir norēķināties par pirkumu ar kredītkarti (vai izmantojot PayPal sistēmu). Turklāt programmatūras kā pakalpojuma (SaaS) modelis lietotājiem nodrošina ērtu un izdevīgu programmatūras iegādes veidu bez ievērojamām sākotnējām izmaksām, garantējot ieguldījumu atdevi pirmajā lietošanas mēnesī, nevis tālākā nākotnē.

Fakts ir tāds, ka mobilajām ierīcēm tīmekļa pārlūkiem praktiski nebija atbalsta. Situācija krasi mainījās, parādoties tehnoloģijai, ko sauc par WebKit, kas, pateicoties iPhone, pārliecinoši ir ieņēmusi vietu mobilo ierīču jomā.

Tikai dažu gadu laikā iPhone platforma ir kļuvusi par pasaules galveno klientu. Kāpēc? Tā kā WebKit kopā ar uzticamu interneta savienojamību ļāva tīmekļa pakalpojumus mobilajās ierīcēs izmantot daudz efektīvāk nekā jebkurā citā modernā pārlūkprogrammā. Arī citi mobilie spēlētāji ir pievērsuši uzmanību jaunajai tehnoloģijai, un tagad visu tirgu var sadalīt uzņēmumos, kas izmanto WebKit, uzņēmumos, kuri gatavojas izmantot WebKit, un uzņēmumos, kas izdomā attaisnojumus WebKit nelietošanai.

Kas tad ir WebKit?

WebKit un HTML5

WebKit ir pārlūka dzinējs, ko izmanto gan mobilā Safari pārlūka atbalstam iPhone platformā, gan pārlūka atbalstam Android platformā. Protams, WebKit tiek izmantots arī citās mobilajās ierīcēs, taču šī raksta vajadzībām mēs aprobežosimies ar iPhone un Android platformu apsvēršanu.

WebKit ir atvērtā pirmkoda projekts, kas radies, izstrādājot K darbvirsmas vidi (KDE). Tieši WebKit projekts ir parādā viņu modernās tīmekļa lietojumprogrammas mobilajām ierīcēm. Mobilās ierīces tehnoloģiskajām un dizaina īpašībām noteikti ir svarīga loma, taču mobilo ierīču lietotājus galvenokārt interesē saturs. Ja mobilā ierīce nodrošina piekļuvi tikai nelielai daļai interneta satura, tad maz ticams, ka tā varēs iekļūt populārāko ierīču top sarakstā.

Lielākā daļa no mums dod priekšroku pilnvērtīgai dzīvei: ja atveram vietni klēpjdatorā, sēžot mājās, mēs sagaidām, ka to pašu saturu redzēsim, apmeklējot šo vietni, atrodoties vilcienā. Saturs ir galvenā mobilo lietotņu problēma. Neatkarīgi no tā, kur mēs atrodamies vai ko darām, mums ir nepieciešama piekļuve mūs interesējošajiem datiem. WebKit tehnoloģija nodrošina bagātīgu saturu iPhone un Android platformās.

Ir vērts atzīmēt, ka WebKit tiek izmantots arī galddatoros, piemēram, pārlūkprogrammā Safari, kas ir galvenais Mac OS X platformas pārlūks. Neatkarīgi no tā, vai tiek apsvērta darbvirsmas versija vai iPhone vai Android pārlūkprogrammas dzinējs, WebKit joprojām ir vismodernākā tehnoloģija. atbalstot HTML un CSS. Patiesībā WebKit atbalsta CSS stilus, kurus citu motoru pārlūkprogrammas vēl nav renderējušas - kā piemēru varat norādīt virkni rekvizītu, kas definēti HTML5 specifikācijā.

HTML5 ir provizorisku tehnisko specifikāciju kopums, kas definē pārlūkprogrammā balstītas tehnoloģijas, piemēram, klienta puses datu glabāšanu ar SQL atbalstu, navigāciju, pārveidošanu utt. HTML5 specifikācija vēl nav pilnīga, taču, tiklīdz pamatprincipi ir skaidri formulēti un ieviesti pārlūkprogrammās lielākajā daļā platformu, tīmekļa lietojumprogrammu pazemīgais sākums būs aizmirsts pagātne. Tīmekļa lietojumprogrammu izstrāde aizņems nozīmīgu programmatūras izstrādes segmentu, un tas attiecas ne tikai uz lietojumprogrammām darbvirsmas, bet arī mobilajām pārlūkprogrammām. No blakusprodukta mobilās lietotnes kļūs par galveno preci tīmekļa lietojumprogrammu tirgū.

Mobilās tīmekļa lietojumprogrammu izstrādes dizaina iezīmes

Kad esat pieņēmis lēmumu apgūt tīmekļa izstrādes tehnoloģijas, jūsu rīcībā ir ļoti maz rīku. Pirmkārt, lietojumprogrammu var izveidot tieši serverī kā failu, kas satur HTML, CSS un JavaScript kodu. Tajā pašā laikā HTML saturu var piegādāt kā statiskus HTML failus, vai arī to var ģenerēt dinamiski, izmantojot dažādas tehnoloģijas, kas darbojas servera pusē, piemēram, piemēram, PHP, ASP.NET, Java Servlet utt. Jebkurā gadījumā no punkta No šajā rakstā aplūkoto jautājumu viedokļa viss ir saistīts ar HTML kodu, un šeit mums vissvarīgākais ir tas, ka WebKit tehnoloģija ļauj pārlūkprogrammām renderēt HTML mobilajās ierīcēs.

Lai palaistu tīmekļa lietojumprogrammu mobilajā ierīcē (iPhone vai Android), lietotājam ir jāpalaiž pārlūkprogramma un jāievada attiecīgā pakalpojuma URL, piemēram: http://jūsuuzņēmuma nosaukums.com/applicationurl.

Tajā pašā laikā piedāvāto mobilo tīmekļa lietojumprogrammu klāsts ir diezgan plašs: sākot no standarta tīmekļa vietnes līdz mobilajai tīmekļa lietojumprogrammai, kas paredzēta tieši konkrētai mobilajai platformai.

Parāda standarta vietnes

WebKit dzinējs apvienojumā ar intuitīvo un lietotājam draudzīgo iPhone un Android platformu interfeisu ļauj jums gandrīz jebkurā mobilajā ierīcē skatīt vietni. Tīmekļa lapas tiek rādītas diezgan pareizi, atšķirībā no iepriekšējās paaudzes mobilajām pārlūkprogrammām, kas patvaļīgi transportēja satura gabalus vai tos vispār neparādīja. Kad lapas tiek ielādētas pārlūkprogrammā, kurā iespējots WebKit, lapas saturam ir tendence palielināties. Tajā pašā laikā mērogs tiek izvēlēts tā, lai visa lapa ietilptu ekrānā, kaut arī ievērojami samazinātā, bieži vien nelasāmā formā, kā parādīts 1. attēlā. Tomēr lapu var ritināt, palielināt, pārvietot, nodrošinot ērtu piekļuvi visiem satura elementiem ... Pēc noklusējuma pārlūkprogramma izmanto 980 pikseļu lielu logu.

Kaut arī Web lapas pilnīga parādīšana pārlūkprogrammas logā pati par sevi ir būtisks uzlabojums salīdzinājumā ar iepriekšējās paaudzes pārlūkprogrammu izmantošanas pieredzi, mūsdienu mobilo tehnoloģiju iespējas ar to neaprobežojas.

Tīmekļa lapas, kas paredzētas mobilajām ierīcēm

Ja vēlaties, lai jūsu vietne būtu pieejama mobilajiem lietotājiem, kā arī vispārējiem tīmekļa lietotājiem, mobilajām tīmekļa lietojumprogrammām ir jāapsver vairākas citas optimizācijas iespējas.

Lai gan WebKit var pareizi parādīt tīmekļa lapu mobilās ierīces ekrānā, pastāv atšķirība starp ierīcēm, kas izmanto peli, piemēram, klēpjdatoriem vai galddatoriem, un skārienjutīgām ierīcēm, piemēram, iPhone vai Android viedtālruņiem. Skārienierīces atšķiras ar fizisko "klikšķa" apgabala lielumu, kursora novietošanas virs jebkura elementa funkcijas neesamību un citu notikumu secību. Tādējādi, ja vēlaties izveidot vietni, kas ir ērta gan vispārējiem, gan mobilajiem lietotājiem, jums jāņem vērā šādas mobilo ierīču funkcijas:

  • IPhone un Android pārlūkprogrammas spēj parādīt visu tīmekļa lapu diezgan lasāmā formā - šo pārlūkprogrammu displeja kvalitāte ir daudz augstāka nekā standarta mobilajām pārlūkprogrammām - tāpēc nesteidzieties pārmērīgi vienkāršot vietnes dizainu.
  • Pirkstu galu izmērs ir daudz lielāks nekā peles rādītāja lielums. Izstrādājot vietnes navigācijas elementus, ņemiet vērā šo faktoru. Nenovietojiet saites pārāk tuvu viena otrai, pretējā gadījumā lietotājs nevarēs noklikšķināt uz vienas saites, nesitot blakus esošo.
  • Novietojot kursoru, mobilajās ierīcēs nedarbosies. Lietotājs vienkārši nevar "norādīt" pirkstu virs jebkura elementa tādā pašā veidā kā peles kursors.
  • Notikumi, ko nosaka, nospiežot un turot peles pogu, velkot peli utt., Skārienekrānos tiek realizēti atšķirīgā veidā. Daži no šiem notikumiem varētu darboties mobilajās ierīcēs, taču kopumā nevajadzētu gaidīt, ka mobilais pārlūks un darbvirsmas pārlūks veiks vienu un to pašu darbību secību.

Detalizētu šo aspektu diskusiju varat atrast rakstā “ iPhone darbībā"(Skatīt sadaļu). Šajā rakstā mēs aprobežosimies ar WebKit priekšrocību, nevis tās trūkumu apsvēršanu.

Apskatīsim acīmredzamāko problēmu, ar kuru saskaras iPhone vai Android lietotāji, piekļūstot vietnēm, ierobežotais ekrāna izmērs. Faktiski mūsdienu mobilās ierīces ekrāns ir 320x480 vai 480x320, ar nosacījumu, ka lietotājs dod priekšroku tīmekļa satura apskatīšanai ainavas konfigurācijā. Kā redzat 1. attēlā, WebKit spēj pareizi parādīt Web lapu, kas paredzēta standarta galddatoriem. Tomēr, kad Web lapa tiek tuvināta, teksts var būt pārāk mazs, lai to lasītu, tāpēc lietotājam pirms teksta lasīšanas būs jā ritina, jāpārvieto un jātuvina. Kā rīkoties ar šo ierobežojumu?

Vienkāršākais veids, kā izveidot lapu, kas vienlīdz labi parādās mobilās pārlūkprogrammas logā un darbvirsmas pārlūka logā, ir izmantot pielāgotu meta tagu skata logs.

Meta tags ir HTML tags, kas tiek ievietots HTML dokumenta galvā. Vienkāršākais skata porta taga izmantošanas piemērs izskatās šādi: ... Pievienojot šo metatagu HTML lapai, tā parādīšana mobilās pārlūkprogrammas logā tiek optimizēta visoptimālākajā veidā (sk. 2. attēlu). Pārlūkprogrammas, kas neatbalsta skatījumu, vienkārši ignorē šo tagu.

Dažos gadījumos ir lietderīgi iepriekš noteikt loga mērogošanas parametrus, kā parādīts 3. attēlā.

Lai definētu konkrētas mērogošanas opcijas, norādiet precīzu skata metataga satura atribūta vērtību: ... Mainot sākotnējā mēroga parametra vērtību, attēlu var samazināt vai palielināt. IPhone un Android platformās labāk izmantot vērtības no 1,0 līdz 1,3. Skatsporta metatags atbalsta arī minimālo un maksimālo mērogošanu, kas ierobežo lietotāja iespējas mērogot lapu, kamēr tā tiek ielādēta.

Kaut arī iPhone dizaina raksturlielumi, it īpaši 320x480 ekrāna izmēri, kopš tā pirmsākumiem ir palikuši praktiski nemainīgi, Android platformas ierīču parametriem ir diezgan plašs diapazons, jo mobilās ierīces šajā platformā ražo dažādi ražotāji un tās ir paredzētas visdažādākajām lietotāju grupām. Tāpēc, ja vēlaties, lai jūsu tīmekļa lietojumprogramma būtu populāra mobilo ierīču lietotāju vidū, jums jāapsver iespējamās atšķirības Android ierīču ekrāna izmēros, izšķirtspējā un dizaina funkcijās.

Pieredze rāda, ka papildus dažādu Android mobilo ierīču dizaina atšķirībām pati Android programmatūra mēģina pielāgot ielādētās Web lapas iestatījumus, pamatojoties uz mobilās ierīces pārlūka īpašībām. Papildus stabilitātei Android platformā ir arvien mainīgs funkciju un iespēju kopums. Konkrētas Android ierīces iestatījumi, visticamāk, atšķirsies no iestatījumiem jūsu izstrādes vidē atkarībā no SDK versijas un ierīces ražotāja. 4. attēlā parādīts pārlūka konfigurācijas ekrāns Android Emulator V1.6. Ekrāna iestatījumi nodrošina lietotājam iespēju noteikt ekrāna attēla tuvināšanas līmeni (tālu, tuvu, vidēju) vai izvēlēties automātisko lapas mērogošanas režīmu.

Mobilo ierīču pasaulē izmaiņas ir visnoturīgākās, tāpēc jāņem vērā mobilās programmatūras tirgus attīstība un atjaunošana. Piemēram, Sprint Hero pārlūka iestatījumos ir iekļauts opciju komplekts, kas pilnīgi atšķiras no noklusējuma iestatījumiem, ko izmanto, ielādējot Web lapu. Hero pārlūks ir veidots uz Android V1.5 platformas, izmantojot vairākas HTC veiktās modifikācijas. Par laimi, lietojot skata meta tagu, varonim raksturīgie iestatījumi tiks ignorēti.

Līdz šim mēs esam redzējuši, ka WebKit diezgan labi var tikt galā ar Web lapas ielādi, kaut arī ievērojami samazinātā un grūti lasāmā formā. Pēc tam mēs paplašinājām kontroli pār to, kā lapa tiek parādīta mobilajā ekrānā, izmantojot skata porta metatagu. Tagad atveidoto lapu ir daudz vieglāk lasīt un pārvietoties. Bet ar to joprojām nepietiek, lai mūsu lapa izskatās un darbojas kā tīmekļa lietojumprogramma.

Izgatavots mobilajām ierīcēm

Pāriesim pie Web lapas dizaina iezīmēm mobilajai auditorijai. Kā konkrētu piemēru apsveriet Google e-pasta reģistrācijas lapu GMail.

Šādi šī lapa izskatās darbvirsmas pārlūka logā:


Darbvirsmas pārlūka logā kreisajā pusē ir redzams informatīvs saturs, un pats reģistrācijas logs atrodas labajā rūtī. Mobilās pārlūkprogrammas logā tai pašai lapai ir pilnīgi atšķirīgs izskats.

Lapa, kas parādīta 6. attēlā, noteikti ir paredzēta mobilo sakaru lietotājiem. Ekrānā tiek parādīti tikai tie lapas elementi, kas ir nepieciešami lietotājam turpmākam darbam - nav nepieciešama papildu ritināšana, pārvietošana vai mērogošana.

Tagad apskatīsim Gmail mobilās versijas e-pasta skatītāju. Tā kā lietojumprogrammai pieejamais ekrāna laukums ir ļoti ierobežots, ziņojumu skatītājam ir papildu pogas un navigācijas elementi. Šajā gadījumā parādītie navigācijas elementi pārklājas ar ziņojumu skatīšanas logu. Nelietojiet arī pārāk daudz kadru vai ritināšanu divs, ja jūs varat no tā izvairīties. Gmail mobilā versija atrisina šo problēmu, izmantojot uznirstošo izvēlni, kas parādās, tiklīdz lietotājs pabeidz lapas ritināšanu. Uznirstošajā izvēlnē ir 3 pogas: Arhīvs, Dzēst un Vairāk... Nospiežot pogu Vairāk parādās papildu izvēlnes vienumi (sk. 7. attēlu).

Šī ir patiesi mobilajām ierīcēm paredzēta lietojumprogramma.

Jāpatur prātā, ka mēs nevēlamies apzināti noplicināt dizainu un samazināt to mobilo lietotāju pieredzi, kuri ir izstrādājuši daudzfunkcionālus pārlūkus iPhone un Android platformām. No šī viedokļa ir noderīgi pamanīt elementu, kas tiek parādīts Gmail lapas apakšā (sk. 8. attēlu):

Ja lietotājs dod priekšroku darbvirsmas versijas paplašinātajai funkcionalitātei, nodrošiniet iespēju lejupielādēt atbilstošo lapas versiju.

Tagad apsveriet gadījumu, kad vēlaties izveidot lietojumprogrammu, kas izmanto Web tehnoloģijas, bet izskatās kā vietēja mobilā lietojumprogramma.

Īpašs platformas saturs

Nākamais solis ir satura izstrāde, kas raksturīga konkrētai mobilajai platformai. Tas definē lapas formātu un saskarni tā, lai iegūtā lapa izskatās pēc vietējās platformas lietojumprogrammas, nevis kā standarta publiskā vietne. Ko mēs domājam ar "dzimto" lietojumprogrammu?

Pirms ienirt diskusijā par to, kā Web lietojumprogrammu padarīt pēc iespējas līdzīgāku konkrētās platformas vietējai lietojumprogrammai, atstāsim malā iPhone un Android pārlūku vispārīgās īpašības un īsi pārrunāsim šo platformu vizuālās atšķirības.

IPhone lietojumprogrammām ir savs īpašs izskats un interfeiss. Parādiet kādam iPhone ekrānuzņēmumu un, ja vien šī persona otro dienu burtiski nenokrita no mēness, viņš gandrīz noteikti nekavējoties sacīs, ka tas ir iPhone. Parādiet tai pašai personai Android mobilās ierīces ekrānuzņēmumu, un atbilde nebūs tik skaidra. Kāds ir iemesls? Ir vairāki iespējamie izskaidrojumi. Pirmkārt, iPhone parādījās tirgū daudz agrāk nekā Android ierīces un izdevās iegūt milzīgu skaitu fanu. Padomājiet par cilvēkiem, kas rindā maksā, lai samaksātu lielus dolārus par ierobežotajām V1 iPhone iespējām. Neatkarīgi no tā, vai jums patīk iPhone vai nē, šis Apple produkts šobrīd ir tirgus līderis. Kā ir ar Android?

Android platforma ir salīdzinoši jauns produkts, un daudzējādā ziņā tas darbojas kā antipods iPhone, jo tas galvenokārt ir paredzēts atvērtai sabiedrībai. Android platformu izmanto ļoti dažādās ierīcēs (tālruņos un citās sadzīves tehnikās). Diskusijas atvieglošanai šajā rakstā mēs aprobežosimies ar Android izmantošanu mobilajos tālruņos.

Laika gaitā Android ierīču skaits pasaulē pārsniegs iPhone skaitu. Tas ir tāpēc, ka Android ierīces ražo dažādi uzņēmumi, un tās atbalstīs visdažādākie datu tīkli. Ar tik ievērojamu spēlētāju skaitu Android mobilo ierīču tirgū nav šaubu, ka, ņemot vērā ierīču izskatu un parametrus, ir sagaidāma zināma tirgus sadrumstalotība. Šī tendence ir redzama HTC SenseUI. Šo pievilcīgo izskatu un izjūtu neatbalsta pamata Android SDK, un tas nav saderīgs ar citām Android ierīcēm. Motorola, Google un Verizon ir apvienojuši spēkus, lai izstrādātu jaunu Android balstītu DROID ierīci. Šis ir pirmais komerciālais produkts Android 2.0 platformā.

Salīdziniet Android sistēmu daudzveidību ar vienotu iPhone izskatu. IPhone ir īpaši vērtīgs Apple īpašums. Laika gaitā iPhone lietojumprogrammu izskats var nedaudz mainīties, taču maz ticams, ka šīs nelielās izmaiņas tiks salīdzinātas ar dažādajām Android sistēmu versijām, kuru skaits ir diezgan liels pat tagad, kad platforma ir ļoti agrīnā stadijā.

Tātad, kas jādara, lai lietojumprogrammas izskats un saskarne būtu pēc iespējas tuvāka "vietējām" programmām?

Ja tas būtu izaicinājums pirms Web 2.0, tā būtu patiešām liela problēma. Agrīnie mēģinājumi atbalstīt vairākas klientu pārlūkprogrammas (mobilās un darbvirsmas) balstījās uz vairākām pieejām, piemēram:

  • Pilnīgi paralēlu vietu attīstība
  • Dinamiskā satura ģenerēšana atkarībā no parametra userAgent
  • Starpniekserveru izmantošana, kas varētu pārveidot saturu atkarībā no katras konkrētās ierīces. Šo tehnoloģiju RIM ir veiksmīgi izmantojusi, lai nodrošinātu piekļuvi e-pastam no klienta mobilās ierīces.

Šādas pieejas var būt diezgan pieņemamas gadījumos, kad izstrādi veic lielas, labi finansētas komandas. Un kā ir ar pārējo pasauli? Ne visiem ir ievērojami finanšu resursi, augsti kvalificēti speciālisti un neierobežots laiks šādu stratēģiju īstenošanai. Turklāt, kā mēs jau esam atzīmējuši, iepriekšējās paaudzes pārlūku mobilo internetu nevar saukt par ērtu vai populāru lietošanai, tāpēc jebkurā gadījumā nepakavēieties pie novecojušām metodēm un pieejām.

Par laimi mums tas nav jādara. WebKit un CSS laikmetā dažādu mobilo ierīču izskata un izjūtu atšķirības var mazināt, izmantojot stila lapas un multivides vaicājumus, lai atkarībā no konkrētā ierīces veida būtu pieejami dažādi stili. Multivides vaicājumu tehnoloģija ļauj iegūt informāciju par klientu. Tradicionāli pārlūks serverim nosūta vērtību userAgent, kas ļauj serverim identificēt konkrētu pārlūkprogrammu un noteikt klientam piegādājamo saturu. Izmantojot multivides vaicājumu, pārlūks izvēlas lapas stilu, pamatojoties uz savām iespējām. Šis piemērs parāda viedtālruņu stila lapas izvēli: ... Un šis vaicājums nosaka stila lapu darbvirsmām: .

Internet Explorer V6

Rakstīšanas laikā Internet Explorer V6 bija aptuveni 20–30% no kopējā pārlūkprogrammu tirgus, taču IE V6 ir ārpus šī raksta darbības jomas.

Detalizētāku informāciju par multivides vaicājumiem varat atrast specifikācijas projektā (skatīt sadaļu).

Apsvērsim piemēru, kā multivides vaicājumus izmantot, lai izstrādātu lietojumprogrammu, kas parāda tīkla serveru stāvokli.

Tīkla uzraudzības programma

Šīs lietojumprogrammas mērķis ir uzraudzīt vairāku serveru darbību. Neatkarīgiem programmatūras piegādātājiem bieži ir jāatbalsta vairākas lietojumprogrammas vairākos serveros. Ja jūs kādu nozīmīgu laiku esat izstrādājis programmatūru, tad, iespējams, jau esat sastapis dažāda veida serverus un dažāda veida lietojumprogrammas. Tas viss nozīmē, ka ir pilnīgi iespējama situācija, kad nevarat izmantot vienu rīku, lai izsekotu visu nepieciešamo lietojumprogrammu darbu. Šajā gadījumā ir jēga izmantot mobilā tīkla uzraudzības lietojumprogrammu (netmon). Lietojumprogramma nodrošina visu nepieciešamo funkcionalitāti, vienlaikus paliekot elastīga un viegli pieejama no mobilās ierīces.

Netmon lietojumprogrammā ir saraksts ar serveriem, kas jāuzrauga. Galvenie veiktspējas rādītāji (KPI) tiek apkopoti katram serverim. KPI ir galvenais instruments, kuru MBA studenti daudzus gadus ir izmantojuši, lai novērtētu biznesa pašreizējo stāvokli. No tīmekļa lietojumprogrammu mitināšanas viedokļa šādus rādītājus var izmantot kā KPI:

  • Darījumu skaits pēdējā laika periodā
    • Pasūtījumi
    • Direktorija pieprasījumi
    • E-pasta ziņojumi
    • Lapas skatījumi
  • Pagājis laiks kopš pēdējā darījuma
    • Pasūtījums
    • Elektroniska datu apmaiņa
    • Biznesa partnera ziņojumi
    • Failu augšupielāde no pārdevēja, izmantojot FTP
  • Vai datu bāze ir pieejama
  • Pēdējās rezerves datums
  • Vidējā pasūtījuma summa (USD)
  • Brīva vieta diskā
  • Joslas platums pēdējai stundai, dienai, mēnesim

Iepriekš minētā metrika un citi līdzīgi darbības parametri ļauj novērtēt konkrētas sistēmas vai lietojumprogrammas stāvokli. Piemēram, svētku laikā mēs pārskatām pasūtījumu skaitu, kas veikti dažās mūsu vietnēs. Ja dati neliecina par stabilu pasūtījumu skaita pieaugumu katru stundu, mēs veicam detalizētāku situācijas analīzi.

Tā kā konkrētai lietojumprogrammai ir nepieciešami savi apstākļi un resursi, netmon jābūt pietiekami elastīgam, lai pielāgotos katra lietojuma specifikai. Lai nodrošinātu šo elastības līmeni, mēs vispirms definējam vispārīgāko datu struktūru, lai pielāgotos katras sistēmas stāvoklim. 2. daļā mēs sīkāk aplūkosim, no kurienes rodas šie dati un kā tie tiek atjaunināti. Pagaidām mēs aprobežosimies ar šādu informāciju:

  • Vietnes nosaukums
  • Vietnes (mājas lapas) URL
  • URL, lai iegūtu atjauninājumus
  • Statuss: Labi vai nē
  • Īsumā: servera stāvokļa apraksts, kas būs vai nu OK, vai arī satur teksta virkni, kas norāda uz nopietnāko servera problēmu
  • Elementi: tas ir vārdu / vērtību pāru kopums, kas mums jāpaziņo par pašreizējās KPI vērtībām attiecīgajā vietnē.

Mūsu lietojumprogramma parādīs iegūtos veiktspējas rādītājus viegli orientējamā veidā, maksimāli izmantojot CSS, jQuery un WebKit iespējas, lai pievērstu lietotāja uzmanību problemātiskajām jomām. Kā jau minējām, šīs programmas izstrādes galvenais mērķis ir spēt to palaist iPhone, Android platformā un galddatorā pārlūkprogrammā Safari.

Tīkla uzraudzības lietojumprogrammu izstrāde

Mūsdienu tīmekļa lapas jāizveido deklaratīvā veidā, kas nosaka lapas organizatorisko struktūru un saturu. Lapas pozicionēšana un formatēšana tiek veikta, izmantojot CSS stila lapas kaskādēs un vairumā gadījumu izmantojot JavaScript. Faktiski JavaScript bibliotēkas ir kļuvušas tik populāras, ka mūsdienās to lietošana ir vairāk noteikums, nevis izņēmums. Šajā rakstā aplūkotajā lietojumprogrammā mēs izmantosim populāro JavaScript bibliotēku jQuery. Mūsu lietojumprogramma darbosies iPhone, Android un darbvirsmā. Tas izmantos to pašu HTML kodu un ieviesīs visas nepieciešamās atšķirības stilu lapās. Šeit jāatzīmē, ka mēs apzināti nepielēmām ievērojamas pūles, lai izveidotu lietojumprogrammai pievilcīgu izskatu. Turklāt fons tika apzināti izvēlēts kā pievilcīgs, savstarpējas harmonijas dēļ, lai pievērstu lasītāja papildu uzmanību stilu izkārtojumam. 2. daļā mēs nedaudz uzlabosim lietojumprogrammas izskatu, taču pašlaik tās HTML izskatās tāds, kāds parādīts 1. sarakstā.

Sarakste 1. Lietojumprogrammas HTML kods
Mani tīkla resursi
Mans lietotāja aģents


Īss ieskats ierosinātajā HTML kodā atklāj šādas galvenās funkcijas:

  • Kodā tiek izmantoti divi ārējie JavaScript faili: viens jQuery bibliotēkas fails un viens palīgfails mūsu lietojumprogrammai.
  • Kods izmanto skata metatagu, lai mērogotu parādīto saturu.
  • Galveno stila lapu nosaka fails netmon.css.
  • Parametru userAgent izmanto, lai definētu palīgstila lapu. Atkarībā no tā vērtības tiks ielādēta stila lapa iPhone, Android vai darbvirsmas pārlūkprogrammai.
  • Lapas ielādes laikā datu parādīšanai tiek izmantota jQuery un palīga funkcija, kas definēta failā netmon.js.
  • Lapas galvenajā kodā tiek izmantoti vairāki div tagi.
  • Visbeidzot, kodā ir saite uz lapu, kurā parādīta virkne userAgent. Šai saitei nav nekāda sakara ar lietojumprogrammu, un tā tiek izmantota tikai demonstrācijas vajadzībām.

Pirms detalizēti izpētīt stila lapas un failu netmon.js, kas faktiski nosaka lietojumprogrammas pamatdarbību, apskatīsim mūsu lietojumprogrammu pašreizējā stāvoklī. Vēlreiz ņemiet vērā, ka mēs izmantojam trīs dažādas stila lapas, pa vienai katrai no trim atbalstītajām platformām. Lai lietojumprogrammas izstrādes process būtu vizuālāks, katra tabula nosaka savu fona krāsu. 9. attēlā mūsu lapa ir atvērta darbvirsmas Safari un tai ir zils fons.

11. attēlā parādīts lietojumprogrammas izskats iPhone pārlūka logā (fona krāsa ir zaļa).

Galvenā failā netmon.js saglabātā stila lapa ir parādīta 2. sarakstā.

Saraksts 2. Galvenā stila lapa
pamatteksts (krāsa: # 888888; font-family: Helvetica; font-size: 14px; margin: 0px; polsterējums: 0;). detalizēta informācija (margin: 0px; polsterējums: 0px; fona krāsa: balta; apmale: cieta; apmale -platums: 1px; -webkit-border-top-left-radius: 8px; -webkit-border-top-right-radius: 8px; -webkit-border-bottom-left-radius: 8px; -webkit-border-bottom -right-rādiuss: 8px;) .OK (krāsa: # 000000;). BAD (krāsa: # ff0000;) .odd (fona attēls: -webkit-gradients (lineārs, kreisais augšējais, labais apakšējais, no (#ccc) ), līdz (# 999));).). pat (fona attēls: -webkit-gradients (lineārs, kreisais augšējais, labais apakšējais, no (# 999) līdz (#ccc));). serveris veiciet (pludiņš: pa labi; krāsa: #ffffff;). serverīti (krāsa: # 000;) # header h1 (piemale: 0; polsterējums: 0; text-align: center; color: # 000;)

Pielāgotas stila lapas izmantošana katrai platformai ļauj veikt šādus uzdevumus:

  1. Mainiet lapas krāsu shēmu. Tas ļauj, pirmkārt, vizuāli parādīt stila lapas lomu, un, otrkārt, parādīt, cik viegli ir izvēlēties vēlamo stila lapu atkarībā no parametra userAgent vērtības.
  2. Iestatiet dažādus fontu lielumus mobilajām un darbvirsmas platformām.
  3. Pārbaudiet atbilstošās WebKit funkcijas. Tas būtu nozīmīgi, ja lietojumprogramma izmantotu pārlūku bez WebKit atbalsta, piemēram, Firefox.

3. sarakstā parādīts faila iphone.css kods.

Saraksts 3. Fails iphone.css
korpuss (fona krāsa: # 00ff00;) .serverentry (-webkit-border-top-left-rādiuss: 8px; -webkit-border-top-top-rādiuss: 8px; -webkit-border-bottom-left-rādius: 8 pikseļi; -webkit-border-bottom-right-rādiuss: 8px;) .name (fonta izmērs: 2em;) .summary (fonta izmērs: 1,5em;) .serverentry a (font size: 1,5em;)

Kā redzam, korpusa birkas fona krāsa ir zaļa (# 00ff00), un fonta lielums tiek pielāgots, lai tā būtu labāk salasāma mobilās ierīces ekrānā. Visbeidzot, apskatīsim failu netmon.js, kas definē serveru sarakstu un funkciju, kas izvada datus par katru serveri (izmantots 4. sarakstā). Īsības labad daļa faila koda ir izlaista, tā pilns teksts ir pieejams sadaļā).

Ieraksts 4. Fails netmon.js
var netmon \u003d (inicializēt: function () (), resursi: [(nosaukums: "msiservices.com", homeurl: "http://msiservices.com", pingurl: "http://msiservices.com/netmon.php ", statuss:" Labi ", kopsavilkums:" Labi ", vienumi: [(nosaukums:" DiskSpace ", vērtība:" 22,13 GB "), (nosaukums:" Datu bāze augšā? ", vērtība:" Jā ")), (nosaukums: "serveris 2", homeurl: "http: // someurl", pingurl: "http: //someurl/netmon.jsp", statuss: "OK", kopsavilkums: "OK", vienumi: [(nosaukums: "DiskSpace", vērtība: "100,8 GB"), (nosaukums: "Datu bāze augšā?", Vērtība: "Jā")])), // papildu ieraksti apgriezti īsuma dēļ], render: function (index, itm) (try ( var ret \u003d "; ret + \u003d"
"; ret + \u003d" "+ itm.name +" Izrāde
"; if (itm.status! \u003d" Labi ") (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"
"; atgriešanās ret;) nozveja (e) (atgriešanās")
Kļūda, atveidojot vienumu ["+ itm.name +"] "+ e +"
"; } } };

Ja kāda servera statusa josla nav pareiza, atbilstošais servera ieraksts tiek parādīts sarkanā krāsā, kā redzams no klases definīcijas CSS failā. Turklāt, ja servera statusa pārbaude atklāja kādas problēmas (statuss nav vienāds ar OK), papildus tiek parādīts īss problēmas apraksts. Attēlos 9-11 varat redzēt, ka 4. serverī nav pietiekami daudz brīvas vietas diskā. Noklikšķinot uz šī servera līnijas, tiks parādīts detalizēts ziņojums par problēmu (sk. 12. attēlu).

Noklikšķinot uz saites šovs pa labi no servera nosaukuma, tiek atvērta servera mājas lapa. Šāda saite ir ļoti ērta divu iemeslu dēļ: pirmkārt, tas ietaupa jums liekas grūtības, kas jāiegaumē katra servera URL, un, otrkārt, tas ietaupa vēl vairāk satraucošo vajadzību ierakstīt šo URL no mobilās tastatūras ( pat ērtākais).

Tātad, ja mēs varam veiksmīgi palaist netmon mobilajā ierīcē, servera atbalsta uzdevumam nevajadzētu radīt problēmas.

Secinājums

Šis raksts iepazīstina ar iPhone un Android tīmekļa lietojumprogrammu izstrādes principiem, izmantojot WebKit tehnoloģiju. 2. daļā mēs paplašināsim mūsu lietojumprogrammas iespējas, pievienojot funkciju datu atjaunināšanai, izmantojot Ajax zvanus.

  • Pārskaitījums

Daudziem no mums izstrādātājiem WebKit - melnā kaste... Mēs tajā iemetam HTML, CSS, JS un ķekaru attēlu, un WebKit kaut kā ... maģiski dod mums tīmekļa lapu, kas izskatās un darbojas labi.
Bet tiešām kā saka mans kolēģis Iļja Grigoriks :

Tīmekļa komplekts nav melnā kaste. Šī ir balta kaste. Un ne tikai balts, bet arī atvērts lodziņā.

Tātad, mēģināsim noskaidrot dažas lietas:
  • Kas ir WebKit?
  • Kas nav WebKit?
  • Kā WebKit izmanto WebKit pārlūkprogrammas?
  • Kāpēc daudzi WebKits nav vienādi?
Tagad, it īpaši pēc ziņām, ka Opera ir pārgājusi uz WebKit, mūs ieskauj daudz WebKit pārlūku, un ir diezgan grūti pateikt, kas viņus vieno un kur viņi iet savu ceļu. Tālāk es ceru, ka mēs centīsimies nedaudz apgaismot šo jautājumu. Tā rezultātā jūs varēsiet labāk noteikt pārlūkprogrammu atšķirības, iesniegt kļūdas pareizajam izsekotājam un efektīvāk attīstīt pārlūkprogrammas.

Standarta tīmekļa pārlūka sastāvdaļas

Uzskaitīsim dažus mūsdienu pārlūkprogrammu komponentus:
  • Parsēšana (HTML, XML, CSS, Javascript parsēšana)
  • Izkārtojums
  • Teksta un grafikas atveidošana
  • Atkodējiet attēlus
  • GPU mijiedarbība
  • Piekļuve tīklam
  • Aparatūras paātrinājums
Kuras no tām ir kopīgas visām WebKit pārlūkprogrammām? Diezgan tikai pirmie divi.

Katru WebKit "portu" pārējos komponentus ievieš savā veidā. Apskatīsim, ko tas nozīmē.

WebKit porti

Ir daudz WebKit "pieslēgvietu", un es piedāvāju Aria Hidayat, WebKit hakeri un citus. Sencha direktoram ir tiesības par to pastāstīt:

Populārākā WebKit asociācija parasti ir Apple sava veida WebKit, kas darbojas uz Mac OS X (pirmā un oriģinālā WebKit bibliotēka). Kā jūs varētu uzminēt, dažādas saskarnes tiek ieviestas, izmantojot dažādas vietējās Mac OS X bibliotēkas, galvenokārt koncentrējoties uz komponentā CoreFoundation Piemēram, ja definējat krāsainu plakanu pogu ar īpašu kontūras rādiusu, WebKit zina, kur un kā šo pogu uzzīmēt, savukārt pogas galīgā atveidošana (kā pikseļi lietotāja monitorā) ietilpst CoreGraphics.

Kā jau minēju iepriekš, izmantotā CoreGraphics ir unikāla katram WebKit portam. Piemēram, pārlūkā Chrome Mac tiek izmantota Skia.

Kādā brīdī WebKit tika pārnests uz dažādām platformām - gan datoriem, gan mobilajām ierīcēm. Šo variantu parasti sauc par “WebKit portu”. Operētājsistēmai Safari Windows Apple arī patstāvīgi "portēja WebKit", lai palaistu operētājsistēmā Windows, izmantojot tās (ierobežotas ieviešanas) CoreFoundation bibliotēku.

... neskatoties uz to, ka Safari operētājsistēmai Windows tagad ir miris.
Bez tam bija arī daudzas citas "ostas" (skatīt pilnu sarakstu). Google ir izveidojis un turpina uzturēt savu Chromium portu. Ir arī WebKitGtk, kas balstīts uz Gtk +. Nokia (un tagad Trolltech, kas to iegādājās) uztur WebKit Qt portu, kas ir kļuvis populārs kā QtWebKit modulis.

Dažas WebKit porti

  • Safari
    - Safari operētājsistēmā OS X un Safari operētājsistēmā Windows divas dažādas ostas
    - WebKit Nightly Build ir Mac "porta" avota koda apkopojums, ko izmanto tikai Safari.
  • Mobilais Safari
    - Izstrādāts privātā filiālē, bet vēlāk tika atvērts.
    - Chrome operētājsistēmai iOS (izmanto Apple WebView; nedaudz vēlāk par atšķirību)
  • Chrome (hroms)
    - Chrome Android ierīcēm (tieši izmanto Chromium "portu")
    - Hroms ir arī pamats pārlūkprogrammām: Yandex ,, Sogou un drīz Opera.
  • Android pārlūks
    - Izmanto jaunāko WebKit avota kodu, kas pieejams izlaišanas laikā.
  • Vēl vairāk portu: Amazon Silk, Dolphin, Blackberry, QtWebKit, WebKitGTK +, EFL ports (Tizen), wxWebKit, WebKitWinCE utt.
Dažādas ostas var koncentrēties uz dažādiem uzdevumiem. Mac porta uzmanības centrā ir pārlūka un operētājsistēmas nošķiršana un Obj-C un C ++ saistījumu nodrošināšana renderēšanas motora iegulšanai vietējās lietojumprogrammās. Chromium porta uzmanība pilnībā tiek pievērsta pārlūkprogrammai. QtWebKit piedāvā savu portu izmantot kopā ar starpplatformu lietojumprogrammu arhitektūru kā renderēšanas motoru.

Kas ir kopīgs visās WebKit pārlūkprogrammās

Vispirms apskatīsim kopīgās funkcijas, kas tiek izmantotas visās WebKit pārlūkprogrammās:

Jūs zināt, ka tas ir smieklīgi, es vairākkārt mēģināju uzrakstīt šo rindkopu. Un katru reizi, kad Chrome komandas locekļi mani laboja, kā redzēsiet ...

  1. Tātad, pirmkārt, WebKit parsē HTML tāpat. Nu, izņemot to, ka Chromium ir vienīgais ports, kurā pašlaik ir iespējots HTML parsēšanas straumēšanas atbalsts.
  2. ... Labi, bet pēc HTML parsēšanas DOM koks tiek veidots tāpat. Nu, faktiski Shadow DOM ir iespējots tikai Chromium pieslēgvietai, tāpēc DOM konstrukcija atšķiras. Arī pielāgotajiem elementiem.
  3. ... Labi, WebKit izveido logu un dokumentu objektus visiem vienādi. Tiesa, lai arī to piedāvātās īpašības un konstrukcijas var būt atkarīgas no iezīmju karodziņu izmantošanas.
  4. ... CSS parsēšana ir vienāda. Ēst CSS un pārveidot to CSSOM ir diezgan standarta. Jā, kaut arī pārlūks Chrome atbalsta tikai prefiksus -webkit-, savukārt Apple un citas pārlūkprogrammas atbalsta novecojušos prefiksus -khtml- un -apple.
  5. ... Izkārtojums ... pozicionēšana? Tas ir kā maize un sviests. Tas ir vienādi visur, vai ne? Nu jau! Apakšpikseļu izkārtojums un bagātīga izkārtojuma aritmētika ir WebKit sastāvdaļa, taču katrā ostā tā atšķiras.
  6. Super.

Tāpēc tas ir grūti.

Tagad mēģināsim apkopot WebKit pasaulē izplatīto ...

Kas ir kopīgs katrai WebKit ostai.

  • DOM, logs, dokuments
    vairāk vai mazāk
  • CSSOM
  • Parsējot CSS rekvizītu / vērtību
    ražotāja prefiksu atšķirības
  • Parsējot HTML un izveidojot DOM
    Tas pats, ja aizmirstam par tīmekļa komponentiem.
  • Izkārtojums un pozicionēšana
    Flexbox, Floats, bloka formēšanas konteksts ... viss kopīgais
  • Lietotāja saskarnes rīki un izstrādātāju rīki, piemēram, Chrome DevTools jeb WebKit inspector.
    Lai gan kopš pagājušā gada aprīļa Safari izmanto savu Safari inspektoru, kas nav WebKit, ir slēgts avots.
  • Tādas funkcijas kā contenteditable, pushState, File API, lielākā daļa SVG, CSS transformācijas matemātika, Web Audio API, localStorage
    Tomēr ieviešana var atšķirties. Katrs ports var izmantot savu krātuvi vietnei LocalStorage un Web Audio API var izmantot citu audio API.
Tas kļūst mazliet mulsinoši, tāpēc mēģināsim aplūkot dažas atšķirības.

Kas nav izplatīts WebKit portiem:

  • Viss, kas saistīts ar GPU
    - 3D transformācijas
    - WebGL
    - Video dekodēšana
  • 2D vilkšana uz ekrāna
    - Anti-aliasing tehnoloģijas
    - SVG un CSS gradientu renderēšana
  • Teksta renderēšana un defise
  • Tīkla tehnoloģijas (SPDY, pirmrenderēšana, WebSocket transports)
  • JavaScript dzinējs
    - JavaScriptCore dzinējs atrodas WebKit repozitorijā. Bet WebKit ir saites gan tai, gan V8.
  • Formas elementu renderēšana
  • Video un audio tagu uzvedība un kodeku atbalsts
  • Attēlu dekodēšana
  • Navigācija atpakaļ / uz priekšu
    - pushState () daļa
  • SSL funkcijas, piemēram, stingra transporta drošība un publiskās atslēgas piespraudes
Apskatīsim vienu no tiem: 2D grafika atkarīgs no porta, renderēšanai uz ekrāna mēs izmantojam pilnīgi citas bibliotēkas:

Vai arī, lai iedziļinātos sīkāk, nesen pievienotā funkcija: CSS.supports () ir iespējots visām ostām, izņemot Win un Wincairo, kurās nav iespējotas nosacītās CSS3 funkcijas.

Tagad mēs iedziļināmies tehniskajās detaļās ... laiks kļūt pedantiskam. Pat iepriekšminētais nav pilnīgi pareizs. Patiesībā tas ir WebCore, tas ir kopīgs komponents. WebCore ir izkārtojums, renderēšana un DOM bibliotēka HTML un SVG, un būtībā to domā cilvēki, sakot WebKit. Patiešām, "WebKit" tehniski ir saistījumu slānis starp WebCore un "portiem", lai gan parastās sarunās šī atšķirība lielākoties nav būtiska.

Diagrammai vajadzētu palīdzēt:

Daudzi WebKit komponenti ir pārslēdzami (parādīti pelēkā krāsā).

Piemēram, WebKit JavaScript dzinējs JavaScriptCore ir WebKit noklusējuma dzinējs. Sākotnēji tā pamatā ir KJS (no KDE) kopš tiem laikiem, kad WebKit sāka darboties kā KHTML dakša. Tajā pašā laikā Chromium ports tiek pārslēgts uz V8 motoru un tiek izmantots unikāls DOM stiprinājums.

Fonti un teksta renderēšana ir ļoti liela platformas daļa. WebKit tekstam ir 2 atsevišķi ceļi: ātra un cieta. Abiem ir nepieciešams platformas specifisks atbalsts (ieviests ostas pusē), taču Fast ir jāzina tikai tas, kā izlaist glifus (kurus WebKit kešatmiņā platformai), kad sarežģītais pilnībā virza virkņu atveidošanu platformas līmenī un vienkārši saka, ka uzzīmējiet to, lūdzu.

“WebKit ir kā sviestmaize. Pretējā gadījumā hroma gadījumā tas ir vairāk kā tako. Garšīgi tako no tīmekļa tehnoloģijām.
Dmitrijs Glazkovs, Chrome WebKit hakeris. Tīmekļa komponentu čempions un ēnu dom.

Tagad paplašināsim mūsu pārskatu, lai apskatītu dažas ostas un dažas apakšsistēmas. Zemāk ir redzamas piecas WebKit porti. Ņemiet vērā, kā katram no tiem atšķiras rīku kopa, neskatoties uz kopīgajiem komponentiem:

Chrome (OS X) Safari (OS X) QtWebKit Android pārlūks Chrome operētājsistēmai iOS
Atveidošana Skia CoreGraphics QtGui Android kaudze / Skia CoreGraphics
Tīklošana Hroma tīkla kaudze CFTīkls QtNetwork Hroma tīkla kaudzes dakša Hroma kaudze
Fonti CoreText caur Skia CoreText Qt iekšējie Android kaudze CoreText
JavaScript V8 JavaScriptCore AS (V8 lieto citur Qt) V8 JavaScriptCore (bez JITting) *

* Zemsvītras piezīme par pārlūku Chrome IOS. Tas, kā jūs droši vien zināt, izmanto UIWebView. Saskaņā ar UIWebView iespējām tas nozīmē, ka tas var izmantot tikai to pašu renderēšanas dzinēju kā Mobile Safari, JavaScriptCore (nevis V8) un vienu vītņotu modeli. Tomēr daži kodi ir aizgūti no Chromium, piemēram, tīklošana, grāmatzīmju infrastruktūras sinhronizācija, universālais lodziņš, metrika un avāriju pārskati. (Arī JavaScript ir tik reti mobilā tālruņa sastrēgums, ka JITting kompilatora trūkumam ir minimāla ietekme.)

Labi, tad kur mēs nonācām?

Un tagad viss WebKit ir pilnīgi atšķirīgs. Esmu nobijies.

Nav tā vērts! WebKit's layoutTest pārklājums ir milzīgs. (28 000 testi beidzot skaitīti), un ne tikai attiecībā uz esošajām funkcijām, bet arī uz visām atrastajām regresijām. Faktiski ikreiz, kad uzzināt jaunas vai “slepenas” DOM / CSS / HTML-5 funkcijas, testa “suiteTest” komplektiem parasti ir lieliska minimāla demonstrācija.

Turklāt W3C cenšas standartizēt testu komplektu. Tas nozīmē, ka mēs varam sagaidīt, ka gan WebKit porti, gan visas citas pārlūkprogrammas tiks pārbaudītas ar vienu un to pašu testu komplektu, kas ļaus mums samazināt dīvainības un savietojamāku tīmekli. Visiem tiem, kas pielika pūles, lai apmeklētu Test The Web Forward pasākumu ... paldies!

Opera tikko pārcēlās uz WebKit. Kas no tā sanāks?

Roberts Nimans un Robs Hokess jau ir skāruši šo tēmu, taču es piebildīšu, ka viena no nozīmīgajām paziņojuma daļām bija tā, ka Opera pāriet uz Chromium... Tas nozīmē WebGL, Canvas, HTML5 veidlapas, 2D grafikas ieviešanu, visas šīs lietas tagad Chrome un Opera būs vienādas. Tā pati API un zema līmeņa ieviešana. Tā kā Opera pamatā ir Chromium, jūs varat justies kā samazināt savu darbu, pārbaudot saderību Opera un Chrome.
Man arī tas būtu jāatzīmē visi Opera pārlūkprogrammas tiks tulkotas pārlūkā Chromium. Tas ir, Opera operētājsistēmām Windows, Mac, Linux un Opera Mobile (pilnvērtīgs mobilais pārlūks). Pat mazais klients Opera Mini tiks pārslēgts no pašreizējās Presto bāzes renderēšanas fermas uz citu Chromium bāzes.

... un iknedēļas WebKit veidošana. Kas tas ir?

Tas ir WebKit, kas darbojas ar to pašu kodu kā Safari (lai gan dažas iekšējās bibliotēkas ir modificētas). Pārsvarā Apple to vada, tāpēc uzvedība un funkciju kopa atbilst tam, ko atradīsit pārlūkprogrammā Safari. Daudzos gadījumos Apple ir konservatīvs, kad runa ir par tādu funkciju iespējošanu, kuras citas ostas ievieš vai eksperimentē. Jebkurā gadījumā, lai izmantotu analoģijas, domājiet, ka ... WebKit nakts versija Safari ir kā Chromium pārlūkam Chrome.
  • tīmekļa pārlūkprogrammas
  • web izstrāde
  • Pievienojiet tagus

    Pārlūka motors ir īpaša programma, kas darbojas ar tīmekļa lapām. Tas apstrādā no interneta lejupielādētu HTML lapu un pārveido tās kodu par lietotājiem pazīstamu attēlojumu. Interneta pārlūka dzinēji tiek izmantoti gan pašos pārlūkos, gan e-pasta klientos. Ne katrs tīmekļa pārlūks ir veidots uz savas unikālās platformas. Daudzi no viņiem izmanto populārus un laika pārbaudītus risinājumus. Šajā rakstā ir apskatīts, kādas platformas pastāv pārlūkprogrammu veidošanai un kā tās atšķiras viena no otras.

    Izmantojot renderēšanas programmu, lai izveidotu pārlūkprogrammas, ir daudz priekšrocību:

    • Atvieglo koda kļūdu meklēšanu un novēršanu.
    • Ērta iespēja uzlabot vienu komponentu vairākās programmās vienlaikus.
    • Tiek atvieglots lietojumprogrammas grafiskās saskarnes maiņas process.
    • Nepieciešama ērta jaunu programmu izveidošana pēc konkrēta izstrādātāja vai konkrēta lietotāja vēlmēm.

    Šādus risinājumus ļoti bieži izmanto programmēšanā: veidojot videospēles, operētājsistēmas sarežģītām programmām utt. Daži speciālisti strādā pie dzinēja uzlabošanas un optimizācijas, ieviešot tajā jaunas funkcijas un noderīgas funkcijas. Citi paši nodarbojas ar programmu izveidi, pamatojoties uz izstrādāto platformu.

    Lielisks piemērs ir Microsoft Trident dzinējs. Tas pats par sevi tiek izmantots visdažādākajos lietojumos konkrētā korporācijā. Bāze attīstās - attīstās arī atvasinātie projekti.

    Katram risinājumam ir savi plusi un mīnusi. Piemēram, daudzi lietotāji pamana, ka Mozilla Firefox darbojas daudz labāk ar atvērtākām cilnēm nekā konkurence. Tas ir sasniegums platformā, uz kuras ir veidota pārlūkprogramma.

    Trident

    Kad lietotājs instalē jaunu Windows operētājsistēmu, pirmais tīmekļa pārlūks, ar kuru viņi sastopas, ir Internet Explorer. Tāpēc pārskatā vispirms tiek apskatīts tā dzinējs.

    Trident jeb MSHTML ir diezgan vecs programmatūras komponents, ko Microsoft izstrādājis savām vajadzībām. Projekts tiek nepārtraukti attīstīts kopš 1997. gada. Tas tiek izmantots Microsoft tīmekļa pārlūkprogrammā - Internet Explorer, Outlook pasta klientā, Windows Explorer (failu pārvaldības programma) un daudzās citās šī izstrādātāja programmās.

    Lietotāji to uzskata par vienu no neveiksmīgākajiem pārlūka dzinējiem. Neatbalsta trešo pušu modulārus paplašinājumus - spraudņi, nepareizi parādot daudzas interneta lapas, nav visātrākais ātrums.

    Atbrīvojot Windows 10, Trident platforma pārtapa EdgeHTML, par pamatu ņemot novecojušu, sliktu motoru un izveidojot jaunu, kas atbilst visām mūsdienu lietotāju vajadzībām. Spriežot pēc etaloniem (programmatūras veiktspējas un ātruma pārbaude), Microsoft Edge (pārlūks, kura pamatā ir EdgeHTML) tika galā un pat pārspēja populārās programmas, kuras tika izmantotas Google Chrome un Mozilla Firefox pārlūku izveidošanai.

    Geko

    Gecko ir dzinējs, ko izmanto populārajā interneta pārlūkā Mozilla Firefox un daudzās citās programmās. Programmas avota kods ir brīvi pieejams, tas ir, ikviens var izveidot pats savu pārlūku vai e-pasta klientu, pamatojoties uz Gecko, absolūti bez maksas.

    Vēl viena Gecko priekšrocība ir starpplatforma. Tas darbojas lielākajā daļā mūsdienu operētājsistēmu: gan personālajiem datoriem, gan mobilajām ierīcēm (atšķirībā no Internet Explorer, kas darbojas tikai operētājsistēmā Windows).

    Gecko atbalsta visus mūsdienu standartus un tehnoloģijas, ko izmanto vietņu izstrādē. Tā ir viena no divām populārākajām pārlūka platformām. Atbalsta spraudņu savienojumu. Etaloni un lietotāju personīgā pieredze rāda, ka šī dzinēja pārlūkprogrammas patērē vismazāk personālā datora resursus un stabili strādā ar lielu skaitu cilņu (piemēram, vairākus simtus).

    Uz Gecko bāzes tiek izveidots populārais interneta pārlūks Mozilla Firefox, Thunderbird pasta klients, Sunbird uzdevumu plānotājs un anonīms tīmekļa pārlūks ar iebūvētu atbalstu VPN tehnoloģijām Tor.

    KHTML

    Neskaidra platforma, ko izmanto, lai izveidotu Konqueror, KDE vides failu pārvaldnieku. Lietotājiem, kuri nav pazīstami ar Linux saimes operētājsistēmām, tas ir interesanti, jo, pamatojoties uz šo projektu, ir izveidots populārākais dzinējs pasaulē, par kuru tiks runāts tālāk.

    WebKit

    Šo motoru izstrādāja pasaules slavenā Apple korporācija, pamatojoties uz iepriekšminēto risinājumu - KHTML. Šis projekts tika izlaists 2001. gadā, un tajā ir notikusi kolosāla attīstība un tas ir kļuvis par vienu no visvairāk izmantotajiem pasaulē.

    Balstoties uz WebKit, tika izveidots Safari tīmekļa pārlūks, kuru pēc noklusējuma izmanto iOS ierīcēs un pārlūkprogrammu popularitātes līderi - Google Chrome. Lielākais vairums mūsdienu Web lapu satura apstrādes programmu ir balstītas uz WebKit. To izmanto arī populārajā Steam lietojumprogrammā PC spēļu digitālai izplatīšanai no Valve.

    Līdzīgi kā Gecko, arī WebKit ir pārrobežu platforma un lieliski darbojas visās populārajās platformās. Rāda augstu stabilitāti un veiktspēju. Milzīgās popularitātes dēļ šim risinājumam tiek izstrādāts vairums paplašinājumu. Izmanto arī populārajās mobilajās platformās, piemēram, Android un iOS. Tas ir bezmaksas motors, tas ir, to ikviens var bez maksas izmantot, lai izveidotu savas lietojumprogrammas.

    2013. gadā no GoogleKK sadalījās jauna filiāle, kas pieder Google korporācijai Blink. Šis projekts veidoja Chrome 28. versijas (un visu nākamo), kā arī tā atvērtā koda brālēna Chromium pamatu. Hroms tika izmantots, lai izveidotu Krievijā populāro Yandex pārlūku. Sākot ar 15. versiju, Opera pārlūks arī pārslēdzās uz Blink.

    Presto

    Presto pārlūka dzinējs, kas tika palaists 2003. gadā, tika izmantots par pamatu Opera. Tā attīstās 10 gadus. 2013. gadā Opera izstrādātāji nolēma novirzīt Presto par labu jaudīgākam un populārākam Google Blink. Šobrīd projekta attīstība ir apturēta.

    Vai šis raksts bija noderīgs?

    Šajā rakstā mēs apskatīsim trīs populārā WebKit dzinēja pārlūkus. Izvēloties tīmekļa pārlūku, lietotāji mēdz meklēt slavenākās programmas: Google Chrome, Opera, Mozilla Firefox, Internet Explorer. Tajā pašā laikā daudzi aizmirst vai nezina, ka tas pats Firefox, Chrome un nesen arī Opera ir izveidoti, pamatojoties uz atvērtā pirmkoda projektiem, kas nozīmē, ka šīs programmas var modificēt.

    Šī iespēja noved pie tā, ka daudzi programmētāji ir izveidojuši vairākus populāru pārlūkprogrammu analogus, kas piedāvā diezgan interesantas iespējas. Tātad, pieņemsim apsvērt vairākus šādas programmatūras pārstāvjus.

    Tas tiek izplatīts bez maksas, tam ir krievu interfeiss, darbojas operētājsistēmās Windows, Android, Mac, iOS. Šis pārlūks pirms desmit gadiem bija pazīstams kā MyIE2 un bija Internet Explorer papildinājums, taču kopš tā laika daudz kas ir mainījies, un tagad programma pēc noklusējuma izmanto Webkit motoru.

    Jaunākajā, 4. versijā, pārlūks piedāvā vairākas noderīgas funkcijas, starp kurām visinteresantākā ir iespēja uzglabāt informāciju “mākonī”. Tas ļauj izmantot kontu programmā, lai pārsūtītu informāciju no dažādām ierīcēm, neatkarīgi no tā, vai tas ir Android sīkrīks, Apple kampaņas produkts vai stacionārs personālais dators.

    Lai arī Maxthon Cloud Browser saskarne ir veidota Chrome stilā, tai ir daudz vairāk funkciju. Sānjoslā tiek parādītas ikonas piekļuvei paplašinājumiem. Ir ērti, ka ar vienu klikšķi jūs varat atspējot vai iespējot visus instalētos papildinājumus, un no īpašas vietnes varat lejupielādēt jaunus.

    Tas tiek izplatīts bez maksas, tam ir krievu interfeiss, darbojas operētājsistēmā Windows. Kompānijas Comodo produkts, kas ir labāk pazīstams kā drošības programmatūras izstrādātājs. Comodo Dragon vairs nav izstrāde, bet gan montāža, jo funkcionalitātes ziņā tas daudz neatšķiras no Chrome.

    No sākotnējā pārlūka nav daudz atšķirību, un tie visi ir saistīti ar drošības jautājumiem. Pirmā galvenā atšķirība no Google Chrome ir patiešām inkognito režīms, Comodo Dragon neizmanto unikālu lietotāja ID un HTTP-REFERRER, kas neļauj izsekot lietotājam tīklā.

    Otrā atšķirība slēpjas Comodo pamatdarbībā, lietotāju drošībā. Pieņem, ka jums ir savi drošie DNS serveri datu pārraidei. Turklāt pēc lietotāja pieprasījuma satiksme var iet caur viņiem ne tikai Dragon, bet arī visas citas lietojumprogrammas. Drošie DNS serveri automātiski bloķē piekļuvi vietnēm, kuras pašas Comodo tīmekļa draudu noteikšanas tīklā ir atzīmētas kā neuzticamas.

    Tas tiek izplatīts bez maksas, tam ir krievu interfeiss, darbojas operētājsistēmā Windows. Yandex Browser ir nesen atbrīvots Chromium bāzes pārlūks no Krievijas uzņēmuma Yandex. Šajā produktā izstrādātāji ir vienkārši pievienojuši Yandex pakalpojumus ātro saišu panelim. Tāpat ir pievienots un pilnveidots režīms "Turbo", ko var atrast operā. Kopumā izrādījās, ka nav slikta pārlūkprogramma, kas paredzēta Yandex lietotājiem.