Chrome が単なる代替手段だった時代は終わりました。 いくつかの独立した情報源からの統計によると、この Web ブラウザはすでに Internet Explorer を追い越し、世界で最も広く使用されているブラウザであるか、その末尾に位置しているかのどちらかです。

Google Chrome の機能はアドオンを使用してほぼ無限に拡張できますが、同じ WebKit エンジンに基づいた代替ブラウザ ビルドを使用すると、場合によっては拡張機能を使用して達成できないことを実現できます。 このレビューでは、Chrome の最も人気のある代替手段とその機能を検討します。

当然のことながら、レビューの犯人である Chrome と Chromium から始めましょう。 これらのブラウザについては多くのことを説明できますが、この資料はブラウザに特化したものではないため、これらの Web ブラウザについては表面的にのみ触れます。

以前の ChromePlus は、Google がブラウザよりも優れていることを示唆する名前を好まなかったため、CoolNovo に名前が変更されました。 しかし、公正に判断すれば、これはまさに起こったことであり、いくつかの点では、CoolNovo は現在でも Chrome よりも優れています。

3 年前に人気を博した ChromePlus の最大の特徴は、本格的な広告ブロッカーを使用できるようにする改造コードでした。 オリジナルの Chrome は当初、AdBlock に代わる通常の代替手段が存在しなかったため、ほとんどのユーザーによって拒否されました。

Chrome 拡張機能は同じユーザー エクスペリエンスを提供しないため、マウス ジェスチャのサポートは依然として重要です。 たとえば、Chrome では、ジェスチャが描画されず、認識されない「アイドル ショット」が発生することがあります (特に、使用中に一定の時間が経過した後)。 線のレンダリングもぎくしゃくしたり遅れたりすることが多く、正しいジェスチャを描画することが困難になります。 しかし、最も重要な違いは、CoolNovo ジェスチャは、Chrome がジェスチャをサポートしていないテクニカル ページ (たとえば、「404」ページ、新しいタブ、またはブラウザ設定のあるタブ) でも機能することです。

スムーズ スクロールは Chrome にはまだ実装されておらず、アドオンが必要ですが、CoolNovo には最初から備わっていました。

ブラウザは 2 つのエンジン (WebKit と Trident) を同時に使用します。 Internet Explorer でレンダリングされたページを見る必要がある場合は、アドレス バーの 1 つのボタンをクリックすることで実行できます。 CoolNovo は 2 つのエンジン間で Cookie を同期するため、サイトに再度ログインしなくてもページを表示できます。

SuperDrag は、ラップトップでのブラウザ エクスペリエンスを簡素化します。 リンク、画像、または選択したテキストをページ上にドラッグすると、それらは新しいタブで開きます。 言い換えれば、SuperDrag は、タッチパッドには存在しないマウスの中ボタンの代わりになります。

公式には、Google は現在でもブラウザのポータブル バージョンを提供していませんが、CoolNovo は常にインストーラーとポータブル アーカイブの両方として配布されています。

それほど重要ではない機能もリストできます。

閉じたタブの便利な復元。
- ブラウザをシステム トレイに最小化します (構成可能)。
- タブをダブルクリックしてタブを閉じます (これも、マウスの中ボタンがないラップトップでは便利です)。
- サイト名を表示するスペースを確保するために、タブ上の十字を非表示にする機能。
- ブックマークをゴミ箱に削除します。
- いくつかの拡張機能を表示できるサイドバーの存在
- Boss キー (ブラウザをすばやく最小化するため)。
- 追加のホットキー。
- ディスク上にダウンロードしたファイルをブラウザから直接削除する機能
- ダウンロード パネルのダウンロード速度インジケーター (KB/秒)。

CoolNovo は WebKit で最も人気のあるブラウザの 1 つであるという事実にもかかわらず、最近では徐々にその地位を失い始めています。 これは定期的なアップデートが行われていないことが原因です (最新バージョンは 3 月末にリリースされました)。 現時点では、状況はまだ危機的ではありませんが、Chrome と CoolNovo の間にはすでに 4 つのバージョンの違いがあります (CoolNovo は Chromium 17 コードを使用し、後者は Chromeのバージョン- 21)、わずかな遅延により、CoolNovo が歴史展示物の博物館に送られる可能性があります。

Comodo のちょっと変わったブラウザ。 数年前に登場しましたが、Chrome との違いについてはホームページにまだ明確な情報がありません。 私たちが調べた限りでは、セキュリティを向上させるために文字通りいくつかの変更がブラウザに加えられています。

インストール中に、Comodo SecureDNS サービスの使用に同意することができます。その後、ブラウザーはすべてのリクエストをこの安全なインターネット サーバー経由で送信し、危険なサイトはすべてブロックされ、ドメインから IP アドレスへの変換速度が向上すると考えられます。

また、ブラウザは SSL 証明書をチェックし、安全なページの隅に検証ステータスを表示します。

インターフェイスもわずかに変更されています。非標準の配色が使用され、ウィンドウ コントロール ボタンがわずかに変更されています。

Comodo Dragon には大きなアップデートがなく、Chrome に比べてブラウザのアップデートが遅れていること（Chromium 19 ベースのバージョンが利用可能になりました）を考慮すると、一般ユーザーの間でこの Web ブラウザの必要性は依然として残っています。質問。

私たちの国では、複数のプログラムが、それを社会的収穫者に変えたいという開発者の願望によって台無しにされました。 一般に、国内のユーザーはソーシャル サイトや機能をすべて詰め込み始めることをあまり好みませんが、RockMelt の場合、開発者は古い熊手を踏むことなくソーシャル ブラウザを作成することに成功したようです。

人気のソーシャルネットワークとの統合 サイトは本当に目立たないように作られています。必要な要素とアイコンがウィンドウ内に適切に配置され、ブラウザ内で不必要なスペースを占有せず、インターフェイスに過負荷がかかることもありません。元の Chrome と比較すると、わずかな変更のみが加えられています。

RockMelt をより簡単に説明するには、インターフェイスを 3 つのコンポーネントに分割することをお勧めします。

の上 トップパネル Facebook プロフィールをすばやく開き、友達リクエストに応答し、ドロップダウン メニューでチャット履歴を開いて、通知を表示することができます。 近く アドレスバー利用可能なボタン クイックアップデートのステータス ソーシャルネットワーク、一度に複数のサイトに送信できます。 ステータスだけでなく、現在のページへのリンクも投稿でき、タイトルやイラスト（選択可能）とともにメッセージ本文に自動的に追加されます。

左側のパネルには、ブラウザのインス​​トール中に選択されたサイトのアイコンが含まれています。 したがって、このパネルは RSS アグリゲータのようなものになりますが、ここではサイトだけでなく、 メールアカウント、Facebook、Twitter、その他のソーシャル ネットワーク。 ネットワーク。 各アイコンには、未読のメッセージ/レター/通知/ニュースの数が表示されます。 いずれかのサイトのアイコンをクリックすると、小さなパネルが開き、そこに少量のテキストとイラストを含むモバイル RSS フィードのスタイルで最新ニュースが表示されます。 パネルは、ブラウザのメイン ウィンドウと重ならないように、画面上のどこにでも移動できます。

右側のパネルには、そのサイトでおなじみのスタイルで Facebook の友達のリストが表示されます。 アイコンをクリックすると、Facebook と同じように、下に小さなチャット ウィンドウが表示されます。

したがって、これらすべてが 追加機能いわゆる静音モードがあるため、必要のないときにユーザーの注意をそらすことはありません。 目覚まし時計のアイコンをクリックすると、メイン ウィンドウからすべてのパネルが消え、Facebook に簡単にアクセスできるユーザーのアバターのみが表示され、RockMelt と Chrome を区別できるようになります。

このブラウザが世界でどれだけ人気があるかを言うのは難しいですが、Facebook での 24 万件の「いいね！」は、このブラウザが愛好家だけが使用しているわけではないことを示しています。

Trident エンジンでなんとか人気を取り戻したブラウザの 1 つですが、WebKit に切り替えた後は第二の風が吹いています。

マックスソンの特徴:

ジェスチャーのサポート。
- CoolNovo の SuperDrag と同様の Super Drag&Drop 機能により、中央のボタンを使用せずにタッチパッドでブラウザを簡単に制御できます。
- AD Hunter広告ブロッカー
- 複数の検索エンジンから同時に検索結果を受信する機能
- リーダー モード。ページから不要なものをすべて削除します。
- 人気のサイトからストリーミングビデオをダウンロードします。
- 組み込みのスクリーンショット機能と結果の画像の基本的な編集
- 内蔵ページトランスレータ
- 同期によるメモ
- ナイトモード - ナイトモード、夜間の読書を快適にするためにデザインテーマを変更します。
- Resource Sniffer - ページ上のメディア ファイルのスキャナーで、見つかったファイルをバッチ モードでダウンロードできます。
- 内蔵 ダウンロードマネージャー一時停止サポート付き
- 自動更新機能 - 指定した時間が経過すると、選択したページを更新します。
- URL の安全性 – すべてのサイトはレンダリング前にフィッシング脅威データベースでチェックされます。

このブラウザの大きな利点は、パフォーマンスが高いことであり、この Web ブラウザでは一部の WebKit 調整が Google よりも早く有効化されるため、多くの場合、元の Chrome よりも優れています。

概して、マクソンが最多タイトル争いで勝利することを妨げているのは、たった 1 つの重大な欠点だけです。 最高のブラウザ WebKitエンジン上で。 Chrome拡張機能をインストールできないことについて話しています。 Maxthon には独自のアドオンがありますが、Chrome ほど数が多くなく、それほど興味深いものでもありません。

ただし、この欠点があっても、Maxthon は WebKit エンジンをベースとした最も興味深い代替ブラウザです。

Trident (IE)、Gecko (Firefox)、WebKit (Chrome) の 3 つのエンジンを同時にサポートするユニークなブラウザーです。

この三位一体にもかかわらず、ブラウザは主に Gecko 用に設計されたようです。 エンジン間の切り替えは手動または手動で行うことができます。 自動モードあらかじめ決められたルールに従って。

Lunascapeは3種類の拡張子をサポートしています。 予想通り、IE と Firefox からのものですが、Chrome アドオンはサポートされていません。代わりに、Lunascape 専用の特別な拡張機能をインストールできます。

カスケード ブラウジング モードを使用すると、1 つのウィンドウで複数のサイトを同時に開き、同時に表示できるようにサイズを変更できます。

従来のほとんどのブラウザとは異なり、2 つの全画面表示モードがあります。 1 つ目は通常のもので、F11 でアクティブ化され、ブックマークとページ自体のみが画面上に残ります。 ラージ ウィンドウ モード (F12) では、すべてのパネルが非表示になりますが、マウスをパネル上に移動すると、画面に再表示されます。

追加機能:

内蔵マウスジェスチャ認識
- タブの数が多い場合は複数行に分けて表示されます
- ブックマークやプラグインを含むすべてのブラウザ設定は、必要に応じて復元できるように定期的にバックアップされます。
- スキンのサポート
- 基本機能 ペアレントコントロール(サイトをブラックリストに追加する可能性)。

検討中のブラウザの中で最も新しいもの (数値 最新バージョン- 1.0.0.1374)。 ベースとなっているバージョンの Chromium はインストールできませんでしたが、おそらく最新の安定バージョンの Chrome よりも新しい、新しいソースが使用されている可能性があります。

このブラウザには、元の Google ブラウザとの違いがちょうど 3 つあります。

内蔵のトレントダウンローダーは必要ありません サードパーティのプログラム(この機能は他の WebKit ブラウザでは利用できません)
- ストリーミング ビデオ ダウンローダー (ほぼすべての Web サイトで動作します)
- Facebook ページへのリンクをすばやく投稿します
Torch が今後どのような方法で開発されるかは不明ですが、次のバージョンの 1 つでは、ファイル ダウンロード アクセラレータが組み込まれることが約束されています。

インストール後、Sleipnir はすべての Chrome 設定を自動的に取得します。ブックマーク、拡張機能、その他のデータは、初回起動時にすぐにブラウザーに表示されます。

このブラウザの主な目標は、PC と携帯電話を最も緊密に統合することです。 この目的のために、特殊なアプリケーションでよく見られる最も人気のある機能が Sleipnir に追加されました。

モバイル ブラウザとデスクトップ ブラウザ間のブックマークは常に同期されます。 PC で開いたサイトはすべて、携帯電話やタブレットで表示できるように「後で読む」セクションに追加できます。 電話番号デスクトップ ブラウザでは、ダイヤル用に送信したり、地図上で住所を開くことができます。

PC と電話をリンクするには、iOS および Android で利用可能な追加のモバイル アプリケーションをインストールする必要があります。 Sleipnir ブラウザ自体は Windows と Mac で利用できます。

Yandex.インターネット
Yandex からの Chrome の最小限の変更。 当然、Yandex がデフォルトの検索エンジンとして使用されます。 さらに、ブラウザには天気予報アプリケーションとページ上の単語翻訳機能がインストールされています。

新しいタブも若干再設計されました。 大きな検索バーと、Yandex の「ビジュアル タブ」拡張機能が表示されます。 Opera のスピード ダイヤル スタイルにはデフォルトで 18 個のビジュアル リンクがあり、その数は 48 個まで増やすことができます。 背景画像ページ上でも変更可能です。

すでに述べたように、Chrome の最新の安定バージョンは現在 21 位ですが、 最新のビルド Yandex.Internet はバージョン 18 のソース コードに基づいています。 ブラウザーには特別な機能がなく、そのすべての機能はいくつかの拡張機能を使用してコピーできることを考慮すると、このアセンブリを使用する特別な意味はありません。

ロシアで Chrome を再考するもう 1 つの試み、今回は Rambler によるものです。 サイトには変更点の説明がなく、ブラウザを使用すると予想通り、アイコンが変わったこととデフォルトの Rambler 検索エンジン以外は何も変更されていないことがわかりました。

Nichrome の最新ビルドは、Google ブラウザのバージョン 19 に基づいています。

かつて、Gecko エンジンをベースにした最も人気のあるブラウザの 1 つ (RockMelt など) は、ソーシャル Web ブラウザとして位置付けられていました。 2010 年の夏に、Gecko は Webkit に置き換えられ、2011 年の春にブラウザは正式に終了しました。

しばらくの間、サイトにはプロジェクトの再開を示すメッセージが表示されていたが、マーク・トウェインの有名な言葉「私の死の噂は非常に誇張されている」を除けば、ページ上では何も起こっていない。

結果

この資料を要約するのは非常に簡単であることがわかりました。 ユーザーの注目に値するブラウザは 3 つだけです。 これらは Chrome、Maxthon、CoolNovo であり、おそらくこの順序です。

Chrome の主な利点は、6 週間ごとに安定して更新されることです。

Maxthon の利点は、興味深い追加機能と高速性です。 欠点 - Chrome 拡張機能をインストールできない。

CoolNovo の利点 - 追加機能 (拡張機能で置き換えられない、または時間がかかる多くの小さな機能を含む) および親戚のサポート Chrome拡張機能。 短所 - ブラウザがめったに更新されなくなりました。

Android と iPhone - ブラウザ戦争

パート 1. WebKit が役に立ちます

ネットワーク状態の監視を担うブラウザアプリケーションの開発

コンテンツシリーズ:

iPhone と Android プラットフォームには合計 100,000 を超えるアプリケーションがあり、さまざまなソースからダウンロードできます。 これは「ネイティブ」アプリケーションを指します。 適切な SDK を使用して開発および組み立てられ、モバイル デバイスにインストールされるアプリケーション。 このような「ネイティブ」アプリケーションを使用すると、サポートを含むモバイル デバイスの技術的機能を効果的に実装できます。 ワイヤレスネットワーク、Bluetooth とデータ ストレージ、加速度計またはコンパス機能、およびモバイル デバイスをユーザーにとって非常に魅力的なものにするその他の技術的な驚異と革新。 iPhone および Android プラットフォームの「ネイティブ」アプリケーションの人気は非常に高いですが、これに加えて、モバイル デバイスでは次のような機能が提供されます。 十分な機会 Web アプリケーションの開発では、モバイル テクノロジは子供の頃からずっと昔に普及し、ある程度の成熟度に達しました。 モバイルインターネット.

この記事は、iPhone および Android 用のブラウザ アプリの開発に関する 2 部構成のシリーズの第 1 部です。 このシリーズの目的は、独自のモバイル Web アプリケーションを作成する基本原則を読者に紹介することです。 モバイル アプリケーションの機能は、モバイル デバイス上で Web サイトを実行することに限定されません。 モバイル アプリケーションの開発で使用される基本的なテクノロジとアプローチを見ていきます。これにより、ソフトウェア開発のこのセクションを別の独立した分野に区別できるようになります。

Web プラットフォームの人気は、Web プラットフォームを使用することで、これまで開発者やシステム管理者の悩みの種であった多くの問題を解決できるという事実によって説明されています。 その中で：

• インストールの問題: Web アプリケーションのインストールは手間がかかりません。Web アプリケーションをサーバーにインストールまたはコピーし、ブラウザーで指す URL をクライアントに伝えるだけです。
• スケーリングの問題: Web アプリケーションは、高性能データセンター内のサーバーのプールに合わせて簡単に拡張でき、アプリケーションにサービスを提供するために既製の Web サイト管理ツールが使用されます。
• データのアーカイブとリカバリの問題: Web アプリケーションは一元化されたデータ ストレージを使用するため、障害が発生した場合のリカバリ タスクが簡素化されます。
• 質問 ユーザーインターフェース: HTML、カスケード スタイル シート (CSS)、JavaScript、および グラフィック画像ネイティブ SDK を使用して開発されたインターフェイスよりも機能と外観が大幅に優れた多機能ユーザー インターフェイスを作成できます。 後者は原則としてゲーム用途での本格的な臨場感効果を提供することができず、対話型情報端末に必要な機能を保証するものではありません。
• 使いやすさ: ほとんどのアプリケーションは、日常的な操作を簡単に実行できる、シンプルで使いやすいユーザー インターフェイス要素を必要とします。

インターネット アプリケーション配布モデルの最も魅力的な側面は、ソフトウェアを一種のサブスクリプション サービスにすることができ、ソフトウェアを配信する相互に有益な方法となることです。 "どうやって？" –あなたは尋ねます。 この問題をさらに詳しく見てみましょう。

Web ベースのソフトウェア配布モデルにより、顧客は最小限のリスクと最小限の価格で、購入前に製品を試すことができます。 もし 体験版クライアントがそれを気に入った場合、その後の使用のために彼に必要なすべてが必要になります ソフトウェア製品- これは購入代金の支払いです クレジットカード(またはPayPal経由)。 さらに、SaaS (Software as a Service) モデルは、多額の初期費用なしでソフトウェアを購入できる便利でコスト効率の高い方法をユーザーに提供し、遠い将来ではなく、使用後最初の 1 か月以内に確実に投資収益率を得ることができます。

実際には、Web ブラウザのサポートは制限されています モバイルデバイスはほとんど不在でした。 WebKit と呼ばれるテクノロジーの出現により、状況は劇的に変化しました。WebKit は、iPhone のおかげでモバイル デバイスの分野で確実にその地位を確立しました。

わずか数年で、iPhone プラットフォームは世界でナンバーワンの Web クライアントになりました。 なぜ？ WebKit と信頼性の高いインターネット接続を組み合わせることで、モバイル デバイス上で Web サービスを他のデバイスよりもはるかに効率的に使用できるようになったからです。 最新のブラウザ。 モバイルデバイス市場の他のプレーヤーも注目を集めました 新しい技術、そして現在、市場全体は、WebKit を使用している企業、WebKit を使用しようとしている企業、WebKit を使用しない言い訳を作る企業に分けることができます。

では、WebKit とは何でしょうか?

WebKit と HTML5

WebKit は、iPhone プラットフォーム上の Mobile Safari ブラウザと Android プラットフォーム上のブラウザの両方をサポートするために使用されるブラウザ エンジンです。 もちろん、WebKit は他のモバイル デバイスでも使用されていますが、この記事では iPhone と Android プラットフォームに限定して検討します。

WebKit は次のようなプロジェクトです。 オープンソース、K デスクトップ環境 (KDE) の開発に由来します。 モバイル デバイス用の最新の Web アプリケーションは、WebKit プロジェクトによって誕生しました。 モバイル デバイスの技術的およびデザイン的特性は確かに重要な役割を果たしますが、モバイル ユーザーは主にコンテンツに興味を持っています。 モバイル デバイスがインターネット コンテンツのごく一部にしかアクセスできない場合、最も人気のあるデバイスのトップ リストに入る可能性は低くなります。

私たちのほとんどは、充実した生活を送ることを好みます。家に座っているときにラップトップで Web サイトを開いた場合、電車に座っているときにそのサイトを開いたときも同じコンテンツが表示されることを期待しています。 モバイル アプリケーションの主な問題はコンテンツです。 どこにいても、何をしていても、興味のあるデータにアクセスする必要があります。 WebKit テクノロジーは、iPhone および Android プラットフォーム上で豊富なコンテンツを提供します。

WebKit は、デスクトップ バージョンであるか、iPhone や Android のブラウザ エンジンであるかに関係なく、Mac OS X プラットフォームの主要なブラウザである Safari ブラウザなどのデスクトップ コンピュータでも使用されることに注意してください。 HTML と CSS をサポートする最先端のテクノロジー。 実際、WebKit は、HTML5 仕様で定義されている多数のプロパティなど、他のエンジンのブラウザではまだレンダリングされていない CSS スタイルをサポートしています。

HTML5 は暫定的なものです。 技術仕様、SQL サポート、移動、変換などを備えたクライアント側のデータ ウェアハウスなど、ブラウザーの使用に基づくテクノロジを定義します。 HTML5 仕様はまだ開発中ですが、基本原則が明確に定義され、ほとんどのプラットフォームのブラウザーに実装されれば、Web アプリケーションの地味な始まりは過去のものになるでしょう。 Web アプリケーション開発は、ソフトウェア開発業界の重要な部分を占めることになるでしょう。デスクトップ ブラウザ用のアプリケーションだけでなく、モバイル ブラウザ用のアプリケーションについても話しています。 モバイル アプリケーションは、Web アプリケーション市場の副産物から主力製品に変わります。

モバイル Web アプリケーション開発の設計機能

Web 開発テクノロジーを習得しようと決めた場合、自由に使えるツールの選択肢は非常に限られています。 まず、アプリケーションは HTML、CSS、JavaScript コードを含むファイルとしてサーバー上に直接作成できます。 この場合、HTML コンテンツは静的 HTML ファイルの形式で提供することも、サーバー側で機能するさまざまなテクノロジ (PHP、ASP.NET、Java サーブレットなど) を使用して動的に生成することもできます。いずれにせよ、この記事で議論されている問題に関して言えば、すべては次のとおりです。 HTMLコードここで私たちにとって最も重要な点は、WebKit テクノロジーにより、ブラウザーがモバイル デバイス上で HTML をレンダリングできるようになることです。

モバイル デバイス (iPhone または Android) で Web アプリケーションを実行するには、ユーザーはブラウザを起動し、対応するサービスの URL (例: http://yourcompanyname.com/applicationurl) を入力する必要があります。

同時に、提案されるモバイル Web アプリケーションの範囲は、標準的な Web サイトから、特定のモバイル プラットフォーム専用に開発されたモバイル Web アプリケーションまで、非常に多岐にわたります。

標準サイトの表示

WebKit エンジンを iPhone および Android プラットフォームの直感的で使いやすいユーザー インターフェイスと組み合わせると、モバイル デバイスでほぼすべての Web サイトを表示できるようになります。 コンテンツの断片がランダムに転送されたり、まったく表示されなかったりした前世代のモバイル ブラウザーとは異なり、Web ページは非常に正確に表示されます。 WebKit 対応のブラウザにページが読み込まれると、ページのコンテンツが拡大縮小する傾向があります。 この場合、図 1 に示すように、ページ全体が画面に収まるように縮尺が選択されます (図 1 に示すように、大幅に縮小されて読みにくくなる場合もあります)。ただし、ページはスクロール、拡大、移動できるため、次のページに簡単にアクセスできます。すべてのコンテンツ要素。 デフォルトでは、ブラウザは幅 980 ピクセルのウィンドウを使用します。

ブラウザ ウィンドウに Web ページを完全に表示すること自体は、前世代のブラウザを使用した経験に比べて大幅な進歩ですが、最新のブラウザの機能は モバイルテクノロジーこれに限定されません。

モバイルデバイスを念頭に置いて設計された Web ページ

Web ページに通常の Web ユーザーだけでなくモバイル ユーザーもアクセスできるようにしたい場合は、モバイル Web アプリケーションを最適化するために考慮すべきオプションがさらにいくつかあります。

WebKit を使用すると、Web ページをモバイル デバイスの画面に正しく表示できますが、ラップトップやデスクトップ コンピュータなどのマウス ベースのデバイスと、次のようなタッチ デバイスとの間には特定の違いがあります。 iPhone・スマートフォンまたはアンドロイド。 タッチ デバイスは、「クリック」領域の物理的寸法、要素上にカーソルを置く機能の欠如、およびイベントのシーケンスの違いにおいて異なります。 したがって、通常のユーザーとモバイル ユーザーの両方にとって便利な Web サイトを作成したい場合は、モバイル デバイスの次の機能を考慮する必要があります。

• iPhone および Android ブラウザは、Web ページ全体をかなり読みやすい形式でレンダリングできます。これらのブラウザのレンダリング品質は、標準のモバイル ブラウザよりもはるかに高いため、サイトのデザインを急いで簡素化する必要はありません。
• 指先のサイズは、マウス ポインターのサイズよりも大幅に大きくなります。 サイト ナビゲーション要素を開発するときは、この要素を考慮してください。 リンクを互いに近づけすぎないでください。そうしないと、ユーザーは 1 つのリンクをクリックすると、次のリンクに移動することができなくなります。
• ホバー要素はモバイル デバイスでは機能しません。 ユーザーは、マウス カーソルと同じように、要素の上に指を「ポイント」することはできません。
• マウスボタンの長押しやマウスのドラッグなどにより決定されるイベント タッチスクリーン別の方法で実装されました。 これらのイベントの一部はモバイル デバイスでも機能する場合がありますが、一般に、モバイル ブラウザとデスクトップ ブラウザが同じ一連のアクションを実行することを期待すべきではありません。

これらの側面の詳細な説明は、記事「 iPhone の動作"(セクションを参照)。 この記事では、WebKit の欠点ではなく、利点についてのみ検討します。

一番考えてみましょう 明らかな問題 iPhone または Android ユーザーが Web サイトにアクセスするときに直面する問題、つまり画面サイズの制限。 実際、最新のモバイル デバイスの画面サイズは、ユーザーが Web コンテンツを横長構成で表示することを好む場合、320x480 または 480x320 です。 図 1 からわかるように、WebKit は標準のデスクトップ コンピューター用に設計された Web ページを正しく表示できます。 ただし、Web ページを拡大縮小すると、テキストが小さすぎて読めなくなる可能性があるため、ユーザーはテキストを読む前にスクロール、パン、ズームする必要があります。 この制限にどう対処すればよいでしょうか?

モバイル ブラウザ ウィンドウとデスクトップ ブラウザ ウィンドウで同等に表示されるページを作成する最も簡単な方法は、特別なメタ タグを使用することです。 ビューポート.

メタタグは、HTML ドキュメントの先頭に配置される HTML タグです。 viewport タグを使用する最も簡単な例は次のようになります。

このメタ タグを HTML ページに追加すると、モバイル ブラウザ ウィンドウでの表示が最適な方法で拡大縮小されます (図 2 を参照)。 ビューポートをサポートしていないブラウザは、このタグを単に無視します。

特定のズーム オプションを定義するには、viewport:meta タグの content 属性の正確な値を指定します。 初期スケールパラメータの値を変更することで、画像を縮小または拡大できます。 iPhoneの場合と アンドロイドの方が良いよ 1.0 から 1.3 までの値を使用します。 ビューポート メタ タグは、最小および最大ズームもサポートしているため、ページの読み込み時にユーザーがページのズームを変更できる機能を制限できます。

iPhone のデザイン特性、特に 320x480 の画面サイズは登場以来ほとんど変わっていませんが、Android プラットフォーム上のモバイル デバイスがリリースされているため、Android プラットフォーム上のデバイスのパラメータはかなり広い範囲にあります。 さまざまなメーカー幅広いユーザー グループを対象としています。 したがって、Web アプリケーションをモバイル ユーザーに人気のあるものにしたい場合は、モバイル デバイス上のデバイスの設計機能だけでなく、画面サイズと解像度の違いを考慮する必要があります。 Androidベース.

経験によれば、さまざまな Android モバイル デバイス間に存在するデザインの違いに加えて、 ソフトウェア Android は、モバイル デバイスのブラウザのプロパティに応じて、読み込まれた Web ページの設定を試みます。 Android プラットフォームには、安定性に加えて、絶えず変化する一連の機能が備わっています。 設定 特定のデバイス Android ベースの設定は、SDK のバージョンやデバイスのメーカーによっては、開発環境の設定とは異なる可能性があります。 図 4 は、V1.6 Android エミュレータのブラウザ設定画面を示しています。 画面設定により、ユーザーは画面上の画像スケーリングのレベル (遠、近、中) を決定したり、自動ページ スケーリング モードを選択したりすることができます。

モバイル デバイスの世界では常に変化するため、モバイル ソフトウェア市場の発展と更新を考慮する必要があります。 たとえば、Sprint Hero ブラウザ設定には、Web ページを読み込むときに使用される標準設定とはまったく異なる一連のオプションが含まれています。 Hero ブラウザは、HTC によって行われた多くの変更を使用して Android V1.5 プラットフォーム上に構築されています。 幸いなことに、ビューポート メタ タグを使用すると、ヒーロー固有の設定が無視されます。

これまでのところ、大幅に縮小されて読みにくい形式ではあるものの、WebKit が Web ページを非常にうまく読み込んでいることを見てきました。 次に、ビューポート メタ タグを使用して、モバイル デバイス画面上でのページの表示方法の制御を拡張しました。 表示されるページが非常に読みやすく、ナビゲートしやすくなりました。 しかし、これだけでは、ページを Web アプリケーションのように見せ、機能させるにはまだ十分ではありません。

モバイルデバイス向けに作られた

次に、モバイル閲覧者を対象とした Web ページのデザイン機能について考えてみましょう。 具体的な例として、登録ページを考えてみましょう。 Gメールサービス Googleメール。

デスクトップのブラウザ ウィンドウではページは次のように表示されます。

デスクトップのブラウザ ウィンドウでは、情報コンテンツが左側に表示され、登録ウィンドウ自体は右側のパネルに表示されます。 モバイル ブラウザ ウィンドウでは、同じページでもまったく異なる外観になります。

図 6 に示すページは、明らかにモバイル ユーザー向けに設計されています。 画面には、ユーザーが必要とするページ要素のみが表示されます。 さらなる仕事– 追加のスクロール、パン、ズームは必要ありません。

次にビューポートを見てみましょう 電子メール Gmail のモバイル版。 アプリケーションで利用できる画面スペースは非常に限られているため、メッセージ ビューアには追加のボタンとナビゲーション要素があります。 この場合、表示されるナビゲーション要素は、メッセージを表示するためのウィンドウと重なって表示されます。 また、できるだけ多くのフレームやスクロール div を使用しないでください。 モバイル版 Gmail では、ユーザーがページのスクロールを終了するとすぐに表示されるフライアウト メニューを使用することで、この問題を解決しています。 ポップアップ メニューには、アーカイブ、削除、その他の 3 つのボタンが含まれています。 [詳細] ボタンをクリックすると、追加のメニュー項目が表示されます (図 7 を参照)。

これはまさにモバイルデバイス向けに設計されたアプリケーションです。

意図的にデザインを貧弱にし、iPhone および Android プラットフォーム用の多機能ブラウザを開発したモバイル ユーザーのエクスペリエンスを低下させたくないということを心に留めておく必要があります。 この観点から、Gmail ページの下部に表示される要素に注目すると便利です (図 8 を参照)。

ユーザーがデスクトップ バージョンの拡張機能を希望する場合は、ページの適切なバージョンをダウンロードするオプションを提供します。

次に、Web テクノロジを使用しているが、ネイティブ モバイル アプリケーションのように見えるアプリケーションを作成したい場合を考えてみましょう。

プラットフォーム固有のコンテンツ

次のステップは、特定のモバイル プラットフォームに固有のコンテンツを開発することです。 これにより、ページの形式とインターフェイスが定義され、結果のページが標準の公開 Web サイトではなく、特定のプラットフォームのネイティブ アプリケーションのように見えるようになります。 「ネイティブ」アプリケーションとは何を意味しますか?

特定のプラットフォームのネイティブ アプリケーションにできるだけ似た Web アプリケーションを作成する方法についての議論を掘り下げる前に、iPhone と Android ブラウザの共通機能については脇に置いて、これらのプラットフォーム間に存在する視覚的な違いについて簡単に触れてみましょう。 。

iPhone アプリケーションには、独自の外観とインターフェイスがあります。 誰かに写真を見せてください iPhoneの画面そして、この人が先日文字通り月から落ちたのでない限り、ほぼ間違いなくすぐにそれは iPhone だと言うでしょう。 同じ人に Android モバイル デバイスのスクリーンショットを見せても、答えはそれほど明確ではなくなります。 理由は何ですか? 考えられる説明はいくつかあります。 まず、iPhone は Android ベースのデバイスよりもはるかに早く市場に登場し、膨大な数のファンを獲得することができました。 V1 iPhone の限られた機能に大金を支払おうと列に並んでいる人々のことを考えてみてください。 iPhone が好きか嫌いかに関係なく、この Apple 製品は現在市場のリーダーです。 アンドロイドはどうですか？

Android プラットフォームは比較的新しい製品であり、主にオープン コミュニティ向けに設計されているため、多くの点で iPhone の対極として機能します。 Android プラットフォームは最も多くの場所で使用されています。 さまざまなデバイス(電話やその他の家電製品)。 議論を簡単にするために、この記事では以下に限定します。 Androidを使用して携帯電話で。

やがて、世界中の Android デバイスの数が iPhone の数を超えるでしょう。 Android デバイスはさまざまな企業によって製造されており、さまざまなデータ ネットワークでサポートされるためです。 モバイル市場には非常に多くのプレイヤーが存在するため、 Android デバイス、もちろん、デバイスの外観とパラメータに基づいて、市場がある程度細分化されることを期待する必要があります。 この傾向は、HTC の SenseUI インターフェイスで見ることができます。 この魅力的なルック アンド フィールは、基礎となる Android SDK ではサポートされておらず、他の Android デバイスと互換性がありません。 Motorola、Google、Verizon は協力して、新しい Android ベースの DROID デバイスを開発しました。 これはプラットフォーム上の最初の商用製品です Androidのバージョン 2.0.

さまざまな Android システムと、一貫した iPhone のルック アンド フィールを比較してください。 iPhone は Apple の特に貴重な財産です。 外観 iPhoneアプリケーション時間の経過とともにわずかに変化する可能性がありますが、これらの小さな変化は、以前と比べられる可能性は低いです。 異なるバージョン Androidシステム、その数は、プラットフォームが開発の初期段階にある現在でも非常に多くなっています。

では、アプリケーションの外観とインターフェイスを「ネイティブ」プログラムにできるだけ近づけるには何をする必要があるのでしょうか?

Web 2.0 の出現前にこの課題に直面していたら、それは確かに深刻な問題になっていたでしょう。 複数のクライアント ブラウザー (モバイルとデスクトップ) をサポートする初期の試みは、次のようないくつかのアプローチに依存していました。

• 完全並列サイトの開発
• userAgent パラメータに応じた動的コンテンツ生成
• 特定のデバイスごとにコンテンツを変換できるプロキシ サーバーを使用します。 このテクノロジーは、RIM によって、へのアクセスを提供するためにうまく使用されています。 電子メールクライアントのモバイルデバイスから。

このようなアプローチは、資金が豊富な大規模なチームによって開発が実行される場合には、十分に受け入れられる可能性があります。 残りの世界は何をすべきでしょうか？ 誰もがそのような戦略を実行するための十分な資金力、高度な資格を持つ専門家、無制限の時間を持っているわけではありません。 さらに、すでに述べたように、前世代のブラウザのモバイル インターネットは使いやすいとは言えず、人気があるとは言えないため、いずれにせよ、時代遅れの方法やアプローチにこだわるべきではありません。

幸いなことに、その必要はありません。 WebKit と CSS の時代では、スタイル シートとメディア クエリを使用することで、さまざまなモバイル デバイスの外観とインターフェイスの違いを克服でき、特定の種類のデバイスに応じて異なるスタイルを使用できるようになります。 メディア クエリ テクノロジを使用すると、クライアントに関する情報を取得できます。 従来、ブラウザはサーバーに userAgent 値を送信します。これにより、サーバーは特定のブラウザを識別し、クライアントに送信するコンテンツを決定できます。 メディア クエリを使用すると、ブラウザはその機能に基づいてページのスタイルを選択します。 次の例は、スマートフォン用に設計されたスタイル シートの選択を示しています。 そして、このクエリはデスクトップ スタイル シートを定義します。

Internet Explorer V6

この記事の執筆時点では、Internet Explorer V6 はブラウザ市場全体の約 20 ～ 30% を占めていましたが、IE V6 の機能についてはこの記事の範囲を超えています。

もっと 詳細情報メディア クエリに関する情報はドラフト仕様で見つけることができます (セクションを参照)。

メディア クエリを使用して、ネットワーク サーバーのステータスを表示するアプリケーションを開発する例を見てみましょう。

ネットワーク監視プログラム

このアプリケーションの目的は、複数のサーバーの動作を監視することです。 独立系ソフトウェア開発者は、多くの場合、複数のサーバー上で複数のアプリケーションをサポートする必要があります。 ソフトウェア開発に長年携わってきた人であれば、おそらくすでにさまざまな種類のサーバーやさまざまな種類のアプリケーションに出会ったことがあるでしょう。 これは、単一のツールを使用して必要なすべてのアプリケーションのパフォーマンスを追跡できない可能性が非常に高いことを意味します。 この場合、モバイル ネットワーク監視アプリケーション (netmon) を使用するのが合理的です。 このアプリケーションは必要な機能をすべて提供すると同時に、柔軟性とモバイル デバイスからのアクセスが容易です。

netmon アプリケーションには、監視する必要があるサーバーのリストが含まれています。 主要業績評価指標 (KPI) はサーバーごとに収集されます。 主要業績評価指標は、MBA 学生がビジネスの現状を評価するために長年使用してきた主要なツールです。 Web アプリケーション ホスティングの観点からは、次の指標を KPI として使用できます。

• 過去の期間のトランザクション数
  • 注文
  • カタログ請求
  • メール
  • ページビュー数
• 最後のトランザクションからの経過時間
  • 注文
  • 電子データ交換
  • お取引先様からのメッセージ
  • ベンダーから FTP 経由でファイルをアップロードする
• データベースは利用可能ですか?
• 前回のバックアップ日
• 平均注文金額 (ドル)
• ディスクの空き容量
• 過去 1 時間、1 日、1 か月の帯域幅

上記のメトリクスおよびその他の同様の運用パラメータを使用すると、特定のシステムまたはアプリケーションの健全性を評価できます。 たとえば、ホリデーシーズン中に、当社の一部のサイトで行われた注文数を調査します。 データが時間ごとの注文数の安定した増加を示していない場合は、状況をより詳細に分析します。

各アプリケーションには独自の要件とリソースがあるため、netmon は各アプリケーションのニーズに対応できる十分な柔軟性を備えている必要があります。 このレベルの柔軟性を提供するために、各システムの状態パラメーターを考慮した最も一般的なデータ構造を定義することから始めます。 パート 2 では、このデータがどこから取得され、どのように更新されるかを詳しく見ていきます。 現時点では、次の情報に限定します。

• サイト名
• サイトURL（ホームページ）
• アップデートを取得するための URL
• ステータス: OK かどうか
• 概要: OK であるか、そのサーバーの最も深刻な問題を示すテキスト文字列を含むサーバー ステータスの説明
• 要素: これは、対応するサイトの現在の KPI 値を渡すために必要な名前と値のペアのセットです。

私たちのアプリケーションは、結果として得られるパフォーマンス指標をナビゲートしやすい方法で表示し、 CSS機能、jQuery および WebKit を使用して、問題領域にユーザーの注意を引きつけます。 すでに述べたように、このアプリケーション開発の主な目標は、iPhone、Android プラットフォーム、デスクトップ コンピュータの Safari ブラウザでアプリケーションを実行できるようにすることです。

ネットワーク監視アプリケーションの開発

最新の Web ページは、ページの組織構造とコンテンツを定義する宣言形式で作成する必要があります。 ページの配置と書式設定はカスケード テーブルを使用して行われます CSS スタイルそしてほとんどの場合、JavaScript を使用します。 実際、JavaScript ライブラリは非常に人気があり、今日では例外ではなく一般的に使用されています。 この記事で説明するアプリケーションでは、人気のある JavaScript ライブラリ jQuery を使用します。 私たちのアプリケーションは、iPhone、Android、およびデスクトップのプラットフォームで実行されます。 同じ HTML コードが使用され、必要な相違点はスタイル シートで実装されます。 ここで注意しなければならないのは、アプリケーションの魅力的な外観をデザインするために意識的に大きな努力を払っていないということです。 さらに、読者の注意をスタイルシートの構成にさらに引き付けるために、互いに調和しない派手な色が背景として意図的に選択されています。 パート 2 では、アプリケーションの外観を少し改善しますが、現時点では HTML コードはリスト 1 のようになります。

リスト 1. アプリケーション HTML コード if (navigator.userAgent.indexOf("iPhone") != -1) ( document.write(""); ) else if (navigator.userAgent.indexOf("Android") != -1 ) ( document.write(""); ) else ( document.write(""); ) function setupTestData() ( try ( netmon.initialize(); if (netmon.resources.length > 0) ( jQuery.each( netmon .resources,function (index, value) ( $("#mainContent").append(netmon.render(index,value)); )); click (function() ( $(this ).find(".serveritems").toggle();)); $(".serveritems").hide(); ) catch (e) (alert(e); ) ) 私のネットワーク リソースサーバー 私のユーザーエージェント

提案された HTML コードをざっと見てみると、次の主な機能がわかります。

• コードでは 2 つの外部を使用します。 JavaScriptファイル: 1 つの jQuery ライブラリ ファイルと、アプリケーション用の 1 つのサポート ファイル。
• このコードは、ビューポート メタ タグを使用して、表示されるコンテンツを拡大縮小します。
• メインのスタイル シートは netmon.css ファイルによって定義されます。
• userAgent パラメータは、補助スタイル シートを定義するために使用されます。 その値に応じて、スタイル シートは iPhone、Android、またはデスクトップ ブラウザーにロードされます。
• ページ読み込みプロセスでは、jQuery と netmon.js ファイルで定義されたヘルパー関数を使用してデータを表示します。
• メイン ページのコードでは、いくつかの div タグが使用されています。
• 最後に、コードには userAgent 文字列を表示するページへのリンクが含まれています。 このリンクはアプリケーションの動作とは関係がなく、デモンストレーションのみを目的として使用されます。

アプリケーションの基本操作を実際に定義するスタイル シートと netmon.js ファイルの詳細に入る前に、アプリケーションの現在の状態を見てみましょう。 3 つの異なるスタイル シートを使用していることにもう一度注意してください。サポートされている 3 つのプラットフォームごとに 1 つずつです。 アプリケーション開発プロセスをより視覚的にするために、各テーブルは独自の背景色を定義します。 図 9 では、ページがデスクトップ Safari ブラウザで開かれており、背景が青色です。

図 11 は、iPhone ブラウザ ウィンドウ内のアプリケーションの外観を示しています (背景色は緑色)。

netmon.js ファイルに保存されているメインのスタイル シートをリスト 2 に示します。

リスト 2. メイン スタイル シート body ( color: #888888; font-family: Helvetica; font-size:14px; margin: 0px; padding: 0; ) .details ( margin: 0px; padding: 0px; background-color:white) ; ボーダー: ソリッド; ボーダー幅: 1px; -webkit-border-top-right-radius: 8px; : #ff0000; ) .odd (背景画像: -webkit-gradient(linear, 左上, 右下,from(#ccc) ,to(#999)); .even (background-image: -webkit-gradient(リニア、左上、右下、fr​​om(#999) 、to(#ccc)); ) .serverentry a ( float: right; color: #ffffff; ) .serveritems( color: #000; ) #header h1 ( margin : 0; パディング: 0; テキスト整列: 色: #000;

プラットフォームごとに異なるスタイル シートを使用すると、次のタスクを実行できます。

ページの配色を変更します。 これにより、第一に、スタイル シートの役割を明確に示すことができ、第二に、userAgent パラメータの値に応じて目的のスタイル シートを選択することがいかに簡単であるかを示すことができます。

モバイルとデスクトップのプラットフォームに異なるフォント サイズを設定します。

関連する WebKit 機能を確認してください。 これは、アプリケーションが Firefox などの WebKit サポートのないブラウザで実行されている場合に大きな違いを生みます。

リスト 3 は、iphone.css ファイルのコードを示しています。

リスト 3. ファイル iphone.css body (background-color: #00ff00; ) .serverentry ( -webkit-border-top-left-radius: 8px; -webkit-border-top-right-radius: 8px; -webkit-border -左下の半径: 8px; -webkit-border-右下の半径: 8px; サイズ: 1.5em)

ご覧のとおり、body タグの背景色は 緑(#00ff00)、モバイル端末の画面で読みやすいようにフォントサイズを調整しています。 最後に、netmon.js ファイルを見てみましょう。このファイルは、サーバーのリストと、各サーバーのデータを出力する関数 (リスト 4 で使用) を定義します。 簡潔にするためにファイル コードの一部は省略されています。全文はセクション) で参照できます。

リスト 4. Netmon.js ファイル var netmon = ( 初期化: function () ( )、リソース: [ ( name: "msiservices.com"、homeurl: "http://msiservices.com"、pingurl: "http:// msiservices.com/netmon.php"、ステータス: "OK"、概要: "OK"、項目: [ (名前: "DiskSpace"、値: "22.13 GB")、(名前: "Database Up?"、値: "はい") ] )、(名前: "サーバー 2"、ホーム URL: "http://someurl"、pingURL: "http://someurl/netmon.jsp"、ステータス: "OK"、概要: "OK" , items: [ (name: "DiskSpace", value: "100.8 GB"), (name: "Database Up?", value: "Yes") ] ), // 簡潔にするために追加のエントリは切り取られています ], render: function( Index,itm) (try ( var ret = "; ret += ""; ret += "" + itm.name + " 表示
"; if (itm.status != "OK") ( ret += "-" + itm.summary + "
"; ) ret += ""; jQuery.each(itm.items,function (j,itemdetail) ( ret += ">" + itemdetail.name + "= + itemdetail.value + "
"; )); ret += ""; ret += ""; return ret; ) catch (e) ( return "アイテムのレンダリングエラー [" + itm.name + "] " + e + ""; ) ) ;

CSS ファイルのクラス定義からわかるように、いずれかのサーバーのステータス バーに問題がない場合は、対応するサーバー エントリが赤色で表示されます。 さらに、サーバーのステータスをチェックして問題があることが判明した場合 (ステータスが OK ではない場合)、追加で次のメッセージが表示されます。 簡単な説明問題。 図 9 ～ 11 は、サーバー 4 に十分な空きがないことを示しています。 ディスクスペース。 このサーバーの行をクリックすると、問題に関する詳細メッセージが画面に表示されます (図 12 を参照)。

サーバー名の右側にある [表示] リンクをクリックすると、そのサーバーのホームページが開きます。 このようなリンクがあると、2 つの理由で非常に便利です。1 つは、各サーバーの URL を記憶するという不快な必要性から解放されること、そして 2 つ目は、この URL をキーボードから入力するというさらに不快な必要性から解放されることです。あなたのモバイルデバイス（最も便利なデバイスであっても）。

したがって、モバイル デバイス上で netmon を正常に実行できれば、サーバーを保守するタスクによって問題が発生することはありません。

結論

この記事では、WebKit テクノロジーを使用して iPhone および Android 用の Web アプリケーションを開発する原則を紹介します。 パート 2 では、Ajax 呼び出しを使用したデータ更新機能を追加することで、アプリケーションの機能を拡張します。

• 翻訳

私たちの多くの開発者にとって、WebKit はブラック ボックスです。 HTML、CSS、JS、そして大量の画像をそこに投げ込むと、WebKit がどういうわけか...魔法のように、見た目も動作も良好な Web ページを提供します。
しかし、実際にはどうやって 私の同僚のイリヤ・グリゴリックは言います :

Web キットはブラックボックスではありません。 こちらは白い箱です。 そして白だけでなく、オープンボックスもあります。
そこで、いくつかのことを理解してみましょう。

• WebKitとは何ですか?
• WebKit ではないものは何ですか?
• WebKit ブラウザは WebKit をどのように使用しますか?
• 多くの WebKit が同じではないのはなぜですか?

現在、特に Opera が WebKit に切り替えたというニュースの後、私たちの周りには多くの WebKit ブラウザがあり、何がそれらを結び付け、どこに独自の道を歩むのかを言うのは非常に困難です。 以下では、この問題について少しでも明らかにしていきたいと思います。 その結果、ブラウザーの違いをより適切に特定し、バグを適切なトラッカーに送信し、クロスブラウザー開発をより効率的に実行できるようになります。 標準 Web ブラウザーのコンポーネント 最新のブラウザーのコンポーネントをいくつか挙げてみましょう。

• 解析 (HTML、XML、CSS、JavaScript の解析)
• レイアウト
• テキストとグラフィックのレンダリング
• 画像デコード
• GPUとの対話
• ネットワークアクセス
• ハードウェアアクセラレーション

すべての WebKit ブラウザに共通するものはどれですか? ほとんど最初の 2 つだけです。

WebKit の各「ポート」は、残りのコンポーネントを異なる方法で実装します。 これが何を意味するのか見てみましょう。

WebKitポート

WebKit には多くの「ポート」があり、私は WebKit ハッカーであり技術である Ariya Hidayat に提供しています。 Sencha のディレクターには、これについて話す権利があります。

WebKit の概念と最もよく関連付けられるのは、通常、Mac OS X 上で動作する Apple バージョンの WebKit (最初のオリジナルの WebKit ライブラリ) です。ご想像のとおり、さまざまなインターフェイスは、主にさまざまなネイティブ Mac OS X ライブラリを使用して実装されています。たとえば、特定の輪郭半径を持つ色付きのフラット ボタンを定義すると、WebKit はこのボタンをどこにどのように描画するかを認識しますが、ボタンの最終的なレンダリングは (ユーザーのモニター上のピクセルとして) CoreGraphics で行われます。 。

上で述べたように、使用される CoreGraphics は各 WebKit ポートに固有です。 たとえば、Chrome for Mac は Skia を使用します。

ある時点で、WebKit はデスクトップとモバイルの両方のさまざまなプラットフォームに「移植」されました。 このバリエーションは通常「WebKit ポート」と呼ばれます。 Safari Windows の場合、Apple は独自に WebKit を「移植」し、その (限定された実装) CoreFoundation ライブラリを使用して Windows 上で実行できるようにしました。

...Windows 上の Safari は廃止されたという事実にもかかわらず、これ以外にも多くの「ポート」がありました (完全なリストを参照)。 Google は Chromium ポートを作成し、引き続きサポートしています。 Gtk+ をベースにした WebKitGtk もあります。 Nokia (そして現在は Nokia を買収した Trolltech) は、QtWebKit モジュールとして人気のある WebKit Qt ポートをサポートしています。
一部の WebKit ポート

• サファリ
  - Safari for OS X と Safari for Windows は 2 つの異なるポートです
  - WebKit ナイトリー ビルドは、Safari で使用される Mac ソース コード「ポート」のビルドであり、より新しいもののみです
• モバイルサファリ
  - プライベートブランチで開発されましたが、後にオープンされました。
  - Chrome for iOS (Apple の WebView を使用します。違いについては後で詳しく説明します)
• クロム（クロム）
  - Android 用 Chrome (Chromium の「ポート」を直接使用)
  - Chromium はブラウザの基礎でもあります: Yandex、Sogou、そして間もなく Opera になります。
• Androidブラウザ
  - リリース時点で利用可能な最新の WebKit ソース コードを使用します。
• さらに多くのポート: Amazon Silk、Dolphin、Blackberry、QtWebKit、WebKitGTK+、EFL ポート (Tizen)、wxWebKit、WebKitWinCE など

ポートごとに異なるタスクに集中できます。 Mac 移植の焦点は、ブラウザとオペレーティング システムの分離と、レンダリング エンジンをネイティブ アプリケーションに埋め込むための Obj-C および C++ バインディングの提供です。 Chromium ポートの焦点は完全にブラウザにあります。 QtWebKit は、すべての WebKit ブラウザーに共通する、レンダリング エンジンとしてクロスプラットフォーム アプリケーション アーキテクチャと一緒に使用できるポートを提供します。

まず、すべての WebKit ブラウザで使用される共通の機能を見てみましょう。

面白いことに、私はこの段落を書こうとして何度か試みました。 そして、ご覧のとおり、毎回 Chrome チームのメンバーが私を修正してくれました...

したがって、まず第一に、WebKit は HTML を同じ方法で解析します。 ただし、現時点で HTML 解析用のスレッドのサポートが含まれているポートは Chromium だけです。

...わかりましたが、HTML を解析した後、DOM ツリーは同じ方法で構築されます。 実際には、Shadow DOM は Chromium ポートでのみ有効になっており、DOM の構造は異なります。 カスタム要素にも。

…わかりました。WebKit は、誰に対しても同じ方法でウィンドウ オブジェクトとドキュメント オブジェクトを作成します。 確かに、提供されるプロパティと構造は機能フラグの使用に依存する可能性があります。

... CSS 解析も同じです。 CSS を食べて CSSOM に変換することは非常に標準的です。 はい、ただし、Apple やその他のブラウザが従来の -khtml- および -apple- プレフィックスをサポートしている場合、Chrome は -webkit- プレフィックスのみをサポートします。

...レイアウト...配置? パンとバターのようなものです。 それはどこでも同じですよね？ まあ、もう！ サブピクセル レイアウトとリッチ レイアウトの演算は WebKit の一部ですが、ポートごとに異なります。

素晴らしい。

だから、難しいんです。

さて、WebKit の世界の共通点をまとめてみましょう。

各 WebKit ポートに共通するもの。

• DOM、ウィンドウ、ドキュメント
  多かれ少なかれ
• CSSOM
• CSS 解析、プロパティ/値
  メーカープレフィックスの違い
• HTMLの解析とDOMの構築
  Web Components を忘れても同じです。
• レイアウトと配置
  フレックスボックス、フロート、ブロックフォーマットコンテキスト...すべてが共通です
• ユーザー インターフェイス ツールと開発者ツール (WebKit インスペクターとも呼ばれる Chrome DevTools など)。
  ただし、昨年 4 月以来、Safari は独自の Safari Inspector (WebKit ではない、クローズド ソースの Safari Inspector) を使用しています。
• contenteditable、pushState、File API、ほとんどの SVG、CSS 変換計算、Web Audio API、localStorage などの機能
  ただし、実装は異なる場合があります。 各ポートは独自のを使用できます 独自のシステム localStorage 用のストレージであり、Web Audio API 用に別のオーディオ API を使用できます。

少しややこしくなってきたので、WebKit ポートに共通しないいくつかの違いを見てみましょう。

• GPUに関するものなら何でも
  - 3D変換
  - WebGL
  - ビデオデコード
• 2D を画面にレンダリングする
  - アンチエイリアシング技術
  - SVG および CSS グラデーションのレンダリング
• テキストのレンダリングとハイフネーション
• ネットワークテクノロジー (SPDY、プリレンダリング、WebSocket トランスポート)
• JavaScriptエンジン
  - JavaScriptCore エンジンは WebKit リポジトリにあります。 ただし、WebKit には WebKit と V8 の両方に対するバインディングがあります。
• フォーム要素のレンダリング
• ビデオタグとオーディオタグの動作とコーデックのサポート
• 画像デコード
• 戻る/進むナビゲーション
  - 部分のpushState()
• 厳格なトランスポート セキュリティや公開キー PIN などの SSL 機能

そのうちの 1 つを見てみましょう: 2D グラフィックスはポートに依存しており、画面にレンダリングするためにまったく異なるライブラリを使用します。

さらに詳しく言うと、最近追加された機能: CSS.supports() が、有効になっていない win と wincairo を除くすべてのポートで有効になりました。 条件関数 css3 (css3 条件付き機能)。

さて、技術的な話になりますが、衒学的な話をする時間です。 上で述べたことさえ完全に正しいわけではありません。 これは実際には、汎用コンポーネントである WebCore です。 WebCore は、HTML および SVG 用のレイアウト、レンダリング、および DOM ライブラリであり、基本的に WebKit というと人々が思い浮かべるものです。 実際、「WebKit」は技術的には WebCore と「ポート」の間のバインディング層ですが、通常の会話では、この区別はほとんど重要ではありません。

この図は次の点に役立ちます。

WebKit のコンポーネントの多くは切り替え可能です (灰色で表示)。

たとえば、WebKit の JavaScript エンジンである JavaScriptCore は、WebKit のデフォルト エンジンです。 これは元々、WebKit が KHTML のフォークとして始まった時代の KJS (KDE から) に基づいています。 同時に、Chromium ポートは V8 エンジンに切り替わり、独自の DOM バインディングを使用します。

フォントとテキストのレンダリングは、プラットフォームの非常に重要な部分を占めています。 WebKit のテキストには、クイックとハードの 2 つの個別のパスがあります。 どちらもプラットフォーム固有のサポート (ポート側で実装) が必要ですが、Fast はグリフ (WebKit がプラットフォーム用にキャッシュするもの) をブリットする方法を知る必要があるだけで、Complex は文字列レンダリングを完全にプラットフォーム レベルに移動し、単に「これを描画して、お願いします。"

「WebKit はサンドイッチのようなものです。 それ以外の場合、Chromium の場合はタコスに似ています。 ウェブテクノロジーから生まれたおいしいタコス。
Dmitri Glazkov、Chrome WebKit ハッカー。 Web コンポーネントのチャンピオン、およびシャドウ ダム。

ここで、範囲を拡大して、いくつかのポートといくつかのサブシステムを見てみましょう。 以下に 5 つの WebKit ポートを示します。共通のコンポーネントにもかかわらず、それぞれのツールセットがどのように異なるかに注目してください。

Chrome (OS X) Safari (OS X) QtWebKit Android ブラウザ iOS 用 Chromeレンダリング ネットワーキング フォント JavaScript

スキア	コアグラフィックス	QtGui	Android スタック/Skia	コアグラフィックス
クロムネットワークスタック	CFネットワーク	Qtネットワーク	Chromium のネットワーク スタックのフォーク	クロムスタック
Skia経由のCoreText	コアテキスト	Qt の内部構造	Android スタック	コアテキスト
V8	JavaScriptコア	JSC (V8 は Qt の他の場所で使用されます)	V8	JavaScriptCore (JITting なし) *

* iOS 版 Chrome に関する脚注。 ご存知かと思いますが、UIWebView を使用します。 UIWebView の機能によれば、これは、Mobile Safari、JavaScriptCore (V8 ではない)、およびシングルスレッド モデルと同じレンダリング エンジンのみを使用できることを意味します。 ただし、ネットワーキング サブシステム、ブックマーク同期インフラストラクチャ、オムニボックス、メトリクス、クラッシュ レポートなど、一部のコードは Chromium から借用しています。 (また、モバイル デバイスで JavaScript がボトルネックになることはほとんどないため、JITting コンパイラーの欠如による影響は最小限です。)

さて、私たちはどこから来たのでしょうか? それで、すべての WebKit は今では完全に異なっています。 私は怖いです。

それだけの価値はありません！ WebKit がカバーする「layoutTest」テストは膨大です。 (最新のカウントでは 28,000 のテスト)、既存の関数だけでなく、見つかったすべての回帰も対象としています。 実際、新しい DOM/CSS/HTML-5 機能や「秘密の」DOM/CSS/HTML-5 機能を学習するときは、通常、「layoutTest」テスト スイートには優れた最小限のデモが含まれています。

さらに、W3C はテスト スイートの標準化にも取り組んでいます。 これは、WebKit ポートと他のすべてのブラウザの両方が同じテスト スイートでテストされることが期待できることを意味し、これにより問題が減り、Web の相互運用性が向上します。 Test The Web Forward イベントに参加してご尽力くださった皆様...ありがとうございます!

Opera は WebKit に移行したばかりです。 これで何が起こるでしょうか？ Robert Nyman と Rob Hawkes はすでにこの話題に触れていますが、発表の重要な部分の 1 つは Opera が Chromium に移行するということであったことを付け加えておきます。 これは、WebGL、Canvas、HTML5 フォーム、2D グラフィックスの実装、これらすべてが Chrome と Opera で同じになることを意味します。 同じ API と低レベルの実装。 Opera は Chromium に基づいているため、Opera と Chrome の間の互換性をチェックするためにワークロードを削減しているように感じるかもしれません。
すべての Opera ブラウザが Chromium に移行されることにも注意してください。 つまり、Windows、Mac、Linux、および Opera Mobile (本格的なモバイル ブラウザー) 用の Opera です。 シンクライアントである Opera Mini も、現在の Presto ベースのレンダリング ファームから Chromium ベースのレンダリング ファームに切り替えられ、WebKit の夜間ビルドが行われます。 これは何ですか？ これは WebKit で、Safari と同じコードで実行されます (ただし、一部の内部ライブラリは変更されています)。 これは主に Apple によって運営されているため、動作と機能セットは Safari のものと一致しています。 多くの場合、Apple は、他のポートが実装または実験中の機能を含めることに関しては保守的です。 とにかく、たとえて言えば… Safari の WebKit の夜間ビルドは Chrome の Chromium のようなものです。

タグを追加する

Apple Safari および Google Chrome を強化する人気のある Web ページ処理エンジン。 フリーソフトウェアです。 高速性とWeb標準への優れたサポートが特徴です。 WebKit は、多くのブラウザを動作させる Web 処理エンジンです。 その中には、「ビッグ 5」のうちの 2 つと、あまり人気のない Maxthon 3、Rekonq、Epiphany、RockMelt が含まれます。 コンカラー、ミドリ、アローラ。 モバイル ブラウザの開発者も、製品、特に Safari Mobile の操作にこのエンジンを使用しています。 iOSシステム モバイルに組み込まれたブラウザ Android プラットフォーム

、Samsung Bada および HP WebOS。

このようにさまざまなブラウザが存在するのは、WebKit がフリー ソフトウェアであり、いくつかの特定の条件を遵守すれば誰でも使用できるためです。 WebKit は、一般的なグラフィック環境のフレームワーク内で開発された無料の Web ページ処理エンジンを起源としています。オペレーティングシステム

ブラウザは Konqueror と呼ばれ、そのエンジンは KHTML です。 2001 年、Apple は独自のブラウザを作成することを検討し始め、KHTML のソース コードと KJS JavaScript コード処理エンジンを新しいプロジェクト内で動作させるために採用しました。 このプロジェクトは WebKit と呼ばれていました。

2003 年 1 月、Apple は WebKit エンジンを使用する Safari ブラウザの最初のリリースを発表しました。 時間が経つにつれて、Konqueror 開発者は WebKit を KHTML とともに使用する機能を組み込みました。 KHTML はすでに機能の点で WebKit に遅れをとっていますが、開発者は引き続き開発に取り組んでいます。

Google はまた、ブラウザを作成するときに WebKit エンジンを使用することを決定しました。 同社の代表者はこの選択の理由について次のように述べています。 より良いサポート Web標準と高速性。 さらに、Google は Apple 開発者の労働力を利用することを計画していました。 2 つの企業のプログラマーと多くの独立した開発者が現在このエンジンに取り組んでいることを考慮すると、WebKit がさらに優れたものになることは間違いありません。

つい最近、「Webkit」というタグが付いた質問を見つけました。 このような質問は通常、CSS、jQuery、レイアウト、ブラウザー間の互換性の問題などに関連する Web の問題に関連しています。

では、「Webkit」とは何ですか?CSS とどのように関係するのでしょうか? また、 -webkit-... プロパティがたくさんあることに気付きました。 ソースコードさまざまなウェブサイトに。 この2つは関連していますか?

アップデート

それで、これまでの答えから... WebKit は、Safari/Chrome 用の HTML/CSS Web ブラウザー レンダリング エンジンです。 そのようなメカニズムは IE/Opera/Firefox に存在しますか?また、一方を他方と比較して使用する場合の違い、長所、短所は何ですか? たとえば、Firefox で WebKit 機能を使用できますか?

最後の質問... WebKit は IE でサポートされていますか?

アップデート 2

主要なブラウザはすべて、異なるレンダリング エンジンを使用しています。 これが、ブラウザ間の互換性の問題が非常に多く存在する大きな理由だと思います。

では、すべてのブラウザが使用する標準レンダリング エンジンに関する何らかのプロジェクトや動きはあるのでしょうか? HTML5 はブラウザ間の互換性の問題を解決しますか?