Mesin browser web - apa itu dan apa itu. Apa itu WebKit dan kaitannya dengan CSS

  • Transfer

Bagi banyak dari kita pengembang, WebKit - kotak hitam... Kami memasukkan HTML, CSS, JS dan sekumpulan gambar ke dalamnya, dan WebKit, entah bagaimana ... secara ajaib, memberi kami halaman web yang terlihat dan berfungsi dengan baik.
Tapi sebenarnya bagaimana kata kolega saya Ilya Grigorik :

Kit web tidak kotak hitam. Ini adalah kotak putih. Dan bukan hanya putih, tapi juga buka kotak.

Jadi, mari kita coba mencari tahu beberapa hal:
  • Apa itu WebKit?
  • Apa itu WebKit bukan?
  • Bagaimana WebKit digunakan oleh browser WebKit?
  • Mengapa banyak WebKit tidak sama?
Sekarang, terutama setelah berita bahwa Opera telah beralih ke WebKit, kami dikelilingi oleh banyak browser WebKit, dan sulit untuk mengatakan apa yang menyatukan mereka, dan ke mana mereka pergi. Di bawah ini, saya harap kami mencoba menjelaskan masalah ini. Hasilnya, Anda dapat mengidentifikasi perbedaan browser dengan lebih baik, mengirim bug ke pelacak yang benar, dan pengembangan lintas browser dengan lebih efisien.

Komponen Browser Web Standar

Mari daftar beberapa komponen peramban modern:
  • Parsing (Parsing HTML, XML, CSS, Javascript)
  • Tata Letak
  • Merender teks dan grafik
  • Gambar decoding
  • Interaksi GPU
  • Akses jaringan
  • Akselerasi perangkat keras
Manakah yang umum untuk semua browser WebKit? Hampir hanya dua yang pertama.

Setiap "port" WebKit mengimplementasikan komponen lain dengan caranya sendiri. Mari kita lihat apa artinya ini.

Port WebKit

Ada banyak "port" WebKit dan saya menyediakan Aria Hidayat, hacker WebKit, dan lainnya. direktur di Sencha memiliki hak untuk menceritakannya:

Asosiasi paling populer untuk WebKit biasanya adalah jenis WebKit milik Apple, yang berjalan di Mac OS X (pustaka WebKit pertama dan asli). Seperti yang Anda duga, berbagai antarmuka diimplementasikan menggunakan berbagai pustaka Mac OS X asli, yang sebagian besar difokuskan dalam komponen CoreFoundation Misalnya, jika Anda menentukan tombol datar berwarna dengan radius garis khusus, WebKit tahu di mana dan bagaimana menggambar tombol itu, sedangkan rendering akhir tombol (sebagai piksel pada monitor pengguna) berada pada CoreGraphics.

Seperti yang saya sebutkan di atas, CoreGraphics yang digunakan unik untuk setiap port WebKit. Chrome untuk Mac, misalnya, menggunakan Skia.

Pada titik tertentu, WebKit telah "di-porting" ke berbagai platform, baik desktop maupun seluler. Variasi ini biasanya disebut sebagai "port WebKit". Untuk Safari Windows, Apple juga secara independen "mem-porting WebKit" untuk berjalan di Windows menggunakan pustaka CoreFoundation (implementasi terbatas).

... terlepas dari kenyataan bahwa Safari untuk Windows sekarang sudah mati.
Selain itu, masih banyak "port" lainnya (lihat daftar lengkapnya). Google telah membuat dan terus mempertahankan port Chromium-nya. Ada juga WebKitGtk berdasarkan Gtk +. Nokia (dan sekarang Trolltech, yang membelinya) memelihara port WebKit Qt, yang menjadi populer sebagai modul QtWebKit.

Beberapa port WebKit

  • Safari
    - Safari di bawah OS X dan Safari di bawah Windows dua port berbeda
    - WebKit Nightly Build adalah kompilasi kode sumber untuk "port" Mac yang digunakan untuk Safari, hanya yang lebih baru
  • Mobile Safari
    - Dikembangkan di cabang pribadi, tetapi kemudian dibuka.
    - Chrome untuk iOS (menggunakan Apple WebView; sedikit kemudian tentang perbedaannya)
  • Chrome (Chromium)
    - Chrome untuk Android (menggunakan "port" Chromium secara langsung)
    - Chromium juga merupakan dasar untuk browser: Yandex ,, Sogou, dan segera, Opera.
  • Browser Android
    - Menggunakan kode sumber WebKit terbaru yang tersedia pada saat rilis.
  • Lebih banyak port: Amazon Silk, Dolphin, Blackberry, QtWebKit, WebKitGTK +, The EFL port (Tizen), wxWebKit, WebKitWinCE, dll
Port yang berbeda dapat berfokus pada tugas yang berbeda. Fokus port Mac adalah pemisahan antara browser dan sistem operasi, serta penyediaan binding Obj-C dan C ++ untuk menyematkan mesin rendering dalam aplikasi asli. Fokus port Chromium sepenuhnya pada browser. QtWebKit menawarkan portnya untuk digunakan bersama dengan arsitektur aplikasi lintas platformnya, sebagai mesin rendering.

Apa yang umum di semua browser WebKit

Pertama, mari kita lihat fitur umum yang digunakan di semua browser WebKit:

Anda tahu ini lucu, saya mencoba beberapa kali untuk menulis paragraf ini. Dan setiap kali anggota tim Chrome mengoreksi saya, seperti yang akan Anda lihat ...

  1. Jadi, pertama-tama, WebKit mengurai HTML dengan cara yang sama. Hanya saja, Chromium adalah satu-satunya port yang saat ini mendukung pengaliran untuk penguraian HTML.
  2. ... Ok, tapi setelah parsing HTML, pohon DOM dibuat dengan cara yang sama. Sebenarnya Shadow DOM hanya diaktifkan untuk port Chromium, jadi konstruksi DOM bervariasi. Juga untuk elemen khusus.
  3. ... Oke, WebKit membuat jendela dan objek dokumen yang sama untuk semua orang. Benar, meskipun properti dan konstruksi yang mereka sediakan mungkin bergantung pada penggunaan tanda fitur.
  4. ... Parsing CSS itu sama. Makan CSS Anda dan mengubahnya menjadi CSSOM cukup standar. Ya, meskipun Chrome hanya mendukung awalan -webkit-, sementara Apple dan browser lain mendukung awalan -khtml- dan -apel- yang tidak digunakan lagi.
  5. … Tata letak… penentuan posisi? Ini seperti roti dan mentega. Sama saja di mana-mana, bukan? Nah sudah! Tata letak subpiksel dan aritmatika tata letak yang kaya adalah bagian dari WebKit, tetapi berbeda dari satu port ke port lain.
  6. Super.

Jadi ini sulit.

Sekarang, mari kita coba meringkas apa yang umum di dunia WebKit ...

Apa yang umum untuk setiap port WebKit.

  • DOM, jendela, dokumen
    lebih atau kurang
  • CSSOM
  • Mengurai properti / nilai CSS
    perbedaan prefiks pabrikan
  • Mengurai HTML dan membangun DOM
    Sama halnya jika kita melupakan Komponen Web.
  • Tata letak dan pemosisian
    Flexbox, Floats, konteks pembentukan blok ... semuanya sama
  • Alat antarmuka pengguna, dan alat pengembang seperti Chrome DevTools alias inspektur WebKit.
    Meski sejak April lalu, Safari menggunakan inspektur Safari sendiri, non-WebKit, closed source.
  • Fitur seperti contenteditable, pushState, File API, kebanyakan SVG, CSS mengubah matematika, Web Audio API, localStorage
    Implementasinya mungkin berbeda. Setiap port dapat menggunakan penyimpanannya sendiri untuk localStorage dan dapat menggunakan API audio yang berbeda untuk API Audio Web.
Agak membingungkan, jadi mari kita coba melihat beberapa perbedaannya.

Sekarang, apa yang tidak umum untuk port WebKit:

  • Semua yang berhubungan dengan GPU
    - Transformasi 3D
    - WebGL
    - Video decoding
  • Menggambar 2D ke layar
    - Teknologi anti-aliasing
    - Merender gradien SVG dan CSS
  • Merender teks dan tanda hubung
  • Teknologi jaringan (SPDY, pra-rendering, transportasi WebSocket)
  • Mesin JavaScript
    - Mesin JavaScriptCore ada di repositori WebKit. Tetapi ada binding di WebKit untuk keduanya dan V8.
  • Merender elemen formulir
  • Perilaku tag video dan audio dan dukungan codec
  • Gambar decoding
  • Navigasi mundur / maju
    - Bagian pushState ()
  • Fitur SSL seperti Strict Transport Security dan Public Key Pins
Mari kita lihat salah satunya: Grafik 2D tergantung pada portnya, kami menggunakan pustaka yang sangat berbeda untuk merender ke layar:

Atau untuk lebih detailnya, fitur yang baru ditambahkan: CSS.supports () telah diaktifkan untuk semua port kecuali win dan wincairo, yang tidak mengaktifkan fitur bersyarat css3.

Sekarang, kita masuk ke detail teknis ... waktunya untuk bertele-tele. Bahkan pernyataan di atas tidak sepenuhnya benar. Sebenarnya ini adalah WebCore, itu adalah komponen yang umum. WebCore adalah layout, rendering, dan pustaka DOM untuk HTML dan SVG, dan pada dasarnya adalah apa yang dipikirkan orang ketika mereka mengatakan WebKit. Memang, "WebKit" secara teknis adalah lapisan pengikat antara WebCore dan "port", meskipun dalam percakapan normal perbedaan ini sebagian besar tidak relevan.

Diagram akan membantu:

Banyak komponen WebKit dapat dialihkan (ditampilkan dalam warna abu-abu).

Misalnya, mesin JavaScript WebKit, JavaScriptCore, adalah mesin default di WebKit. Ini awalnya didasarkan pada KJS (dari KDE) sejak hari-hari ketika WebKit dimulai sebagai cabang dari KHTML. Pada saat yang sama, port Chromium beralih ke mesin V8 dan menggunakan pengikatan DOM unik.

Font dan rendering teks adalah bagian yang sangat besar dari platform ini. Ada 2 jalur terpisah untuk teks di WebKit: Cepat dan Keras. Keduanya membutuhkan dukungan khusus platform (diimplementasikan di sisi port), tetapi Fast hanya perlu tahu cara blit glyph (yang cache WebKit untuk platform), ketika Complicated benar-benar mendorong rendering string ke level platform dan hanya mengatakan, tolong gambar ini.

“WebKit itu seperti sandwich. Jika tidak, dalam kasus Chromium, ini lebih seperti taco. Taco lezat dari teknologi web.
Dmitri Glazkov, peretas Chrome WebKit. Juara Komponen Web, dan shadow dom.

Sekarang, mari kita memperluas gambaran umum kita untuk melihat beberapa port dan beberapa subsistem. Di bawah ini adalah lima port WebKit, perhatikan bagaimana toolset berbeda untuk masing-masing port, terlepas dari komponen yang umum:

Chrome (OS X) Safari (OS X) QtWebKit Browser Android Chrome untuk iOS
Merender Skia CoreGraphics QtGui Tumpukan Android / Skia CoreGraphics
Jaringan Tumpukan jaringan Chromium CFNetwork QtNetwork Garpu tumpukan jaringan Chromium Tumpukan kromium
Font CoreText melalui Skia CoreText Qt internal Tumpukan Android CoreText
JavaScript V8 JavaScriptCore JSC (V8 digunakan di tempat lain di Qt) V8 JavaScriptCore (tanpa JITting) *

* Catatan kaki tentang Chrome untuk IOS. Ini menggunakan UIWebView seperti yang mungkin Anda ketahui. Konsisten dengan kemampuan UIWebView, ini berarti bahwa ia hanya dapat menggunakan mesin rendering yang sama seperti Mobile Safari, JavaScriptCore (bukan V8) dan model thread tunggal. Namun, beberapa kode dipinjam dari Chromium, seperti jaringan, infrastruktur sinkronisasi bookmark, mahakotak, metrik, dan pelaporan kerusakan. (Selain itu, JavaScript jarang menjadi hambatan di seluler sehingga kurangnya kompiler JITting memiliki dampak yang minimal.)

Oke, jadi kemana kita datang?

Jadi, semua WebKit benar-benar berbeda sekarang. Saya takut.

Tidak layak! Cakupan layoutTest WebKit sangat besar. (28.000 pengujian pada hitungan terakhir), dan tidak hanya untuk fungsi yang ada, tetapi juga untuk semua regresi yang ditemukan. Faktanya, setiap kali Anda mempelajari fitur DOM / CSS / HTML-5 baru atau "rahasia", rangkaian pengujian "layoutTest" biasanya memiliki demo minimal yang bagus.

Selain itu, W3C sedang berupaya untuk menstandarkan rangkaian pengujian. Ini berarti bahwa kita dapat mengharapkan port WebKit dan semua browser lain untuk diuji dengan rangkaian pengujian yang sama, yang akan mengarahkan kita untuk mengurangi quirks dan web yang lebih dapat dioperasikan. Untuk semua yang telah berusaha keras untuk menghadiri acara Test The Web Forward ... terima kasih!

Opera baru saja pindah ke WebKit. Apa hasilnya?

Robert Nyman dan Rob Hawkes telah menyentuh topik ini, tetapi saya akan menambahkan itu, salah satu bagian penting dari pengumuman itu adalah bahwa Opera beralih ke Chromium... Ini berarti WebGL, Canvas, formulir HTML5, implementasi grafik 2D, semua hal ini akan sama di Chrome dan Opera sekarang. API yang sama dan implementasi tingkat rendah. Karena Opera didasarkan pada Chromium, Anda mungkin merasa seperti Anda mengurangi pekerjaan Anda untuk memeriksa kompatibilitas di Opera dan Chrome.
Saya juga harus mencatat itu segala sesuatu Browser Opera akan diterjemahkan ke Chromium. Yakni, Opera untuk Windows, Mac, Linux, dan Opera Mobile (peramban seluler lengkap). Bahkan Opera Mini, klien tipis, akan dialihkan dari rendering farm berbasis Presto saat ini ke yang lain berbasis Chromium.

... dan WebKit yang dibangun setiap malam. Apa itu?

Ini adalah WebKit, yang berjalan pada kode yang sama dengan Safari (meskipun beberapa pustaka internal telah dimodifikasi). Sebagian besar Apple menjalankannya, sehingga perilaku dan rangkaian fitur cocok dengan apa yang dapat Anda temukan di Safari. Dalam banyak kasus, Apple konservatif dalam hal mengaktifkan fitur yang diterapkan atau dicoba oleh port lain. Bagaimanapun, untuk menggunakan analogi, pikirkan bahwa ... WebKit untuk Safari versi malam itu seperti Chromium untuk Chrome. Tambahkan tanda

Android dan iPhone - perang browser

Bagian 1. WebKit bergegas menyelamatkan

Mengembangkan aplikasi browser yang bertanggung jawab untuk memantau status jaringan

Seri Isi:

Secara total, platform iPhone dan Android memiliki lebih dari 100.000 aplikasi yang tersedia untuk diunduh dari berbagai sumber. Ini mengacu pada aplikasi "asli", yaitu. aplikasi yang dikembangkan dan dibuat menggunakan SDK yang sesuai, lalu diinstal pada perangkat seluler. Aplikasi "asli" semacam itu memungkinkan implementasi yang efisien dari kemampuan teknis perangkat seluler, termasuk dukungan untuk jaringan nirkabel, Bluetooth dan penyimpanan data, fungsi akselerometer atau kompas, dan keajaiban dan inovasi teknologi lainnya yang membuat perangkat seluler begitu menarik bagi pengguna. Popularitas aplikasi "asli" untuk iPhone dan platform Android sangat tinggi, tetapi sebagai tambahan, perangkat seluler memberikan banyak peluang untuk mengembangkan aplikasi Web. Teknologi seluler telah lama ditinggalkan, dan bersama mereka Internet seluler telah mencapai kematangan tertentu.

Artikel ini adalah yang pertama dari seri dua bagian tentang pengembangan aplikasi browser untuk platform iPhone dan Android. Tujuan dari seri ini adalah untuk memperkenalkan pembaca pada prinsip-prinsip dasar pembuatan aplikasi Web seluler Anda sendiri. Kemampuan aplikasi seluler tidak terbatas pada menjalankan situs web di perangkat seluler. Kami akan mempertimbangkan teknologi dan pendekatan dasar yang digunakan dalam pengembangan aplikasi seluler, yang memungkinkan untuk memilih bagian pengembangan perangkat lunak ini menjadi disiplin independen yang terpisah.

Popularitas platform Web disebabkan oleh fakta bahwa penggunaannya memungkinkan Anda menyelesaikan banyak masalah yang secara tradisional mengganggu pengembang dan administrator sistem. Diantara mereka:

  • Masalah Penginstalan: Menginstal aplikasi Web sangat mudah - cukup instal atau salin ke server dan beri tahu klien Anda URL mana yang harus diarahkan ke browser.
  • Masalah penskalaan: Aplikasi web menskalakan dengan mudah ke kumpulan server di pusat data berkinerja tinggi, dan menggunakan alat manajemen situs Web yang siap pakai untuk melayani aplikasi.
  • Tantangan Pengarsipan dan Pemulihan Data: Aplikasi web menggunakan penyimpanan data terpusat, sehingga menyederhanakan tugas pemulihan bencana.
  • Pertimbangan antarmuka pengguna: Kombinasi HTML, Cascading Style Sheets (CSS), JavaScript, dan grafik menciptakan antarmuka pengguna yang kaya yang jauh lebih unggul dalam fungsi dan tampilan untuk antarmuka yang dikembangkan dengan SDK asli. Yang terakhir, sebagai aturan, tidak dapat memberikan efek kehadiran penuh untuk aplikasi game dan tidak menjamin fungsionalitas yang diperlukan untuk terminal informasi interaktif.
  • Kemudahan Penggunaan: Sebagian besar aplikasi memerlukan elemen antarmuka pengguna yang sederhana dan mudah digunakan untuk mempermudah pengoperasian sehari-hari.

Aspek yang paling menarik dari model distribusi aplikasi Internet adalah bahwa ia mengubah perangkat lunak menjadi semacam layanan berlangganan yang merupakan cara penyampaian perangkat lunak yang saling menguntungkan. "Bagaimana?" - Anda bertanya. Mari kita lihat lebih dekat masalah ini.

Model distribusi perangkat lunak berbasis web memungkinkan pelanggan untuk mencoba produk sebelum membeli dengan risiko minimal dan biaya minimal. Jika klien menyukai versi trial, maka semua yang diperlukan darinya untuk penggunaan lebih lanjut dari produk perangkat lunak adalah membayar pembelian dengan kartu kredit (atau menggunakan sistem PayPal). Selain itu, model perangkat lunak sebagai layanan (SaaS) memberi pengguna cara yang nyaman dan menguntungkan untuk membeli perangkat lunak tanpa biaya awal yang signifikan, menjamin laba atas investasi dalam bulan pertama penggunaan, bukan dalam waktu yang lama.

Faktanya adalah praktis tidak ada dukungan untuk browser Web di perangkat seluler. Situasi berubah secara dramatis dengan munculnya teknologi yang disebut WebKit, yang dengan percaya diri telah mengambil tempatnya di bidang perangkat seluler berkat iPhone.

Hanya dalam beberapa tahun, platform iPhone telah menjadi klien Web nomor satu di dunia. Mengapa? Karena WebKit, ditambah dengan konektivitas Internet yang andal, memungkinkan untuk menggunakan layanan Web di perangkat seluler dengan jauh lebih efisien daripada di browser modern lainnya. Pemain seluler lain juga telah memperhatikan teknologi baru ini, dan sekarang seluruh pasar dapat dibagi menjadi perusahaan yang menggunakan WebKit, perusahaan yang akan menggunakan WebKit, dan perusahaan yang memiliki alasan untuk tidak menggunakan WebKit.

Jadi, apa itu WebKit?

WebKit dan HTML5

WebKit adalah mesin browser yang digunakan baik untuk mendukung browser Mobile Safari pada platform iPhone dan untuk mendukung browser pada platform Android. Tentu saja, WebKit juga digunakan di perangkat seluler lain, tetapi untuk keperluan artikel ini, kami akan membatasi diri pada mempertimbangkan platform iPhone dan Android.

WebKit adalah proyek sumber terbuka yang berasal dari pengembangan K Desktop Environment (KDE). Ini adalah proyek WebKit tempat aplikasi Web modern untuk perangkat seluler berutang kelahirannya. Karakteristik teknologi dan desain perangkat seluler tentu saja memainkan peran penting, tetapi pengguna seluler terutama tertarik pada konten. Jika perangkat seluler hanya menyediakan akses ke sebagian kecil konten Internet, kemungkinan besar perangkat tersebut tidak dapat masuk ke daftar teratas perangkat paling populer.

Sebagian besar dari kita lebih suka menjalani kehidupan yang memuaskan: jika kita membuka situs web di laptop sambil duduk di rumah, kita berharap melihat konten yang sama saat mengunjungi situs web itu saat di kereta. Konten adalah masalah utama dengan aplikasi seluler. Di mana pun kami berada atau apa pun yang kami lakukan, kami memerlukan akses ke data yang kami minati. Teknologi WebKit menyediakan konten yang kaya di iPhone dan platform Android.

Perlu dicatat bahwa WebKit juga digunakan di komputer desktop, misalnya, di browser Safari, yang merupakan browser utama platform Mac OS X. Baik versi desktop atau mesin browser untuk iPhone atau Android sedang dipertimbangkan, WebKit tetap menjadi teknologi paling canggih. mendukung HTML dan CSS. Faktanya, WebKit mendukung gaya CSS yang belum dirender oleh browser di mesin lain - sebagai contoh, Anda dapat menentukan sejumlah properti yang ditentukan oleh spesifikasi HTML5.

HTML5 adalah sekumpulan spesifikasi teknis awal yang menentukan teknologi berbasis browser seperti penyimpanan data sisi klien dengan dukungan SQL, pemindahan, transformasi, dan sebagainya. Spesifikasi HTML5 belum lengkap, tetapi begitu dasar-dasarnya diartikulasikan dengan jelas dan diterapkan di browser pada sebagian besar platform, permulaan aplikasi Web yang sederhana akan menjadi masa lalu yang terlupakan. Pengembangan aplikasi web akan menempati segmen yang signifikan dalam pengembangan perangkat lunak, dan ini tidak hanya tentang aplikasi untuk browser desktop, tetapi juga untuk browser seluler. Dari produk sampingan, aplikasi seluler akan menjadi komoditas utama di pasar aplikasi Web.

Fitur desain pengembangan aplikasi web seluler

Setelah Anda membuat keputusan untuk menguasai teknologi pengembangan Web, hanya ada sedikit alat yang dapat Anda gunakan. Pertama-tama, aplikasi dapat dibuat langsung di server sebagai file yang berisi kode HTML, CSS, dan JavaScript. Dalam hal ini, konten HTML dapat dikirimkan dalam bentuk file HTML statis, atau dapat dibuat secara dinamis melalui penggunaan berbagai teknologi yang bekerja di sisi server, misalnya, seperti PHP, ASP.NET, Java Servlet, dll. Bagaimanapun, dari sudut pandang Dari sudut pandang masalah yang dibahas dalam artikel ini, semuanya bermuara pada kode HTML, dan di sini poin terpenting bagi kami adalah bahwa teknologi WebKit memungkinkan browser merender HTML pada perangkat seluler.

Untuk menjalankan aplikasi Web di perangkat seluler (iPhone atau Android), pengguna harus meluncurkan browser dan memasukkan URL layanan yang sesuai, misalnya: http://yourcompanyname.com/applicationurl.

Pada saat yang sama, kisaran aplikasi Web seluler yang ditawarkan cukup luas: dari situs Web standar hingga aplikasi Web seluler yang dikembangkan secara khusus untuk platform seluler tertentu.

Menampilkan situs standar

Mesin WebKit, dikombinasikan dengan antarmuka yang intuitif dan ramah pengguna dari platform iPhone dan Android, memungkinkan Anda untuk melihat hampir semua situs Web di perangkat seluler Anda. Halaman web ditampilkan dengan cukup benar, tidak seperti generasi browser seluler sebelumnya, yang secara sewenang-wenang mengangkut konten atau tidak menampilkannya sama sekali. Saat halaman dimuat di browser berkemampuan WebKit, konten halaman cenderung berskala. Dalam hal ini, skala dipilih sehingga seluruh halaman pas dengan layar, meskipun dalam bentuk yang sangat berkurang, seringkali tidak dapat dibaca, seperti yang ditunjukkan pada Gambar 1. Namun demikian, halaman dapat digulir, diperbesar, dipindahkan, menyediakan akses mudah ke semua elemen konten ... Secara default, browser menggunakan jendela lebar 980px.

Meskipun tampilan penuh dari sebuah halaman Web di jendela browser itu sendiri merupakan peningkatan yang signifikan dari browser generasi sebelumnya, kemampuan teknologi seluler modern tidak terbatas pada itu.

Halaman web yang ramah seluler

Jika Anda ingin halaman Web Anda dapat diakses oleh pengguna seluler serta pengguna web umum, ada beberapa opsi pengoptimalan aplikasi Web seluler lainnya yang perlu dipertimbangkan.

Meskipun WebKit dapat menampilkan halaman Web dengan benar pada layar perangkat seluler, terdapat perbedaan antara perangkat yang menggunakan mouse, seperti laptop atau komputer desktop, dan perangkat sentuh, seperti iPhone atau smartphone Android. Perangkat sentuh dibedakan berdasarkan ukuran fisik dari area "klik", tidak adanya fungsi mengarahkan kursor ke elemen apa pun, dan urutan peristiwa lainnya. Jadi, jika Anda ingin membuat situs web yang nyaman bagi pengguna umum dan seluler, Anda perlu mempertimbangkan fitur-fitur perangkat seluler berikut:

  • Peramban iPhone dan Android mampu menampilkan seluruh halaman Web dalam bentuk yang cukup mudah dibaca - kualitas tampilan peramban ini jauh lebih tinggi daripada peramban seluler standar - jadi jangan terlalu cepat menyederhanakan desain situs Anda.
  • Ukuran ujung jari jauh lebih besar dari ukuran pointer mouse. Pertimbangkan faktor ini saat mendesain elemen navigasi situs Anda. Jangan letakkan tautan terlalu dekat satu sama lain, jika tidak pengguna tidak akan dapat mengeklik satu tautan tanpa menekan tautan yang berdekatan.
  • Item yang ditampilkan dengan kursor tidak akan berfungsi di perangkat seluler. Pengguna tidak bisa begitu saja "mengarahkan" jarinya ke elemen apa pun dengan cara yang sama seperti kursor mouse.
  • Peristiwa yang ditentukan dengan menekan dan menahan tombol mouse, menyeret mouse, dll., Diimplementasikan pada layar sentuh dengan cara yang berbeda. Beberapa dari peristiwa ini mungkin berfungsi di perangkat seluler, tetapi secara umum, Anda tidak perlu mengharapkan browser seluler dan browser desktop melakukan urutan tindakan yang sama.

Anda dapat menemukan pembahasan mendetail tentang aspek-aspek ini di artikel " iPhone beraksi"(Lihat bagian). Pada artikel ini, kami akan membatasi diri untuk membahas keuntungan WebKit, bukan kerugiannya.

Perhatikan masalah paling kentara yang dihadapi pengguna iPhone atau Android saat mengakses situs Web, yakni ukuran layar yang terbatas. Faktanya, layar perangkat seluler modern berukuran 320x480 atau 480x320, asalkan pengguna lebih suka melihat konten Web dalam konfigurasi lanskap. Seperti yang Anda lihat pada Gambar 1, WebKit dapat menampilkan halaman Web dengan benar yang dirancang untuk komputer desktop standar. Namun, saat halaman Web diperbesar, teks mungkin terlalu kecil untuk dibaca, sehingga pengguna harus menggulir, menggeser, dan memperbesar sebelum mereka dapat membaca teks. Bagaimana cara mengatasi batasan ini?

Cara termudah untuk membuat halaman yang tampil sama baiknya di jendela browser seluler dan di jendela browser desktop adalah dengan menggunakan tag meta kustom viewport.

Tag meta adalah tag HTML yang ditempatkan di bagian atas dokumen HTML. Contoh paling sederhana menggunakan tag viewport terlihat seperti ini: ... Saat Anda menambahkan meta tag ini ke halaman HTML, tampilannya di jendela browser seluler berskala dengan cara yang paling optimal (lihat Gambar 2). Browser yang tidak mendukung viewport cukup mengabaikan tag ini.

Dalam beberapa kasus, berguna untuk menentukan parameter penskalaan jendela, seperti yang ditunjukkan pada Gambar 3.

Untuk menentukan opsi penskalaan tertentu, tentukan nilai yang tepat untuk atribut konten dari tag meta viewport: ... Dengan mengubah nilai parameter skala awal, gambar dapat diperkecil atau diperbesar. Untuk platform iPhone dan Android, lebih baik menggunakan nilai antara 1.0 dan 1.3. Tag meta viewport juga mendukung penskalaan minimal dan maksimal, yang membatasi kemampuan pengguna untuk menskalakan halaman saat sedang memuat.

Meskipun karakteristik desain iPhone, khususnya ukuran layar 320x480, praktis tidak berubah sejak awal, parameter perangkat pada platform Android memiliki jangkauan yang cukup luas, karena perangkat seluler pada platform ini diproduksi oleh berbagai produsen dan ditujukan untuk berbagai kelompok pengguna. Oleh karena itu, jika Anda ingin aplikasi Web Anda populer di kalangan pengguna seluler, Anda harus mengetahui kemungkinan perbedaan dalam ukuran layar, resolusi, dan pertimbangan desain untuk perangkat Android.

Pengalaman telah menunjukkan bahwa selain perbedaan desain antara berbagai perangkat seluler Android, perangkat lunak Android itu sendiri berupaya menyesuaikan pengaturan halaman Web yang dimuat tergantung pada properti browser perangkat seluler. Selain stabilitas, platform Android memiliki serangkaian fitur dan kemampuan yang selalu berubah. Setelan untuk perangkat Android tertentu mungkin berbeda dari yang ada di lingkungan pengembangan Anda, bergantung pada versi SDK dan produsen perangkat. Gambar 4 menunjukkan layar pengaturan browser di V1.6 Android Emulator. Pengaturan layar memberi pengguna kemampuan untuk menentukan tingkat skala gambar di layar (jauh, dekat, sedang) atau memilih mode penskalaan halaman otomatis.

Di dunia perangkat seluler, perubahan adalah hal yang paling konstan, sehingga pengembangan dan pembaruan pasar perangkat lunak seluler harus dipertimbangkan. Misalnya, pengaturan browser Sprint Hero menyertakan serangkaian opsi yang sama sekali berbeda dari pengaturan default yang digunakan saat memuat halaman Web. Browser Hero dibangun di atas platform Android V1.5 menggunakan sejumlah modifikasi yang dibuat oleh HTC. Untungnya, saat menggunakan tag meta viewport, pengaturan khusus Hero akan diabaikan.

Sejauh ini, kita telah melihat bahwa WebKit melakukan pekerjaan yang cukup baik dalam memuat halaman Web, meskipun dalam bentuk yang sangat berkurang dan sulit dibaca. Kami kemudian memperluas kontrol atas bagaimana halaman ditampilkan pada layar ponsel dengan menggunakan meta tag viewport. Halaman yang ditampilkan sekarang lebih mudah dibaca dan dinavigasi. Tetapi ini masih belum cukup untuk membuat halaman kita terlihat dan berfungsi seperti aplikasi Web.

Dibuat untuk perangkat seluler

Mari beralih ke fitur desain halaman Web untuk audiens seluler. Sebagai contoh konkret, pertimbangkan halaman pendaftaran email Google untuk GMail.

Seperti inilah tampilan halaman ini di jendela browser desktop:


Jendela browser desktop menampilkan konten informasi di sebelah kiri, dan jendela pendaftaran itu sendiri ada di panel kanan. Di jendela browser seluler, halaman yang sama memiliki tampilan yang sama sekali berbeda.

Halaman yang ditunjukkan pada Gambar 6 pasti ditujukan untuk pengguna ponsel. Layar hanya menampilkan elemen halaman yang diperlukan pengguna untuk pekerjaan lebih lanjut - tidak diperlukan pengguliran, perpindahan, atau penskalaan tambahan.

Sekarang mari kita lihat penampil email dari versi seluler Gmail. Karena ruang layar yang tersedia untuk aplikasi sangat terbatas, penampil pesan memiliki tombol tambahan dan elemen navigasi. Dalam kasus ini, elemen navigasi yang ditampilkan tumpang tindih dengan jendela untuk melihat pesan. Selain itu, jangan gunakan terlalu banyak frame atau div gulir jika Anda dapat menghindarinya. Versi seluler Gmail memecahkan masalah ini dengan menggunakan menu pop-up yang muncul segera setelah pengguna selesai menggulir halaman. Menu pop-up berisi 3 tombol: Arsip, Menghapus dan Lebih... Dengan menekan tombol Lebih item menu tambahan muncul (lihat Gambar 7).

Ini benar-benar aplikasi yang dirancang untuk perangkat seluler.

Perlu diingat bahwa kami tidak ingin sengaja memiskinkan desain dan mengurangi pengalaman pengguna ponsel yang telah mengembangkan browser multifungsi untuk platform iPhone dan Android. Dari sudut pandang ini, penting untuk memperhatikan elemen yang ditampilkan di bagian bawah halaman Gmail (lihat Gambar 8):

Jika pengguna lebih menyukai fungsionalitas yang disempurnakan dari versi desktop, berikan opsi untuk mengunduh versi halaman yang sesuai.

Sekarang pertimbangkan kasus ketika Anda ingin membuat aplikasi yang menggunakan teknologi Web, tetapi terlihat seperti aplikasi seluler asli.

Konten khusus platform

Langkah selanjutnya adalah mengembangkan konten khusus untuk platform seluler tertentu. Ini mendefinisikan format halaman dan antarmuka sehingga halaman yang dihasilkan terlihat seperti aplikasi platform asli daripada situs Web publik standar. Apa yang kami maksud dengan aplikasi "asli"?

Sebelum menyelami diskusi tentang cara membuat aplikasi Web semirip mungkin dengan aplikasi asli untuk platform tertentu, mari kita kesampingkan properti umum browser iPhone dan Android dan secara singkat membahas perbedaan visual antara platform ini.

Aplikasi iPhone memiliki tampilan dan antarmuka khusus. Tunjukkan screenshot iPhone kepada seseorang dan, kecuali orang ini benar-benar jatuh dari bulan beberapa waktu yang lalu, dia hampir pasti akan langsung mengatakan bahwa itu adalah iPhone. Tunjukkan tangkapan layar perangkat seluler Android kepada orang yang sama, dan jawabannya tidak akan begitu jelas. Apa alasannya? Ada beberapa kemungkinan penjelasan. Pertama, iPhone muncul di pasaran jauh lebih awal dari perangkat Android dan berhasil mendapatkan banyak penggemar. Pikirkan orang-orang yang mengantri untuk membayar mahal untuk kemampuan terbatas iPhone V1. Suka atau tidak suka iPhone, produk Apple ini saat ini menjadi pemimpin pasar. Bagaimana dengan Android?

Platform Android adalah produk yang relatif baru, dan dalam banyak hal bertindak sebagai kebalikan dari iPhone, karena dirancang terutama untuk komunitas terbuka. Platform Android digunakan di berbagai perangkat (ponsel dan peralatan rumah tangga lainnya). Untuk memudahkan pembahasan, artikel ini akan membatasi diri pada penggunaan Android di ponsel.

Seiring waktu, jumlah perangkat Android di dunia akan melampaui jumlah iPhone. Ini karena perangkat Android diproduksi oleh berbagai perusahaan dan akan didukung oleh berbagai jaringan data. Dengan banyaknya pemain di pasar seluler Android, tidak diragukan lagi bahwa fragmentasi pasar tertentu harus diharapkan berdasarkan tampilan dan parameter perangkat. Tren ini terbukti di HTC SenseUI. Tampilan dan nuansa yang menarik ini tidak didukung oleh SDK Android dasar dan tidak kompatibel dengan perangkat Android lainnya. Motorola, Google dan Verizon telah bekerja sama untuk mengembangkan perangkat DROID berbasis Android baru. Ini adalah produk komersial pertama di platform Android 2.0.

Bandingkan keragaman sistem Android dengan tampilan dan nuansa iPhone yang seragam. IPhone adalah milik Apple yang sangat berharga. Munculnya aplikasi iPhone dapat berubah sedikit dari waktu ke waktu, tetapi perubahan kecil ini tidak mungkin dibandingkan dengan berbagai versi sistem Android, yang jumlahnya cukup besar bahkan sekarang, ketika platform berada pada tahap yang sangat awal.

Jadi, apa yang perlu dilakukan agar tampilan dan antarmuka aplikasi sedekat mungkin dengan program "asli"?

Jika ini adalah tantangan sebelum Web 2.0, itu akan menjadi masalah yang sangat besar. Upaya awal untuk mendukung beberapa browser klien (seluler dan desktop) mengandalkan beberapa pendekatan, misalnya:

  • Pengembangan situs paralel sepenuhnya
  • Pembuatan konten dinamis bergantung pada parameter userAgent
  • Penggunaan server proxy yang dapat mengubah konten bergantung pada setiap perangkat tertentu. Teknologi ini telah berhasil digunakan oleh RIM untuk menyediakan akses e-mail dari perangkat mobile klien.

Pendekatan semacam itu bisa sangat diterima dalam kasus di mana pengembangan dilakukan oleh tim yang besar dan didanai dengan baik. Dan bagaimana dengan bagian dunia lainnya? Tidak semua orang memiliki sumber keuangan yang signifikan, spesialis yang berkualifikasi tinggi, dan waktu yang tidak terbatas untuk menerapkan strategi semacam itu. Selain itu, seperti yang telah kami catat, Internet seluler dari generasi browser sebelumnya tidak dapat disebut nyaman atau populer untuk digunakan, jadi bagaimanapun Anda tidak boleh memikirkan metode dan pendekatan yang ketinggalan zaman.

Untungnya, kami tidak harus melakukan ini. Di era WebKit dan CSS, perbedaan tampilan dan nuansa perangkat seluler yang berbeda dapat diatasi melalui penggunaan stylesheet dan kueri media untuk memungkinkan gaya yang berbeda bergantung pada jenis perangkat tertentu. Teknologi kueri media memungkinkan Anda mendapatkan informasi tentang klien. Secara tradisional, browser mengirimkan nilai userAgent ke server, yang memungkinkan server untuk mengidentifikasi browser tertentu dan menentukan konten yang akan disajikan ke klien. Menggunakan kueri media, browser memilih gaya halaman berdasarkan kemampuannya. Contoh berikut mendemonstrasikan pemilihan style sheet untuk smartphone: ... Dan kueri ini menentukan lembar gaya untuk desktop: .

Internet Explorer V6

Pada saat penulisan ini, Internet Explorer V6 diperkirakan memiliki pangsa 20-30% dari total pasar browser, tetapi IE V6 berada di luar cakupan artikel ini.

Anda dapat menemukan informasi lebih rinci tentang kueri media di spesifikasi draf (lihat bagian).

Mari pertimbangkan contoh penggunaan kueri media untuk mengembangkan aplikasi yang menampilkan status server jaringan.

Program pemantauan jaringan

Tujuan dari aplikasi ini adalah untuk memonitor pengoperasian beberapa server. Vendor perangkat lunak independen seringkali harus mendukung banyak aplikasi di banyak server. Jika Anda telah mengembangkan perangkat lunak untuk waktu yang lama, Anda mungkin telah menemukan berbagai jenis server dan jenis aplikasi yang berbeda. Semua ini berarti bahwa situasi sangat mungkin terjadi ketika Anda tidak dapat menggunakan alat tunggal untuk melacak pekerjaan semua aplikasi yang diperlukan. Dalam hal ini, masuk akal untuk menggunakan aplikasi seluler untuk pemantauan jaringan (netmon). Aplikasi ini menyediakan semua fungsionalitas yang diperlukan namun tetap fleksibel dan mudah diakses dari perangkat seluler.

Aplikasi netmon menyertakan daftar server untuk dipantau. Indikator kinerja utama (KPI) dikumpulkan untuk setiap server. KPI adalah alat utama yang digunakan mahasiswa MBA selama bertahun-tahun untuk menilai keadaan bisnis saat ini. Dari perspektif hosting aplikasi Web, metrik berikut dapat digunakan sebagai KPI:

  • Jumlah transaksi selama periode waktu yang lalu
    • Pesanan
    • Permintaan direktori
    • Pesan email
    • Tampilan halaman
  • Waktu berlalu sejak transaksi terakhir
    • Memesan
    • Pertukaran data elektronik
    • Pesan dari mitra bisnis
    • Unggahan file dari vendor melalui FTP
  • Apakah database tersedia
  • Tanggal pencadangan terakhir
  • Jumlah Pesanan Rata-rata (USD)
  • Ruang disk kosong
  • Bandwidth untuk jam, hari, bulan terakhir

Metrik di atas dan parameter operasi serupa lainnya memungkinkan Anda menilai kesehatan sistem atau aplikasi tertentu. Misalnya, selama musim liburan, kami meninjau jumlah pesanan yang dilakukan di beberapa situs kami. Jika data tidak menunjukkan peningkatan yang stabil dalam jumlah pesanan setiap jam, kami melakukan analisis situasi yang lebih rinci.

Karena aplikasi tertentu membutuhkan kondisi dan sumber dayanya sendiri, netmon harus cukup fleksibel untuk mengakomodasi spesifikasi setiap aplikasi. Untuk memberikan tingkat fleksibilitas ini, kita akan mulai dengan mendefinisikan struktur data yang paling umum untuk mengakomodasi keadaan setiap sistem. Di Bagian 2, kita akan melihat lebih dekat dari mana data ini berasal dan bagaimana data itu diperbarui. Untuk saat ini, kami akan membatasi diri pada informasi berikut:

  • Nama situs
  • URL situs (beranda)
  • URL untuk mendapatkan pembaruan
  • Status: OK atau tidak
  • Singkat: Penjelasan tentang status server, yang akan baik-baik saja atau berisi string teks yang menunjukkan masalah paling serius untuk server itu
  • Elemen: Ini adalah sekumpulan pasangan nama / nilai yang kami perlukan untuk mengomunikasikan nilai KPI saat ini untuk masing-masing situs.

Aplikasi kami akan menampilkan indikator kinerja yang dihasilkan dengan cara yang mudah dinavigasi, memanfaatkan kekuatan CSS, jQuery dan WebKit untuk menarik perhatian pengguna ke area masalah. Seperti yang sudah kami sebutkan, tujuan utama dalam mengembangkan aplikasi ini adalah untuk dapat menjalankannya di platform iPhone, Android dan di komputer desktop di browser Safari.

Pengembangan aplikasi monitoring jaringan

Halaman web modern harus dibuat dengan cara deklaratif yang mendefinisikan struktur organisasi dan konten halaman. Penempatan dan pemformatan halaman dilakukan dengan menggunakan cascading CSS style sheets dan, dalam banyak kasus, menggunakan JavaScript. Faktanya, pustaka JavaScript telah menjadi sangat populer sehingga penggunaannya saat ini lebih merupakan aturan daripada pengecualian. Dalam aplikasi yang dibahas dalam artikel ini, kita akan menggunakan pustaka JavaScript populer jQuery. Aplikasi kami akan berjalan di iPhone, Android dan desktop. Ini akan menggunakan kode HTML yang sama dan menerapkan perbedaan yang diperlukan di stylesheet. Perlu dicatat di sini bahwa kami sengaja tidak melakukan upaya yang signifikan dalam mengembangkan tampilan yang menarik untuk aplikasi. Selain itu, latar belakang sengaja dipilih agar menarik, tidak selaras satu sama lain, untuk menarik perhatian tambahan pembaca pada pengaturan style sheets. Di Bagian 2, kami akan sedikit meningkatkan tampilan aplikasi, tetapi untuk saat ini HTML-nya terlihat seperti yang ditunjukkan pada Daftar 1.

Daftar 1. Kode HTML Aplikasi
Sumber Daya Jaringan Saya
Agen Pengguna Saya


Sekilas kode HTML yang diusulkan mengungkapkan fitur-fitur utama berikut:

  • Kode menggunakan dua file JavaScript eksternal: satu file library jQuery dan satu file pembantu untuk aplikasi kita.
  • Kode menggunakan meta tag viewport untuk menskalakan konten yang ditampilkan.
  • Stylesheet utama ditentukan oleh file netmon.css.
  • Parameter userAgent digunakan untuk menentukan lembar gaya bantu. Bergantung pada nilainya, stylesheet untuk iPhone, Android, atau untuk browser desktop akan dimuat.
  • Selama pemuatan halaman, jQuery dan fungsi pembantu yang ditentukan dalam file netmon.js digunakan untuk menampilkan data.
  • Ada beberapa tag div yang digunakan dalam kode utama halaman.
  • Terakhir, di dalam kode, terdapat link ke halaman yang menampilkan string userAgent. Tautan ini tidak ada hubungannya dengan aplikasi dan hanya digunakan untuk tujuan demonstrasi.

Sebelum kita melihat secara mendetail pada file stylesheet dan netmon.js yang benar-benar menentukan operasi dasar aplikasi, mari kita lihat aplikasi kita dalam keadaannya saat ini. Perhatikan lagi bahwa kami menggunakan tiga lembar gaya berbeda, satu untuk masing-masing dari tiga platform yang didukung. Untuk membuat proses pengembangan aplikasi lebih visual, setiap tabel menentukan warna latar belakangnya sendiri. Pada Gambar 9, halaman kita terbuka di Desktop Safari dan memiliki latar belakang biru.

Gambar 11 menunjukkan tampilan aplikasi di jendela browser iPhone (warna latar belakang hijau).

Stylesheet utama yang disimpan dalam file netmon.js ditunjukkan pada Listing 2.

Daftar 2. Style sheet utama
body (color: # 888888; font-family: Helvetica; font-size: 14px; margin: 0px; padding: 0;) .details (margin: 0px; padding: 0px; background-color: white; border: solid; border -width: 1px; -webkit-border-top-left-radius: 8px; -webkit-border-top-right-radius: 8px; -webkit-border-bottom-left-radius: 8px; -webkit-border-bottom -right-radius: 8px;) .OK (color: # 000000;) .BAD (color: # ff0000;) .odd (background-image: -webkit-gradient (linier, kiri atas, kanan bawah, dari (#ccc ), ke (# 999));) .even (background-image: -webkit-gradient (linear, left top, right bottom, from (# 999), to (#ccc));) .serverentry a (float: kanan; color: #ffffff;) .serveritems (color: # 000;) #header h1 (margin: 0; padding: 0; text-align: center; color: # 000;)

Menggunakan lembar gaya khusus untuk setiap platform memungkinkan Anda menyelesaikan tugas-tugas berikut:

  1. Ubah skema warna halaman. Hal ini memungkinkan, pertama, untuk mendemonstrasikan peran stylesheet dengan jelas, dan kedua, untuk menunjukkan betapa mudahnya memilih stylesheet yang diinginkan bergantung pada nilai parameter userAgent.
  2. Tetapkan ukuran font yang berbeda untuk platform seluler dan desktop.
  3. Lihat fitur WebKit yang sesuai. Ini akan menjadi penting jika aplikasi menggunakan browser tanpa dukungan WebKit, seperti Firefox.

Kode 3 menunjukkan kode untuk file iphone.css.

Kode 3. File iphone.css
body (background-color: # 00ff00;) .serverentry (-webkit-border-top-left-radius: 8px; -webkit-border-top-right-radius: 8px; -webkit-border-bottom-left-radius: 8px; -webkit-border-bottom-right-radius: 8px;) .name (font-size: 2em;) .summary (font-size: 1.5em;) .serverentry a (font-size: 1.5em;)

Seperti yang bisa kita lihat, warna latar belakang dari tag badan berwarna hijau (# 00ff00), dan ukuran font disesuaikan agar lebih mudah dibaca di layar perangkat seluler. Terakhir, mari kita lihat file netmon.js, yang mendefinisikan daftar server dan fungsi yang mengeluarkan data untuk setiap server (digunakan dalam Daftar 4). Sebagian dari kode file telah dihilangkan agar singkat; teks lengkapnya tersedia di bagian).

Kode 4. File netmon.js
var netmon \u003d (inisialisasi: function () (), resource: [(name: "msiservices.com", homeurl: "http://msiservices.com", pingurl: "http://msiservices.com/netmon.php ", status:" OK ", ringkasan:" OK ", item: [(name:" DiskSpace ", value:" 22.13 GB "), (name:" Database Up? ", value:" Yes ")]), (nama: "server 2", homeurl: "http: // someurl", pingurl: "http: //someurl/netmon.jsp", status: "OK", ringkasan: "OK", item: [(name: "DiskSpace", nilai: "100.8 GB"), (name: "Database Up?", Value: "Yes")]), // entri tambahan dipotong agar singkat], render: function (index, itm) (coba ( var ret \u003d "; ret + \u003d"
"; ret + \u003d" "+ itm.name +" Menunjukkan
"; 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"
"; return ret;) catch (e) (return"
Kesalahan saat merender item ["+ itm.name +"] "+ e +"
"; } } };

Jika bilah status server mana pun tidak OK, maka catatan server terkait ditampilkan dalam warna merah, seperti yang terlihat dari definisi kelas di file CSS. Selain itu, jika pemeriksaan status server menunjukkan adanya masalah (status tidak sama dengan OK), penjelasan singkat tentang masalah tersebut juga ditampilkan. Pada Gambar 9-11, Anda dapat melihat bahwa Server 4 kehabisan ruang disk. Mengklik baris server ini akan menampilkan pesan rinci tentang masalah (lihat Gambar 12).

Mengklik link menunjukkan di sebelah kanan nama server, halaman beranda server tersebut terbuka. Memiliki tautan seperti itu sangat nyaman karena dua alasan: pertama, Anda tidak perlu repot mengingat URL setiap server, dan kedua, Anda tidak perlu lagi repot mengetikkan URL itu dari keyboard perangkat seluler ( bahkan yang paling nyaman).

Jadi, jika kita berhasil menjalankan netmon di perangkat seluler, tugas dukungan server seharusnya tidak menimbulkan masalah.

Kesimpulan

Artikel ini memperkenalkan prinsip-prinsip pengembangan aplikasi Web untuk iPhone dan Android menggunakan teknologi WebKit. Di Bagian 2, kami akan memperluas kemampuan aplikasi kami dengan menambahkan fungsionalitas untuk memperbarui data menggunakan panggilan Ajax.

  • Transfer

Bagi banyak dari kita pengembang, WebKit - kotak hitam... Kami memasukkan HTML, CSS, JS dan sekumpulan gambar ke dalamnya, dan WebKit, entah bagaimana ... secara ajaib, memberi kami halaman web yang terlihat dan berfungsi dengan baik.
Tapi sebenarnya bagaimana kata kolega saya Ilya Grigorik :

Kit web tidak kotak hitam. Ini adalah kotak putih. Dan bukan hanya putih, tapi juga buka kotak.

Jadi, mari kita coba mencari tahu beberapa hal:
  • Apa itu WebKit?
  • Apa itu WebKit bukan?
  • Bagaimana WebKit digunakan oleh browser WebKit?
  • Mengapa banyak WebKit tidak sama?
Sekarang, terutama setelah berita bahwa Opera telah beralih ke WebKit, kami dikelilingi oleh banyak browser WebKit, dan sulit untuk mengatakan apa yang menyatukan mereka, dan ke mana mereka pergi. Di bawah ini, saya harap kami mencoba menjelaskan masalah ini. Hasilnya, Anda dapat mengidentifikasi perbedaan browser dengan lebih baik, mengirim bug ke pelacak yang benar, dan pengembangan lintas browser dengan lebih efisien.

Komponen Browser Web Standar

Mari daftar beberapa komponen peramban modern:
  • Parsing (Parsing HTML, XML, CSS, Javascript)
  • Tata Letak
  • Merender teks dan grafik
  • Gambar decoding
  • Interaksi GPU
  • Akses jaringan
  • Akselerasi perangkat keras
Manakah yang umum untuk semua browser WebKit? Hampir hanya dua yang pertama.

Setiap "port" WebKit mengimplementasikan komponen lain dengan caranya sendiri. Mari kita lihat apa artinya ini.

Port WebKit

Ada banyak "port" WebKit dan saya menyediakan Aria Hidayat, hacker WebKit, dan lainnya. direktur di Sencha memiliki hak untuk menceritakannya:

Asosiasi paling populer untuk WebKit biasanya adalah jenis WebKit milik Apple, yang berjalan di Mac OS X (pustaka WebKit pertama dan asli). Seperti yang Anda duga, berbagai antarmuka diimplementasikan menggunakan berbagai pustaka Mac OS X asli, yang sebagian besar difokuskan dalam komponen CoreFoundation Misalnya, jika Anda menentukan tombol datar berwarna dengan radius garis khusus, WebKit tahu di mana dan bagaimana menggambar tombol itu, sedangkan rendering akhir tombol (sebagai piksel pada monitor pengguna) berada pada CoreGraphics.

Seperti yang saya sebutkan di atas, CoreGraphics yang digunakan unik untuk setiap port WebKit. Chrome untuk Mac, misalnya, menggunakan Skia.

Pada titik tertentu, WebKit telah "di-porting" ke berbagai platform, baik desktop maupun seluler. Variasi ini biasanya disebut sebagai "port WebKit". Untuk Safari Windows, Apple juga secara independen "mem-porting WebKit" untuk berjalan di Windows menggunakan pustaka CoreFoundation (implementasi terbatas).

... terlepas dari kenyataan bahwa Safari untuk Windows sekarang sudah mati.
Selain itu, masih banyak "port" lainnya (lihat daftar lengkapnya). Google telah membuat dan terus mempertahankan port Chromium-nya. Ada juga WebKitGtk berdasarkan Gtk +. Nokia (dan sekarang Trolltech, yang membelinya) memelihara port WebKit Qt, yang menjadi populer sebagai modul QtWebKit.

Beberapa port WebKit

  • Safari
    - Safari di bawah OS X dan Safari di bawah Windows dua port berbeda
    - WebKit Nightly Build adalah kompilasi kode sumber untuk "port" Mac yang digunakan untuk Safari, hanya yang lebih baru
  • Mobile Safari
    - Dikembangkan di cabang pribadi, tetapi kemudian dibuka.
    - Chrome untuk iOS (menggunakan Apple WebView; sedikit kemudian tentang perbedaannya)
  • Chrome (Chromium)
    - Chrome untuk Android (menggunakan "port" Chromium secara langsung)
    - Chromium juga merupakan dasar untuk browser: Yandex ,, Sogou, dan segera, Opera.
  • Browser Android
    - Menggunakan kode sumber WebKit terbaru yang tersedia pada saat rilis.
  • Lebih banyak port: Amazon Silk, Dolphin, Blackberry, QtWebKit, WebKitGTK +, The EFL port (Tizen), wxWebKit, WebKitWinCE, dll
Port yang berbeda dapat berfokus pada tugas yang berbeda. Fokus port Mac adalah pemisahan antara browser dan sistem operasi, serta penyediaan binding Obj-C dan C ++ untuk menyematkan mesin rendering dalam aplikasi asli. Fokus port Chromium sepenuhnya pada browser. QtWebKit menawarkan portnya untuk digunakan bersama dengan arsitektur aplikasi lintas platformnya, sebagai mesin rendering.

Apa yang umum di semua browser WebKit

Pertama, mari kita lihat fitur umum yang digunakan di semua browser WebKit:

Anda tahu ini lucu, saya mencoba beberapa kali untuk menulis paragraf ini. Dan setiap kali anggota tim Chrome mengoreksi saya, seperti yang akan Anda lihat ...

  1. Jadi, pertama-tama, WebKit mengurai HTML dengan cara yang sama. Hanya saja, Chromium adalah satu-satunya port yang saat ini mendukung pengaliran untuk penguraian HTML.
  2. ... Ok, tapi setelah parsing HTML, pohon DOM dibuat dengan cara yang sama. Sebenarnya Shadow DOM hanya diaktifkan untuk port Chromium, jadi konstruksi DOM bervariasi. Juga untuk elemen khusus.
  3. ... Oke, WebKit membuat jendela dan objek dokumen yang sama untuk semua orang. Benar, meskipun properti dan konstruksi yang mereka sediakan mungkin bergantung pada penggunaan tanda fitur.
  4. ... Parsing CSS itu sama. Makan CSS Anda dan mengubahnya menjadi CSSOM cukup standar. Ya, meskipun Chrome hanya mendukung awalan -webkit-, sementara Apple dan browser lain mendukung awalan -khtml- dan -apel- yang tidak digunakan lagi.
  5. … Tata letak… penentuan posisi? Ini seperti roti dan mentega. Sama saja di mana-mana, bukan? Nah sudah! Tata letak subpiksel dan aritmatika tata letak yang kaya adalah bagian dari WebKit, tetapi berbeda dari satu port ke port lain.
  6. Super.

Jadi ini sulit.

Sekarang, mari kita coba meringkas apa yang umum di dunia WebKit ...

Apa yang umum untuk setiap port WebKit.

  • DOM, jendela, dokumen
    lebih atau kurang
  • CSSOM
  • Mengurai properti / nilai CSS
    perbedaan prefiks pabrikan
  • Mengurai HTML dan membangun DOM
    Sama halnya jika kita melupakan Komponen Web.
  • Tata letak dan pemosisian
    Flexbox, Floats, konteks pembentukan blok ... semuanya sama
  • Alat antarmuka pengguna, dan alat pengembang seperti Chrome DevTools alias inspektur WebKit.
    Meski sejak April lalu, Safari menggunakan inspektur Safari sendiri, non-WebKit, closed source.
  • Fitur seperti contenteditable, pushState, File API, kebanyakan SVG, CSS mengubah matematika, Web Audio API, localStorage
    Implementasinya mungkin berbeda. Setiap port dapat menggunakan penyimpanannya sendiri untuk localStorage dan dapat menggunakan API audio yang berbeda untuk API Audio Web.
Agak membingungkan, jadi mari kita coba melihat beberapa perbedaannya.

Sekarang, apa yang tidak umum untuk port WebKit:

  • Semua yang berhubungan dengan GPU
    - Transformasi 3D
    - WebGL
    - Video decoding
  • Menggambar 2D ke layar
    - Teknologi anti-aliasing
    - Merender gradien SVG dan CSS
  • Merender teks dan tanda hubung
  • Teknologi jaringan (SPDY, pra-rendering, transportasi WebSocket)
  • Mesin JavaScript
    - Mesin JavaScriptCore ada di repositori WebKit. Tetapi ada binding di WebKit untuk keduanya dan V8.
  • Merender elemen formulir
  • Perilaku tag video dan audio dan dukungan codec
  • Gambar decoding
  • Navigasi mundur / maju
    - Bagian pushState ()
  • Fitur SSL seperti Strict Transport Security dan Public Key Pins
Mari kita lihat salah satunya: Grafik 2D tergantung pada portnya, kami menggunakan pustaka yang sangat berbeda untuk merender ke layar:

Atau untuk lebih detailnya, fitur yang baru ditambahkan: CSS.supports () telah diaktifkan untuk semua port kecuali win dan wincairo, yang tidak mengaktifkan fitur bersyarat css3.

Sekarang, kita masuk ke detail teknis ... waktunya untuk bertele-tele. Bahkan pernyataan di atas tidak sepenuhnya benar. Sebenarnya ini adalah WebCore, itu adalah komponen yang umum. WebCore adalah layout, rendering, dan pustaka DOM untuk HTML dan SVG, dan pada dasarnya adalah apa yang dipikirkan orang ketika mereka mengatakan WebKit. Memang, "WebKit" secara teknis adalah lapisan pengikat antara WebCore dan "port", meskipun dalam percakapan normal perbedaan ini sebagian besar tidak relevan.

Diagram akan membantu:

Banyak komponen WebKit dapat dialihkan (ditampilkan dalam warna abu-abu).

Misalnya, mesin JavaScript WebKit, JavaScriptCore, adalah mesin default di WebKit. Ini awalnya didasarkan pada KJS (dari KDE) sejak hari-hari ketika WebKit dimulai sebagai cabang dari KHTML. Pada saat yang sama, port Chromium beralih ke mesin V8 dan menggunakan pengikatan DOM unik.

Font dan rendering teks adalah bagian yang sangat besar dari platform ini. Ada 2 jalur terpisah untuk teks di WebKit: Cepat dan Keras. Keduanya membutuhkan dukungan khusus platform (diimplementasikan di sisi port), tetapi Fast hanya perlu tahu cara blit glyph (yang cache WebKit untuk platform), ketika Complicated benar-benar mendorong rendering string ke level platform dan hanya mengatakan, tolong gambar ini.

“WebKit itu seperti sandwich. Jika tidak, dalam kasus Chromium, ini lebih seperti taco. Taco lezat dari teknologi web.
Dmitri Glazkov, peretas Chrome WebKit. Juara Komponen Web, dan shadow dom.

Sekarang, mari kita memperluas gambaran umum kita untuk melihat beberapa port dan beberapa subsistem. Di bawah ini adalah lima port WebKit, perhatikan bagaimana toolset berbeda untuk masing-masing port, terlepas dari komponen yang umum:

Chrome (OS X) Safari (OS X) QtWebKit Browser Android Chrome untuk iOS
Merender Skia CoreGraphics QtGui Tumpukan Android / Skia CoreGraphics
Jaringan Tumpukan jaringan Chromium CFNetwork QtNetwork Garpu tumpukan jaringan Chromium Tumpukan kromium
Font CoreText melalui Skia CoreText Qt internal Tumpukan Android CoreText
JavaScript V8 JavaScriptCore JSC (V8 digunakan di tempat lain di Qt) V8 JavaScriptCore (tanpa JITting) *

* Catatan kaki tentang Chrome untuk IOS. Ini menggunakan UIWebView seperti yang mungkin Anda ketahui. Konsisten dengan kemampuan UIWebView, ini berarti bahwa ia hanya dapat menggunakan mesin rendering yang sama seperti Mobile Safari, JavaScriptCore (bukan V8) dan model thread tunggal. Namun, beberapa kode dipinjam dari Chromium, seperti jaringan, infrastruktur sinkronisasi bookmark, mahakotak, metrik, dan pelaporan kerusakan. (Selain itu, JavaScript jarang menjadi hambatan di seluler sehingga kurangnya kompiler JITting memiliki dampak yang minimal.)

Oke, jadi kemana kita datang?

Jadi, semua WebKit benar-benar berbeda sekarang. Saya takut.

Tidak layak! Cakupan layoutTest WebKit sangat besar. (28.000 pengujian pada hitungan terakhir), dan tidak hanya untuk fungsi yang ada, tetapi juga untuk semua regresi yang ditemukan. Faktanya, setiap kali Anda mempelajari fitur DOM / CSS / HTML-5 baru atau "rahasia", rangkaian pengujian "layoutTest" biasanya memiliki demo minimal yang bagus.

Selain itu, W3C sedang berupaya untuk menstandarkan rangkaian pengujian. Ini berarti bahwa kita dapat mengharapkan port WebKit dan semua browser lain untuk diuji dengan rangkaian pengujian yang sama, yang akan mengarahkan kita untuk mengurangi quirks dan web yang lebih dapat dioperasikan. Untuk semua yang telah berusaha keras untuk menghadiri acara Test The Web Forward ... terima kasih!

Opera baru saja pindah ke WebKit. Apa hasilnya?

Robert Nyman dan Rob Hawkes telah menyentuh topik ini, tetapi saya akan menambahkan itu, salah satu bagian penting dari pengumuman itu adalah bahwa Opera beralih ke Chromium... Ini berarti WebGL, Canvas, formulir HTML5, implementasi grafik 2D, semua hal ini akan sama di Chrome dan Opera sekarang. API yang sama dan implementasi tingkat rendah. Karena Opera didasarkan pada Chromium, Anda mungkin merasa seperti Anda mengurangi pekerjaan Anda untuk memeriksa kompatibilitas di Opera dan Chrome.
Saya juga harus mencatat itu segala sesuatu Browser Opera akan diterjemahkan ke Chromium. Yakni, Opera untuk Windows, Mac, Linux, dan Opera Mobile (peramban seluler lengkap). Bahkan Opera Mini, klien tipis, akan dialihkan dari rendering farm berbasis Presto saat ini ke yang lain berbasis Chromium.

... dan WebKit yang dibangun setiap malam. Apa itu?

Ini adalah WebKit, yang berjalan pada kode yang sama dengan Safari (meskipun beberapa pustaka internal telah berubah). Sebagian besar Apple menjalankannya, sehingga perilaku dan rangkaian fitur cocok dengan apa yang akan Anda temukan di Safari. Dalam banyak kasus, Apple bersikap konservatif dalam hal mengaktifkan fitur yang diterapkan atau dicoba oleh port lain. Bagaimanapun, untuk menggunakan analogi, pikirkan bahwa ... WebKit untuk Safari yang dibangun setiap malam itu seperti Chromium untuk Chrome.
  • browser web
  • pengembangan web
  • Tambahkan tanda

    Mesin browser adalah program khusus yang bekerja dengan halaman web. Ini memproses halaman HTML yang diunduh dari Internet dan mengubah kodenya menjadi representasi yang akrab bagi pengguna. Mesin browser Internet digunakan di browser itu sendiri serta di klien email. Tidak setiap browser web dibangun di atas platform uniknya sendiri. Banyak dari mereka menggunakan solusi populer dan teruji waktu. Artikel ini membahas platform apa yang tersedia untuk membuat browser, dan perbedaannya satu sama lain.

    Menggunakan mesin Rendering untuk membuat browser memiliki banyak keuntungan:

    • Memfasilitasi pencarian dan penghapusan kesalahan kode.
    • Kesempatan yang nyaman untuk meningkatkan satu komponen dalam beberapa program sekaligus.
    • Proses mengubah antarmuka grafis aplikasi difasilitasi.
    • Kemudahan membuat program baru untuk keinginan pengembang tertentu atau kebutuhan pengguna tertentu.

    Solusi semacam itu sangat sering digunakan dalam pemrograman: saat membuat gim video, sistem operasi untuk program yang kompleks, dan sebagainya. Beberapa spesialis sedang bekerja untuk meningkatkan dan mengoptimalkan mesin, memperkenalkan fitur baru dan fungsi yang berguna ke dalamnya. Yang lain terlibat dalam pembuatan program itu sendiri berdasarkan platform yang dikembangkan.

    Contoh utama adalah mesin Trident Microsoft. Itu sendiri digunakan dalam berbagai aplikasi di perusahaan tertentu. Basisnya sedang berkembang - proyek turunan juga sedang berkembang.

    Setiap solusi memiliki pro dan kontra masing-masing. Misalnya, banyak pengguna memperhatikan bahwa Mozilla Firefox berkinerja jauh lebih baik dengan lebih banyak tab terbuka daripada pesaing. Ini adalah pencapaian platform tempat browser dibuat.

    Trisula

    Saat pengguna menginstal sistem operasi Windows baru, browser web pertama yang mereka temui adalah Internet Explorer. Karena itu, mesinnya dianggap pertama kali dalam review.

    Trident, atau MSHTML, adalah komponen perangkat lunak yang cukup lama yang dikembangkan oleh Microsoft untuk kebutuhannya sendiri. Proyek ini terus berkembang sejak 1997. Ini digunakan di browser web Microsoft - Internet Explorer, klien email Outlook, Windows Explorer (pengelola file), dan banyak aplikasi lain dari pengembang ini.

    Ini dianggap sebagai salah satu mesin browser yang paling tidak berhasil oleh pengguna. Tidak mendukung ekstensi modular pihak ketiga - plugin, salah menampilkan banyak halaman Internet, tidak memiliki kecepatan tercepat.

    Dengan dirilisnya Windows 10, platform Trident berevolusi menjadi EdgeHTML, menggunakan mesin lama yang gagal sebagai fondasi dan membuat yang baru yang memenuhi semua kebutuhan pengguna saat ini. Dilihat dari tolok ukurnya (kinerja perangkat lunak dan uji kecepatan), Microsoft Edge (peramban berbasis EdgeHTML) berhasil menyusul dan bahkan melampaui program populer yang digunakan untuk membuat peramban Google Chrome dan Mozilla Firefox.

    Tokek

    Gecko adalah mesin yang digunakan di browser Internet populer Mozilla Firefox dan banyak program lainnya. Kode sumber program ini tersedia secara gratis, artinya, setiap orang dapat membuat browser atau klien email mereka sendiri berdasarkan Gecko secara gratis.

    Keunggulan lain dari Gecko adalah lintas platform. Ini berfungsi pada sebagian besar sistem operasi modern: baik untuk komputer pribadi dan untuk perangkat seluler (tidak seperti Internet Explorer, yang hanya berjalan di Windows).

    Gecko mendukung semua standar dan teknologi modern yang digunakan dalam pengembangan situs web. Ini adalah salah satu dari dua platform browser paling populer. Mendukung koneksi plugin. Tolok ukur dan pengalaman pribadi pengguna menunjukkan bahwa browser pada mesin ini mengonsumsi sumber daya paling sedikit dari komputer pribadi dan bekerja secara stabil dengan sejumlah besar tab (misalnya, beberapa ratus).

    Berdasarkan Gecko, browser Internet populer Mozilla Firefox, klien email Thunderbird, penjadwal tugas Sunbird, dan browser web anonim dengan dukungan bawaan untuk teknologi VPN Tor dibuat.

    KHTML

    Platform tidak jelas yang digunakan untuk membangun Konqueror, pengelola file untuk lingkungan KDE. Bagi pengguna yang tidak terbiasa dengan sistem operasi keluarga Linux, ini menarik karena berdasarkan proyek ini mesin paling populer di dunia telah dibuat, yang akan dibahas nanti.

    WebKit

    Mesin ini dikembangkan oleh perusahaan Apple yang terkenal di dunia berdasarkan solusi yang disebutkan di atas - KHTML. Dirilis pada tahun 2001, proyek ini telah mengalami perkembangan kolosal dan menjadi salah satu yang paling banyak digunakan di dunia.

    Berdasarkan WebKit, browser web Safari telah dibuat, yang digunakan secara default di perangkat iOS dan merupakan pemimpin dalam popularitas di antara browser - Google Chrome. Sebagian besar program modern untuk memproses konten halaman web didasarkan pada WebKit. Ini juga digunakan dalam aplikasi Steam populer untuk distribusi digital game PC dari Valve.

    Mirip dengan Gecko, WebKit adalah lintas platform dan berjalan dengan sempurna di semua platform populer. Menunjukkan stabilitas dan kinerja tinggi. Karena popularitas yang luar biasa, sebagian besar ekstensi sedang dikembangkan untuk solusi ini. Juga digunakan di platform seluler populer seperti Android dan iOS. Ini adalah mesin gratis, yaitu dapat digunakan secara gratis oleh siapa saja untuk membuat aplikasi mereka sendiri.

    Pada 2013, cabang baru milik perusahaan Google, Blink, memisahkan diri dari WebKit. Proyek ini membentuk dasar dari Chrome versi 28 (dan semua yang berikutnya), serta sepupu open source - Chromium. Chromium digunakan untuk membuat Peramban Yandex, populer di Rusia. Dimulai dengan versi 15, browser Opera juga beralih ke Blink.

    Presto

    Diluncurkan pada tahun 2003, mesin browser Presto digunakan sebagai dasar untuk Opera. Ini telah berkembang selama 10 tahun. Pada 2013, pengembang Opera memutuskan untuk meninggalkan Presto demi Blink yang lebih kuat dan populer dari Google. Saat ini, pengembangan proyek dihentikan.

    Apakah artikel ini berguna?

    Pada artikel ini, kita akan melihat tiga browser di mesin WebKit yang populer. Saat memilih browser web, pengguna cenderung melihat ke program yang paling terkenal: Google Chrome, Opera, Mozilla Firefox, Internet Explorer. Pada saat yang sama, banyak orang lupa atau tidak tahu bahwa Firefox, Chrome, dan yang lebih baru, Opera dibuat berdasarkan proyek open source, yang berarti bahwa program-program ini dapat dimodifikasi.

    Peluang ini mengarah pada fakta bahwa banyak programmer telah membuat beberapa analog dari browser populer yang menawarkan fitur yang cukup menarik. Jadi, mari kita lihat beberapa perwakilan perangkat lunak semacam itu.

    Ini didistribusikan secara gratis, memiliki antarmuka Rusia, berfungsi di Windows, Android, Mac, iOS. Browser ini sepuluh tahun yang lalu dikenal sebagai MyIE2 dan merupakan add-on untuk Internet Explorer, tetapi sejak itu banyak yang berubah dan sekarang program menggunakan mesin Webkit secara default.

    Di versi terbaru, ke-4, browser menawarkan beberapa fungsi yang berguna, di antaranya yang paling menarik adalah kemampuan untuk menyimpan informasi di "cloud". Hal ini memungkinkan penggunaan akun dalam program untuk mentransfer informasi antara perangkat yang berbeda, baik itu gadget Android, produk kampanye Apple atau PC stasioner.

    Meskipun antarmuka Browser Cloud Maxthon dibuat dengan gaya Chrome, ia memiliki lebih banyak fitur. Bilah sisi menampilkan ikon untuk mengakses ekstensi. Sangat mudah bahwa dengan satu klik Anda dapat menonaktifkan atau mengaktifkan semua add-on yang diinstal, dan Anda dapat mendownload yang baru dari situs khusus.

    Ini didistribusikan secara gratis, memiliki antarmuka Rusia, berfungsi pada Windows. Produk dari perusahaan Comodo, yang lebih dikenal sebagai pengembang perangkat lunak keamanan. Comodo Dragon tidak lagi merupakan pengembangan, tetapi perakitan, karena dalam hal fungsionalitasnya sedikit berbeda dari Chrome.

    Tidak banyak perbedaan dari browser aslinya, dan semuanya terkait dengan masalah keamanan. Perbedaan utama pertama dari Google Chrome adalah mode penyamaran, Comodo Dragon tidak menggunakan ID pengguna unik dan HTTP-REFERRER, yang tidak memungkinkan pelacakan pengguna di jaringan.

    Perbedaan kedua terletak pada bisnis inti Comodo, keamanan pengguna. Mengasumsikan Anda memiliki server DNS aman Anda sendiri untuk transmisi lalu lintas. Selain itu, atas permintaan pengguna, lalu lintas dapat melewati mereka tidak hanya Naga, tetapi juga semua aplikasi lainnya. Server DNS yang aman secara otomatis memblokir akses ke situs yang telah ditandai sebagai tidak tepercaya di Jaringan Definisi Ancaman Web milik Comodo.

    Ini didistribusikan secara gratis, memiliki antarmuka Rusia, berfungsi pada Windows. Yandex Browser adalah peramban berbasis Chromium yang baru saja dirilis dari perusahaan Rusia Yandex. Di produk ini, pengembang hanya menambahkan layanan Yandex ke panel tautan cepat. Selain itu, mode "Turbo", yang dapat ditemukan di Opera, telah ditambahkan dan ditingkatkan. Secara umum, ternyata bukan browser buruk yang ditujukan untuk pengguna Yandex.