CEF:クライアント用にChromeを埋め込む

クズども · 掲載地 2017/09/22 16:19:26

CEFとは何ですか?
CEFはChromium Embedded Frameworkの略称で、Google Chromiumプロジェクトに基づくオープンソースのウェブブラウザ制御で、Windows、Linux、Maxプラットフォームをサポートしています。 C/C++インターフェースの提供に加え、他の言語向けの移植も存在します。

Cromiumをベースにしているため、CEFはWebkitやChromeで実装されたHTML5機能をサポートし、パフォーマンス面ではChromeに比較的近いです。

CEFはまた、カスタムプラグイン、カスタムプロトコル、カスタムJavascripオブジェクトおよび拡張、リソースの読み込み、ナビゲーション、コンテキストメニューなどを制御できます。

CEFを使っているのは誰か
CEFで皆さんが行ったことを示すために、いくつかの実践的な例を挙げてみましょう。

さまざまなブラウザ

初期のデュアルコアブラウザ(IE + Webkit)では、一部はCEFをWebkitカーネルブラウザ制御として使用していました。

しかしブラウザに関しては、Chromeに直接拡張することが実は王様であり、今では多くの高速ブラウザがそれを行っています。

Evernoteクライアント(Windows用)

Evernoteはユーザーがウェブページをノートに貼り付けることを可能にし、ウェブページをメモとして保存するプラグインも提供しています。

それはクライアント側で正しくページをレンダリングする必要性であり、この作業はCEFに任されています。

GitHubクライアント(Windows版)

GitHubはパフォーマンスの観点から、プロジェクトを表示するReadMeページはCEFでなければならず、他のUIも部分的にページで実装できるlibcef.dllパッケージ化しています。

QQ

QQはずっと前にIEを埋め込むことでいくつかの関数やインターフェースを実装しています。昨年以降、QQはCEFを導入し、以前IEを使用していた一部の場所を置き換え、Webkitに基づく新機能を活用できるようにしました。同時に、速度、安定性、互換性の面で優位性を得ています。

Adobe Edge アニメーション & Adobe Edge リフロー

Adobeは、最新のウェブページ(あるいはHTML5?)の完全なセットをリリースしました。エッジ。

アニメーション用のAdobe Edge Animateは、タイムラインを編集しオリジナル(Edge Animateではシンボルと呼ばれます)を作成することで複雑なアニメーションを実現できます。

エッジリフローはレスポンシブウェブの設計です。一部の人はこれをレスポンシブと訳しますが、実際には適応型です。

上記の2つのソフトウェアは基本的にWebkitカーネルのブラウザ向けに設計されているため、WYSIWYGプレビューおよび編集インターフェースを提供するためにWebkitカーネルを埋め込む必要があります。みんなCEFを使っていました。 (CEFと純粋Webkitの違いについては後ほど説明します)

質問+

Webアプリの概念のもと、Q+はウェブページの実行環境(簡単に言えばクライアントのボックスと一部の利用可能なAPI)を提供し、IEおよびWebkitカーネルをサポートしています。

ウェブ開発の学生にとって、私たちが導入したWebkitカーネル(実際にはCEF)はIEのバージョン互換性の問題を考慮する必要がありません。これにより開発効率が向上するだけでなく、新しいHTML5の機能を活用できます。当時、Q+のアプリケーションマーケット、メッセージセンター、壁紙、音楽ウィジェットなどのアプリケーションはすべてWebkitカーネルをベースに開発されていました。

Q+プロジェクトはCEFの試みがさらに多かったと言えるでしょう。例えば:

開発された音楽ウィジェットはHTML5オーディオタグを使用しています。

一部のアプリケーションはHTML5のオフライン機能(つまりマニフェストファイル)を使っていますが、もちろん多少の余波があり、私は多くの経験を積みました。

パッケージ化されたWebkit開発ツール。

カスタムプロトコル:例えば、qplus:// プロトコルへのアクセスは特別なフォルダにリダイレクトできます。

オフスクリーンレンダリング(OSR):オフスクリーンレンダリング+Windowsレイヤーウィンドウを用いることで、不規則なウェブページウィンドウが作成されます(ウェブページの不透明な部分の形状、ウィンドウの形状など)

なぜクライアントのためにCEFを埋め込むのか?
例が多すぎて、この質問はずっと言いやすいです。

ウェブページの表示やさまざまなWebサービスの利用に使われます。

UIはウェブページを使い、

音声やキャンバスなどのHTML5機能、CSS3の機能も活用しましょう。

オフスクリーンレンダリング(OSR):

いわゆるOSRは、実際のウィンドウを作らずにページ全体をビットマップにレンダリングすることです。もちろん、レンダリングだけでなく、マウスやキーボード、入力メソッドのイベントなどを処理する一連のAPIも含まれます。

この機能は、レイヤードウィンドウのように実際のウィンドウが使えない場合や、ゲーム内でテクスチャにレンダリングされる場合など特に有用です。

OSR機能を使うことで、次のような興味深い効果が生まれます。

AlloyTeamはWebtopを作り、OSRを使ってブラウザやプレイヤーなどを作りました。

OSRをサポートするAwesomiumプロジェクトもあり、すでにAwesomiumを使ってゲーム内のウェブページをレンダリングするゲームプロジェクトもあります。 (Awesomiumの出力ファイルを見ると、CEFの実装に似ているはずです。すべてChromiumのパッケージであり、AwesomiumができるCEFも同様に実現すべきです)

余暇にはデモを作成し、CEFを使ってOpenGL Textureでウェブページをレンダリングしました。これはゲームにCEFを適用しようとした小さな試みと見なせるでしょう。図に示されています:

ゲーム内ブラウザデモ

なぜCEFなのか?
つまり

IEは長い間、組み込みブラウザ制御として存在してきましたが、正確に言えば、今ではIEの代替手段が多数存在しています。

CEFとIE:

互換性：

例えば:カーネルはオペレーティングシステムによって6から10のバージョンまで変動し、これらのバージョンと互換性を持つためのウェブ開発の作業量は過小評価できません。

CEF:Webkitカーネルを使用しており、特性の観点からはCEFバージョンはChromeのバージョン番号に対応し、ウェブ開発に明確な機能セットがあり、互換性の検討にかかる負担を省きます。

HTML5標準と新機能:

IE:もちろん、古いバージョンのIEは最新のHTML機能や標準をサポートしていません。

CEF:WebkitとChromeが新機能のサポートの最前線に立っていることは間違いありません。

オープンソースとクロスプラットフォーム:

つまり:オープンソースではなく、Windowsプラットフォームに限定されています

CEF:オープンソースで、使われているWebkitやChromiumはすべてオープンソースです。オープンソースはよりカスタマイズ可能な可能性を意味します。 Windows、Mac、Linuxにまたがっています。

オフスクリーンレンダリング(OSR):

例えば、いくつかのハックでオフスクリーンレンダリングは可能ですが、作業量は少なく、公式にはサポートされていません。

CEF:専用のオフスクリーンレンダリングモードと対応APIがあります。

貫通:

IE:すべてのWindowsユーザーがIEを持っているため、これがIEの利点ですが(ただし、一部のユーザーは設定が間違っており、jscrip{filtering t.dll}が登録されていないなど使い物にならないことがあります。これによりJavascrip{filter}tが使えなくなることがあります

CEF:自分でインストールしてパッケージ化しなければなりません

ウェブキット

なぜわざとCEFとWebkitを比較するのでしょうか?

最近、Webkitとは何か、何ではないのか、そしてなぜこれほど多くのWebkit移植があるのかについての良い記事を読みました:「開発者が知っておくべきWebKitについて」

大まかな概要は以下の通りです。

Webkitはウェブページの解析および配置のエンジンであり、すべてのWebkitベースのブラウザで共有されています。 Webkitのデフォルト移植版はSafariで、これはWebkitのソースコードコンパイルからダウンロードされたバージョンです。 ChromiumやQtWebkitなど、2Dグラフィックス、GPUアクセラレーション、Javascripエンジン、音声・映像デコードなどで異なる実装を持つ他のWebkit移植版もあります。

CEFとWebkit(実際にはChromium対Webkit)

V8エンジン、skiaの2Dレンダリング、ChromiumのGPUアクセラレーション実装など、Chromiumの優れた実装の助けを借りて、CEFは優れたWebkit移植にもなりました。

CEFの欠点:
どうか親切にしてください。CEFにも独自の欠点や制限があり、利点だけを挙げるだけではダメです。ここではCEFの欠点と欠点を紹介します。

ボリューム:

CEFの最新バージョンでは、すべてのDLLの合計は約40Mに達し、圧縮後は10M+になると推定されています。もしプロジェクト自体が大きくなく、受取できないなら、CEFはあなた向きではありません。

もちろん、現在Gで計算されるゲームの場合、このボリュームは許容範囲であるべきです。

通常のクライアントプロジェクトでは、プロジェクト自体がCEFで実装された機能を使う必要があるか、そして製品のインストールパッケージを大幅に拡張する価値があるかによります。もちろん、インストール後のダウンロードなど実装上の妥協もあります(個人的にはこれは意味がないと思います。パッケージをインストールするユーザーはソフトウェアをダウンロードして高速化することも可能です)。

キャッシュ:

Chromeのキャッシュは1つのプロセスのみの読み書きを想定して設計されており、CEFも同様です。

複数回開く必要があるクライアントの場合、各プロセスインスタンスごとに異なるキャッシュフォルダを指定することが可能です。しかし、これによりハードディスクの使用量が確実に増加し、元々キャッシュされていたファイルが複数回ダウンロードされることもあります(例えば、プロセスAはjQuery.jsにキャッシュし、プロセスBは異なるディレクトリをキャッシュするため一度だけリクエストとキャッシュを行う必要がありますjQueyr.js

OSR:

OSRは現在、GPUで加速できる実際のウィンドウモードとは異なり、OSRはソフトウェアでしかレンダリングできないため、一部のCSS 3Dエフェクトはサポートできません。

しかし、OSRの特徴はまだ改善され続けており、個人的には今後も期待に値すると思っています。

後で共有する内容
これだけ書いた後で、これはCEFの入門書と見なせるでしょう。今後、CEFの使い方についてもいくつか書く予定です。具体的には:

CEFコード取得、コンパイル、埋め込み、ページやクライアントのAPI呼び出し処理、OSRのオフスクリーンレンダリング、キャッシュ、カスタムプロトコル、CEF1およびCEF3など。

さて、今日はこれで終わりです。

ユアン · 掲載地 2019/02/25 9:14:24

すごい

クズども · 掲載地 2023/08/12 20:08:02

WebView2 (6) WebView2ランタイムの配布および展開
https://www.itsvse.com/thread-10372-1-1.html

[WebView2] (5) 仮想ホストのローカルHTMLリソースの読み込み
https://www.itsvse.com/thread-10367-1-1.html

[WebView2] (4) WebとWinFormは関数メソッドを互いに呼び出します
https://www.itsvse.com/thread-10365-1-1.html

WebView2 (3) WebとWinFormアプリケーション間の双方向通信
https://www.itsvse.com/thread-10364-1-1.html

[WebView2] (2) WinFormがWebView2を導入し、ウェブコンテンツを表示
https://www.itsvse.com/thread-10362-1-1.html

[WebView2] (1) Microsoft Edge WebView2技術の初期導入
https://www.itsvse.com/thread-10361-1-1.html

CEF:クライアント用にChromeを埋め込む

関連記事

閲覧したセクション