Що таке CEF?
CEF — це абревіатура від Chromium Embedded Framework, який є відкритим браузерним керуванням, заснованим на проєкті Google Chromium, що підтримує платформи Windows, Linux та Max. Окрім надання інтерфейсів C/C++, існують також порти для інших мов.
Оскільки CEF базується на Chromium, він підтримує функції HTML5, реалізовані у Webkit і Chrome, і відносно близький до Chrome за продуктивністю.
CEF також надає такі функції: власні плагіни, власні протоколи, власні об'єкти та розширення Javascrip; Контрольоване завантаження ресурсів, навігація, контекстні меню тощо.
Хто використовує CEF
Давайте використаємо кілька практичних прикладів, щоб проілюструвати, що всі робили з CEF:
Різні браузери
Ранні двоядерні браузери (IE + Webkit) деякі використовували CEF як керування браузером ядра Webkit.
Однак для браузерів розширення безпосередньо в Chrome насправді є королем, і зараз це роблять усі (різні швидкі браузери).
Evernote Client (на Windows)
Evernote дозволяє користувачам вставляти веб-сторінки у нотатки, а також надає плагіни для збереження вебсторінок у вигляді нотаток.
Це має бути потреба правильно відтворити сторінку на клієнті, і це завдання залишається на CEF.
Клієнт GitHub (на Windows)
GitHub також упакував libcef.dll, з точки зору продуктивності, сторінка ReadMe, що використовується для відображення проєкту, має бути CEF, а інтерфейс в інших місцях також може частково реалізовуватися зі сторінками.
QQ
QQ давно реалізував деякі функції та інтерфейси, вбудувавши IE. З минулого року QQ впровадила CEF, замінивши деякі місця, де раніше використовувався IE, щоб можна було застосовувати нові функції на базі Webkit, а також отримала переваги у швидкості, стабільності та сумісності.
Adobe Edge Animate та Adobe Edge Reflow
Adobe запустила повний набір сучасних веб-сторінок (або HTML5?) Едж.
Adobe Edge Animate для анімації може створювати складні анімації, редагуючи таймлайн і створюючи оригінали (у Edge Animate називаються символами).
Edge Reflow — це дизайн адаптивного вебу. Дехто переводить це як responsive, що насправді є адаптивним.
Два вищезазначені програми орієнтовані на браузер ядра Webkit, тому необхідно вбудувати ядро Webkit для забезпечення інтерфейсу попереднього перегляду та редагування WYSIWYG. Всі вони використовували CEF. (Різниця між CEF і чистим Webkit буде представлена пізніше)
Q+
У межах концепції Web App Q+ забезпечує робоче середовище для веб-сторінок (простіше кажучи: коробку клієнта та деякі доступні API), а також підтримує ядра IE та Webkit.
Для студентів веб-розробки ядро Webkit (фактично CEF), яке ми представили, не потребує врахування проблем сумісності версій IE, що не лише підвищує ефективність розробки, а й дозволяє використовувати деякі нові функції HTML5. На той час ринок додатків Q+, центр повідомлень, шпалери, музичні віджети та інші додатки розроблялися на основі ядра Webkit.
Можна сказати, що проєкт Q+ робив більше спроб реалізувати CEF, наприклад:
Розроблений музичний віджет використовує аудіотег HTML5;
Деякі додатки використовують офлайн-функціонал HTML5 (тобто з файлом маніфесту), але, звісно, є деякі несподівані повороти, і я здобув багато досвіду.
Упаковані інструменти розробки Webkit.
Власні протоколи: Наприклад, доступ до qplus:// протоколів можна перенаправити у спеціальну папку.
Позаекранне рендеринг (OSR): Використовуючи позаекранне рендеринг + Windows Layered Window, створюється нерегулярне вікно веб-сторінки (яка форма непрозорої області веб-сторінки, яка форма вікна)
Чому вбудовувати CEF для клієнтів?
З такою кількістю прикладів це питання набагато легше поставити:
Він використовується для відображення веб-сторінок і використання різних веб-сервісів;
Використовуйте веб-сторінки для створення інтерфейсу;
Використовуйте функції HTML5, такі як аудіо, полотно тощо, включаючи функції CSS3.
Позаекранне рендеринг (OSR):
Так званий OSR — це рендеринг усієї сторінки на бітмап без створення реального вікна. Звісно, не лише рендеринг, а й низку API для обробки подій миші, клавіатури, подій методів введення тощо.
Ця функція особливо корисна, коли реальні вікна неможливо використовувати, наприклад, у шарових вікнах або при рендерингу текстур у іграх.
Використовуючи функції OSR, можна створити цікаві ефекти, наприклад:
AlloyTeam створила Webtop, який використовує OSR для створення браузера, плеєра тощо.
Існує проєкт Awesomium, який також підтримує OSR, і вже є ігрові проєкти, які використовують Awesomium для рендерингу веб-сторінок у іграх. (Дивлячись на вихідний файл Awesomium, він має бути схожий на реалізацію CEF, це все пакет Chromium, і CEF, який Awesomium може робити, теж має бути виконаний)
У вільний час я зробив демо і використовував 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 (але деякі користувачі мають неправильні налаштування IE, що призведе до непридатності використання, наприклад, jscrip{filtering}t.dll не зареєстровано, що призводить до неможливості використовувати Javascrip{filter}t)
CEF: Потрібно встановити і пакувати його самостійно
Webkit
Навіщо навмисно порівнювати CEF і Webkit?
Нещодавно я прочитав хорошу статтю про те, що таке Webkit, чим він не є і чому існує так багато портів Webkit: «Що розробникам потрібно знати про WebKit»
Ось приблизний підсумок:
Webkit — це рушій розбору та організації веб-сторінок, який використовується всіма браузерами на базі Webkit. Порт Webkit за замовчуванням — Safari, версія, завантажена з компіляції вихідного коду Webkit. Існують й інші порти Webkit, зокрема Chromium, QtWebkit тощо, які мають різні реалізації у 2D-графіці, прискоренні GPU, рушії Javascrip, декодуванні аудіо/відео тощо.
CEF проти вебкіта (насправді Chromium проти Webkit)
Двигун V8, 2D-рендеринг від skia, реалізація Chromium з прискоренням GPU тощо, завдяки відмінній реалізації Chromium, CEF також став відмінним портом Webkit.
Недоліки CEF:
Будьте добрими, CEF також має свої недоліки та обмеження, і ви не можете просто згадати їх, тут я розповім про недоліки та недоліки CEF:
Том:
Остання версія CEF, сума всіх DLL має бути близько 40M, і оцінюється, що після стиснення вона буде 10M+. Якщо ваш проєкт сам по собі невеликий і не може його прийняти, то CEF вам не підходить.
Звісно, для ігор, які тепер розраховуються за G, цей обсяг має бути прийнятним.
Для звичайних клієнтських проєктів це залежить від того, чи потрібно сам проєкт використовувати функції, реалізовані CEF, і чи варто так сильно збільшувати пакет встановлення продукту. Звісно, тут є й певні компроміси, наприклад, завантаження після встановлення (особисто я не вважаю це важливим, адже користувачі, які встановлюють пакети, можуть також завантажувати програмне забезпечення для прискорення)
Кеш:
Кеш Chrome розроблений так, щоб читати та записувати лише один процес, і те саме стосується CEF.
Для клієнтів, які потрібно відкривати кілька разів, для кожного екземпляра процесу можна вказати лише окрему папку кешу. Однак це, без сумніву, збільшує використання жорсткого диска, а також призводить до багаторазового завантаження деяких файлів, які були кешовані (наприклад, кешування процесу A jQuery.js, процес B має зробити запит і кешувати один раз, оскільки кешує різні каталоги jQueyr.js
OSR:
OSR наразі відрізняється від режиму real window, який можна прискорити за допомогою GPU, а OSR можна рендерити лише за допомогою програмного забезпечення, що означає, що деякі CSS-3D-ефекти не підтримуються.
Однак характеристики OSR все ще вдосконалюються, і я особисто вважаю, що варто чекати на нього з нетерпінням.
Чим поділитися пізніше
Після стількох написань це можна розглядати як вступ до CEF, і я напишу деякі сухі матеріали в майбутньому, а саме про те, як користуватися CEF, зокрема:
Збір коду CEF, компіляція, вбудовування, обробка API-викликів сторінок і клієнтів, OSR-рендеринг поза екраном, кешування, власні протоколи, CEF1 та CEF3 тощо.
Ну, на сьогодні все.
|
Опубліковано 22.09.2017 16:19:26
|
|
|
Опубліковано 25.02.2019 09:14:24
|
Орендодавець|
Опубліковано 12.08.2023 20:08:02
|
