Mi az a CEF?
A CEF a Chromium Embedded Framework rövidítése, amely egy nyílt forráskódú böngészővezérlő, amely a Google Chromium projekten alapul, és támogatja a Windows, Linux és Max platformokat. A C/C++ interfészek biztosítása mellett más nyelvekhez is vannak portok.
Mivel a Chromiumon alapul, a CEF támogatja a Webkit és Chrome által megvalósított HTML5 funkciókat, és teljesítményében viszonylag közel áll a Chromehoz.
A CEF a következő funkciókat is kínálja: egyedi bővítmények, egyedi protokollok, egyedi Javascrip objektumok és bővítmények; Irányítható erőforrás-betöltés, navigáció, kontextusmenük stb.
Ki használja a CEF-et
Használjunk néhány gyakorlati példát, hogy szemléljük, mit tett mindenki a CEF-szel:
Különböző böngészők
A korai kétmagos böngészők (IE + Webkit) közül néhányan a CEF-et használták Webkit kernel böngészővezérlőként.
Azonban a böngészők esetében a közvetlen Chrome-on való bővítés valójában a király, és most már mindenki ezt csinálja (különböző gyors böngészők).
Evernote Client (Windowson)
Az Evernote lehetővé teszi a felhasználók számára, hogy weboldalakat beillesztsenek jegyzetekbe, és bővítményeket is biztosít, amelyek a weboldalakat jegyzetként tárolják.
Ez valószínűleg az oldal helyes megjelenítésének szükségessége az ügyfélen, és ezt a feladatot a CEF-re bízzák.
GitHub Client (Windowson)
A GitHub libcef.dll is csomagolt be, teljesítmény szempontjából a projekt megjelenítéséhez használt ReadMe oldalnak CEF-nek kell lennie, és máshol a felhasználói felület részben is megvalósítható oldalakkal.
QQ
A QQ már régen beágyazta az IE-t néhány funkciót és interfészt. Tavaly óta a QQ bevezette a CEF-et, amely néhány olyan helyet váltott fel, amelyek korábban IE-t használtak, így néhány új Webkit alapú funkciót is fel tudnak használni, miközben a sebesség, stabilitás és kompatibilitás terén is előnyt szerzett.
Adobe Edge Animate és Adobe Edge Reflow
Az Adobe elindította a modern weboldalak teljes készletét (vagy HTML5-öst?) Él.
Az Adobe Edge Animate animációhoz összetett animációkat tud elérni az idővonal szerkesztésével és az eredetiek létrehozásával (az Edge Animate-ben szimbólumokat neveznek).
Az Edge Reflow a reszponzív webet tervezi. Vannak, akik úgy fordítják, hogy reagál, ami valójában adaptív.
A fenti két szoftver alapvetően a Webkit mag böngészőjére van igazodva, ezért szükséges egy Webkit kernel beágyazni, hogy WYSIWYG előnézett és szerkesztő felületet biztosítson. Mindegyik CEF-et használt. (A CEF és a tiszta Webkit közötti különbséget később bemutatjuk)
Q+
A Web App koncepciója szerint a Q+ futó környezetet biztosít weboldalakhoz (egyszerűen fogalmazva: egy kliens doboz és néhány elérhető API), valamint támogatja az IE és Webkit kerneleket.
Webfejlesztő hallgatók számára a Webkit kernel (valójában CEF), amelyet bemutattunk, nem kell figyelembe vennie az IE verziókompatibilitási problémáit, ami nemcsak javítja a fejlesztési hatékonyságot, hanem lehetővé teszi, hogy kihasználjunk néhány új HTML5 funkciót is. Ekkor a Q+ alkalmazáspiaca, üzenetközpontja, háttérképek, zenei widgetek és egyéb alkalmazások mind a Webkit kernel alapján készültek.
A Q+ projekt több kísérletet tett a CEF megvalósítására, például:
A fejlesztett zenei widget HTML5 audio címkét használja;
Néhány alkalmazás használja a HTML5 offline funkcióját (azaz egy manifest fájllal), de persze vannak csavarok és fordulatok, és rengeteg tapasztalatot szereztem.
Csomagolt Webkit fejlesztői eszközök.
Egyedi protokollok: Például qplus:// protokollokhoz való hozzáférés átirányítható egy speciális mappába.
Képernyőn kívüli renderezés (OSR): A képernyőn kívüli rendereléssel + Windows réteges ablak használatával egy szabálytalan weboldalablak keletkezik (milyen alakja a weboldal átlátszatlan területének, milyen az ablaknak)
Miért ágyazzák be a CEF-et az ügyfeleknek?
Ennyi példa miatt ezt a kérdést sokkal könnyebb megfogalmazni:
Weboldalak megjelenítésére és különféle webszolgáltatások használatára használják;
Weboldalakat használj UI elkészítéséhez;
Használj HTML5 funkciókat, például hangot, vászont stb., beleértve a CSS3 funkciókat is.
Képernyőn kívüli renderelés (OSR):
Az úgynevezett OSR az, hogy az egész oldalt egy bitmapre rendereljük anélkül, hogy valódi ablakot hoznánk létre. Természetesen nemcsak renderelés, hanem egy sor API is, amelyek kezelik az egér-, billentyűzet-eseményeket, bemeneti módszer-eseményeket stb.
Ez a funkció különösen akkor hasznos, ha valódi ablakokat nem lehet használni, például réteges ablakoknál, vagy amikor textúrákra renderelnek játékokban.
OSR funkciók segítségével érdekes effektek is létrehozhatók, például:
Az AlloyTeam készítette a Webtopot, amely OSR-t használ böngésző, lejátszó stb. elkészítéséhez.
Van egy Awesomium projekt, amely szintén támogatja az OSR-t, és már vannak olyan játékprojektek, amelyek az Awesomiumot használják a weboldalak megjelenítésére játékokban. (Az Awesomium kimeneti fájlját nézve annak hasonló kell lennie a CEF megvalósításához, ez mind egy Chromium csomag, és a CEF-et, amit az Awesomium is meg tud csinálni)
Szabadidőmben készítettem egy demót, és a CEF-et használtam weboldalak renderelésére OpenGL Texture-en, ami egy apró kísérletnek tekinthető arra, hogy a CEF-et alkalmazzam a játékban, ahogy az ábrán is látható:
Játékbeli böngésző demó
Miért a CEF?
Például
Az IE már régóta beágyazott böngészővezérlő, és pontosabban mostanra sok alternatívánk van az IE helyett.
CEF vs IE:
Kompatibilitás:
Például: A kernel 6 és 10 verzió között változik az operációs rendszertől függően, és a webfejlesztés munkaterhelése, hogy ezekkel a verziókkal kompatibilis legyen, nem lehet alábecsülni.
CEF: A Webkit kernelt használja, és jellemzők szempontjából egy CEF verzió megfelelhet egy Chrome verziószámnak, így a webfejlesztésnek egyértelmű funkciókészlete van, így kizárja a kompatibilitás számításának terhét.
HTML5 szabvány és új funkciók:
IE: Természetesen az IE régebbi verziói nem támogatják a legújabb HTML funkciókat és szabványokat.
CEF: Kétségtelen, hogy a Webkit és a Chrome az új funkciók támogatásának élvonalában áll.
Nyílt forráskódú és platformos rendszer:
Például: Nem nyílt forráskódú, csak Windows platformra korlátozott
CEF: Nyílt forráskódú, a Webkit és a Chromium mind nyílt forráskódú, a nyílt forráskód több testreszabható lehetőséget jelent; És ez a Windows-on, Mac-en és Linuxon is lefed.
Képernyőn kívüli renderelés (OSR):
Például: Néhány hack-tel el lehet érni a képernyőn kívüli renderelést, de a munkaterhelés nem kicsi, és hivatalosan sem támogatott.
CEF: Van egy dediktált képernyőn kívüli renderelési mód és hozzá tartozó API.
Áthatolás:
IE: Minden Windows felhasználónak van IE, ami az IE előnye (de néhány felhasználónak helytelen IE beállításai vannak, ami használhatóságot nem okoz, például a jscrip{filtering} t.dll nem regisztrált, így nem lehet használni a Javascrip{filter}t)
CEF: Magadnak kell telepítened és csomagolni
Webkit
Miért hasonlítjuk össze szándékosan a CEF-et és a Webkitet?
Nemrég olvastam egy jó cikket arról, hogy mi is az a Webkit, mi nem, és miért van annyi Webkit port: "Mit kell tudniuk a fejlesztőknek a WebKitről"
Íme egy durva összefoglaló:
A Webkit a weboldalak elemzési és elrendezési motorja, amelyet minden Webkit alapú böngésző megoszt. Az alapértelmezett Webkit port a Safari, amely a Webkit forráskód válogatásából letöltött verzió. Vannak más Webkit portok, például a Chromium, QtWebkit stb., amelyek eltérő megvalósítással rendelkeznek 2D grafikában, GPU gyorsításban, Javascrip motorban, audio/videó dekódolásban stb.
CEF vs webkit (valójában Chromium vs Webkit)
V8 motor, a skia 2D renderelése, a Chromium GPU-gyorsított megvalósítása stb., a Chromium kiváló megvalósításának segítségével a CEF kiváló Webkit portjává is vált.
CEF hátrányai:
Légy kedves, a CEF-nek is megvannak a maga hiányosságai és korlátai, és nem lehet csak az előnyöket említeni, itt bemutatom a CEF hátrányait és hátrányait:
Kötet:
A CEF legújabb verziója az összes DLL összege közel 40M-nek kellene lennie, és becslések szerint tömörítés után 10M+ lesz. Ha maga a projekted nem nagy méretű, és nem tudja megkapni, akkor a CEF nem neked való.
Természetesen azoknál a játékoknál, amelyeket most már G-vel számolnak, ez a mennyiség még mindig elfogadható.
A hagyományos kliensprojektek esetében attól függ, hogy a projektnek kell használnia a CEF által megvalósított funkciókat, és megéri-e ennyire növelni a termék telepítési csomagját. Természetesen vannak itt néhány megvalósítási kompromisszum is, például a letöltés telepítés után (személy szerint nem gondolom, hogy ez értelmes, hiszen a csomagokat telepítő felhasználók is letölthetnek szoftvert a gyorsítás érdekében)
Cache:
A Chrome gyorsítótára csak egy folyamat olvasását és írását tartalmazza, és ugyanez igaz a CEF-re is.
Azoknál a klienseknél, amelyeket többször kell megnyitni, minden process-példányhoz csak egy külön cache mappát lehet megadni. Ez azonban kétségtelenül növeli a merevlemez használatát, és egyes, eredetileg gyorsabőrbe állított fájlokat többször is letöltik (például az A folyamat jQuery.js gyorsítótárázza, a B folyamat egyszer kér és gyorsatárázza kell, mert különböző könyvtárakat tárol jQueyr.js
OSR:
Az OSR jelenleg nem olyan, mint a valódi ablakmód, amit GPU gyorsíthat, és az OSR csak szoftverrel renderelhető, ami azt jelenti, hogy bizonyos CSS 3D effektek nem támogathatók.
Az OSR jellemzői azonban még mindig fejlődnek, és személy szerint úgy gondolom, hogy érdemes várni a történetet.
Mit osszunk meg később
Ennyi írás után ezt a CEF bevezetésének tekinthetjük, és a jövőben néhány szárazanyagot is írni fogok, vagyis a CEF használatáról, többek között:
CEF kód gyűjtése, fordítása, beágyazása, oldalak és kliensek API-hívásainak feldolgozása, OSR képernyőn kívüli renderelés, gyorsítótározás, egyedi protokollok, CEF1 és CEF3 stb.
Nos, ennyi volt mára.
|
Közzétéve 2017. 09. 22. 16:19:26
|
|
|
Közzétéve 2019. 02. 25. 9:14:24
|
Háziúr|
Közzétéve 2023. 08. 12. 20:08:02
|
