Vad är CEF?
CEF är en förkortning för Chromium Embedded Framework, som är en öppen källkodswebbläsarkontroll baserad på Google Chromium-projektet, som stödjer Windows-, Linux- och Max-plattformarna. Förutom att tillhandahålla C/C++-gränssnitt finns det även portar för andra språk.
Eftersom det är baserat på Chromium stöder CEF HTML5-funktionerna som implementerats i Webkit och Chrome, och är relativt nära Chrome prestandamässigt.
CEF tillhandahåller även följande funktioner: anpassade plugins, anpassade protokoll, anpassade Javascrip-objekt och tillägg; Kontrollerbar resursladdning, navigering, kontextmenyer med mera.
Vem använder CEF
Låt oss använda några praktiska exempel för att illustrera vad alla har gjort med CEF:
Olika webbläsare
Tidiga dubbelkärniga webbläsare (IE + Webkit) använde vissa CEF som en webbläsarkontroll för Webkit-kärnan.
Men för webbläsare är det faktiskt bäst att utöka direkt i Chrome, och alla gör det nu (olika snabba webbläsare).
Evernote-klient (på Windows)
Evernote låter användare klistra in webbsidor i anteckningar och erbjuder även plugins för att spara webbsidor som anteckningar.
Det måste vara behovet av att rendera sidan korrekt på klienten, och denna uppgift lämnas till CEF.
GitHub-klient (på Windows)
GitHub har också paketerat libcef.dll, ur prestandasynpunkt måste ReadMe-sidan som används för att visa projektet vara CEF, och användargränssnittet på andra håll kan också delvis implementeras med sidor.
QQ
QQ har implementerat vissa funktioner och gränssnitt genom att bädda in IE för länge sedan. Sedan förra året har QQ introducerat CEF, som ersätter vissa platser som tidigare använde IE, så att vissa nya funktioner baserade på Webkit kan användas, och samtidigt har det fått fördelar i hastighet, stabilitet och kompatibilitet.
Adobe Edge Animate & Adobe Edge Reflow
Adobe har lanserat en komplett uppsättning moderna webbsidor (eller HTML5?) Edge.
Adobe Edge Animate kan, för animation, uppnå komplexa animationer genom att redigera tidslinjen och skapa original (kallade symboler i Edge Animate).
Edge Reflow är designen av den responsiva webben. Vissa översätter det som responsivt, vilket faktiskt är adaptivt.
De två ovanstående programmen är i princip inriktade på webbläsaren i Webkit-kärnan, så det är nödvändigt att bädda in en Webkit-kärna för att tillhandahålla en WYSIWYG-förhandsgranskning och redigeringsgränssnitt. De använde alla CEF. (Skillnaden mellan CEF och ren Webkit kommer att introduceras senare)
Q+
Under konceptet Web App tillhandahåller Q+ en körmiljö för webbsidor (enkelt uttryckt: en låda med klienten och några tillgängliga API:er), och stöder IE- och Webkit-kärnor.
För webbutvecklingsstudenter behöver Webkit-kärnan (egentligen CEF) vi introducerade inte ta hänsyn till IE:s versionskompatibilitetsproblem, vilket inte bara förbättrar utvecklingseffektiviteten utan också gör att vi kan dra nytta av vissa nya HTML5-funktioner. Vid den tiden utvecklades Q+:s applikationsmarknad, meddelandecenter, bakgrunder, musikwidgets och andra applikationer alla baserade på Webkit-kärnan.
Q+-projektet kan sägas ha gjort fler försök med CEF, såsom:
Den utvecklade musikwidgeten använder HTML5-ljudtaggen;
Vissa applikationer använder offline-funktionaliteten i HTML5 (dvs. med en manifestfil), men det finns förstås vissa vändningar, och jag har fått mycket erfarenhet.
Paketerade Webkit-utvecklingsverktyg.
Anpassade protokoll: Till exempel kan åtkomst till qplus:// protokoll omdirigeras till en speciell mapp.
Off-screen rendering (OSR): Genom att använda off-screen rendering + Windows Layered Window skapas ett oregelbundet webbsidesfönster (vad är formen på det ogenomskinliga området på webbsidan, vad är formen på fönstret)
Varför bädda in CEF för kunder?
Med så många exempel är denna fråga mycket lättare att säga:
Den används för att visa webbsidor och använda olika webbtjänster;
Använd webbsidor för att göra UI;
Använd HTML5-funktioner, såsom ljud, canvas, etc., inklusive CSS3-funktioner.
Rendering utanför skärmen (OSR):
Den så kallade OSR är att rendera hela sidan på en bitmap utan att skapa ett riktigt fönster. Självklart inte bara rendering, utan också en serie API:er för att hantera mus, tangentbordshändelser, inmatningsmetodhändelser osv.
Denna funktion är särskilt användbar när riktiga fönster inte kan användas, som på lager-på-lager-fönster, eller när de renderas till texturer i spel.
Med hjälp av OSR-funktioner kan några intressanta effekter skapas, såsom:
AlloyTeam gjorde Webtop, som använder OSR för att skapa en webbläsare, spelare, etc.
Det finns ett Awesomium-projekt som också stödjer OSR, och det finns redan spelprojekt som använder Awesomium för att rendera webbsidor i spel. (Om man tittar på utdatafilen för Awesomium bör det likna implementationen av CEF, det är allt ett paket av Chromium, och CEF som Awesomium kan göra bör också göras.)
På min fritid gjorde jag en demo och använde CEF för att rendera webbsidor på OpenGL Texture, vilket kan ses som ett litet försök att applicera CEF på spelet, som visas i figuren:
Demo av webbläsare i spelet
Varför CEF?
IE
IE har länge varit en inbäddad webbläsarkontroll, och för att vara exakt har vi nu många alternativ till IE.
CEF vs IE:
Kompatibilitet:
Dvs: kärnan varierar från 6 till 10 versioner beroende på operativsystem, och arbetsbelastningen för webbutveckling för att vara kompatibel med dessa versioner kan inte underskattas.
CEF: Den använder Webkit-kärnan, och ur ett karaktärsperspektiv kan en CEF-version motsvara ett Chrome-versionsnummer, så att webbutveckling har en tydlig uppsättning funktioner och eliminerar arbetsbördan med kompatibilitet.
HTML5-standard och nya funktioner:
IE: Självklart stöder äldre versioner av IE inte de senaste HTML-funktionerna och standarderna.
CEF: Det råder ingen tvekan om att Webkit och Chrome ligger i framkant när det gäller att stödja nya funktioner.
Öppen källkod och plattformsoberoende plattform:
Dvs: Inte öppen källkod, begränsad till Windows-plattformen
CEF: Öppen källkod, Webkit och Chromium som används är alla öppen källkod, öppen källkod innebär fler anpassningsmöjligheter; Och det täcker Windows, Mac och Linux.
Rendering utanför skärmen (OSR):
T.ex. kan du uppnå rendering utanför skärmen genom vissa hacks, men arbetsbelastningen är inte liten och det stöds inte officiellt.
CEF: Det finns ett dedikerat renderingsläge utanför skärmen och motsvarande API.
Penetration:
IE: Alla Windows-användare har IE, vilket är fördelen med IE (men vissa användare har felaktiga IE-inställningar, vilket leder till oanvändbarhet, såsom jscrip{filtering}t.dll inte registrerat, vilket leder till att Javascrip{filter}t inte kan användas).
CEF: Du måste installera och paketera det själv
Webkit
Varför medvetet jämföra CEF och Webkit?
Jag läste nyligen en bra artikel om vad Webkit är, vad det inte är, och varför det finns så många Webkit-portar: "Vad utvecklare behöver veta om WebKit"
Här är en grov sammanfattning:
Webkit är parsnings- och arrangemangsmotorn för webbsidor, som delas av alla Webkit-baserade webbläsare. Standardporten för Webkit är Safari, som är versionen som laddas ner från Webkit-källkodskompileringen. Det finns andra Webkit-portar, inklusive Chromium, QtWebkit, etc., som har olika implementationer inom 2D-grafik, GPU-acceleration, Javascrip-motor, ljud-/videoavkodning med mera.
CEF vs webkit (egentligen Chromium vs Webkit)
V8-motorn, skias 2D-rendering, Chromiums GPU-accelererade implementation, etc., med hjälp av Chromiums utmärkta implementation har CEF också blivit en utmärkt Webkit-port.
CEF:s nackdelar:
Var snäll, CEF har också sina egna brister och begränsningar, och du kan inte bara nämna fördelarna, här kommer jag att presentera för- och nackdelarna med CEF:
Volym:
I den senaste versionen av CEF bör summan av alla DLL:er vara nära 40 Milliounen, och det uppskattas att det blir 10 Milliounen+ efter komprimering. Om ditt projekt i sig inte är stort och inte kan ta emot det, är CEF inte för dig.
Självklart, för spel som nu räknas av G, bör denna volym fortfarande vara acceptabel.
För vanliga klientprojekt beror det på om projektet självt behöver använda de funktioner som CEF implementerat, och om det är värt att utöka installationspaketet för produkten så mycket. Självklart finns det också vissa implementeringskompromisser här, som nedladdning efter installation (personligen tycker jag inte att detta är meningsfullt, trots allt kan användare som installerar paket också välja att ladda ner programvara för att snabbare på det)
Cache:
Chromes cache är designad för att endast ha en process som läser och skriver, och detsamma gäller för CEF.
För klienter som behöver öppnas flera gånger kan endast en separat cachemapp specificeras för varje processinstans. Detta ökar dock utan tvekan hårddiskanvändningen och gör också att vissa filer som ursprungligen var cachade laddas ner flera gånger (till exempel cachar process A jQuery.js, process B måste begära och cacha en gång eftersom den cachar olika kataloger jQueyr.js
OSR:
OSR är för närvarande inte som det verkliga fönsterläget, som kan accelereras av GPU, och OSR kan endast renderas med mjukvara, vilket innebär att vissa CSS 3D-effekter inte kan stödjas.
Men egenskaperna hos OSR förbättras fortfarande, och jag tycker personligen att det fortfarande är värt att se fram emot.
Vad du ska dela senare
Efter att ha skrivit så mycket kan det ses som en introduktion till CEF, och jag kommer att skriva några torra varor i framtiden, det vill säga hur man använder CEF, inklusive:
CFF-kodinsamling, kompilering, inbäddning, bearbetning av API-anrop för sidor och klienter, OSR-rendering utanför skärmen, caching, anpassade protokoll, CEF1 och CEF3, etc.
Nåväl, det var allt för idag.
|
Publicerad på 2017-09-22 16:19:26
|
|
|
Publicerad på 2019-02-25 09:14:24
|
Hyresvärd|
Publicerad på 2023-08-12 20:08:02
|
