Hvad er CEF?
CEF er en forkortelse for Chromium Embedded Framework, som er en open source webbrowser-kontrol baseret på Google Chromium-projektet, der understøtter Windows-, Linux- og Max-platforme. Ud over at levere C/C++-grænseflader findes der også porte til andre sprog.
Da det er baseret på Chromium, understøtter CEF HTML5-funktionerne, der er implementeret i Webkit og Chrome, og er relativt tæt på Chrome med hensyn til ydeevne.
CEF tilbyder også følgende funktioner: brugerdefinerede plugins, brugerdefinerede protokoller, brugerdefinerede Javascrip-objekter og udvidelser; Kontrollerbar ressourceindlæsning, navigation, kontekstmenuer osv.
Hvem bruger CEF
Lad os bruge nogle praktiske eksempler til at illustrere, hvad alle har gjort med CEF:
Forskellige browsere
Tidlige dual-core browsere (IE + Webkit) brugte nogle CEF som Webkit-kernebrowserkontrol.
Men for browsere er det faktisk vigtigt at udvide direkte i Chrome, og alle gør det nu (forskellige hurtige browsere).
Evernote-klient (på Windows)
Evernote tillader brugere at indsætte websider i noter og tilbyder også plugins til at gemme websider som noter.
Det må være behovet for at gengive siden korrekt på klienten, og denne opgave overlades til CEF.
GitHub-klient (på Windows)
GitHub har også pakket libcef.dll, set fra et performance-synspunkt, skal ReadMe-siden, der bruges til at vise projektet, være CEF, og brugerfladen andre steder kan også delvist implementeres med sider.
QQ
QQ har implementeret nogle funktioner og grænseflader ved at indlejre IE for længe siden. Siden sidste år har QQ introduceret CEF, som erstatter nogle steder, der tidligere brugte IE, så nogle nye funktioner baseret på Webkit kan bruges, og samtidig har det opnået fordele i hastighed, stabilitet og kompatibilitet.
Adobe Edge Animate & Adobe Edge Reflow
Adobe har lanceret et komplet sæt moderne websider (eller HTML5?) Edge.
Adobe Edge Animate kan til animation opnå komplekse animationer ved at redigere tidslinjen og skabe originaler (kaldet symboler i Edge Animate).
Edge Reflow er designet, det responsive web. Nogle oversætter det som responsiv, hvilket faktisk er adaptivt.
De to ovenstående programmer er grundlæggende orienteret mod Webkit-kernens browser, så det er nødvendigt at indlejre en Webkit-kerne for at levere en WYSIWYG-forhåndsvisning og redigeringsgrænseflade. De brugte alle CEF. (Forskellen mellem CEF og ren Webkit vil blive introduceret senere)
Q+
Under konceptet Web App tilbyder Q+ et kørende miljø for websider (kort sagt: en boks med klienten og nogle tilgængelige API'er) og understøtter IE- og Webkit-kerner.
For webudviklingsstuderende behøver Webkit-kernen (faktisk CEF), som vi introducerede, ikke tage højde for IE's versionskompatibilitetsproblemer, hvilket ikke kun forbedrer udviklingseffektiviteten, men også giver os mulighed for at udnytte nogle nye HTML5-funktioner. På det tidspunkt blev Q+'s applikationsmarked, beskedcenter, baggrunde, musikwidgets og andre applikationer alle udviklet baseret på Webkit-kernen.
Q+-projektet kan siges at have gjort flere forsøg på CEF, såsom:
Den udviklede musikwidget bruger HTML5-lydtagget;
Nogle applikationer bruger offline-funktionaliteten i HTML5 (dvs. med en manifestfil), men selvfølgelig er der nogle drikninger, og jeg har fået meget erfaring.
Pakkede Webkit Dev Tools.
Brugerdefinerede protokoller: For eksempel kan adgang til qplus:// protokoller omdirigeres til en særlig mappe.
Off-screen rendering (OSR): Ved at bruge off-screen rendering + Windows Layered Window oprettes et uregelmæssigt websidevindue (hvad er formen på det uigennemsigtige område på websiden, hvad er formen på vinduet)
Hvorfor indlejre CEF for kunder?
Med så mange eksempler er dette spørgsmål meget nemmere at sige:
Den bruges til at vise websider og benytte forskellige webtjenester;
Brug websider til at lave UI;
Brug HTML5-funktioner som lyd, lærred osv., inklusive CSS3-funktioner.
Off-screen rendering (OSR):
Den såkaldte OSR er at gengive hele siden på et bitmap uden at skabe et rigtigt vindue. Selvfølgelig ikke kun rendering, men også en række API'er til at håndtere mus, tastaturbegivenheder, inputmetode-begivenheder osv.
Denne funktion er især nyttig, når rigtige vinduer ikke kan bruges, som på lagdelte vinduer, eller når de renderes til teksturer i spil.
Ved hjælp af OSR-funktioner kan nogle interessante effekter laves, såsom:
AlloyTeam lavede Webtop, som bruger OSR til at lave en browser, spiller osv.
Der findes et Awesomium-projekt, der også understøtter OSR, og der findes allerede spilprojekter, der bruger Awesomium til at gengive websider i spil. (Når man ser på outputfilen fra Awesomium, burde det ligne implementeringen af CEF, det er alt sammen en pakke af Chromium, og CEF, som Awesomium kan lave, bør også udføres)
I min fritid lavede jeg en demo og brugte CEF til at gengive websider på OpenGL Texture, hvilket kan betragtes som et lille forsøg på at anvende CEF på spillet, som vist i figuren:
Browser-demo i spillet
Hvorfor CEF?
IE
IE har i lang tid været en indlejret browserkontrol, og for at være præcis har vi nu mange alternativer til IE.
CEF vs IE:
Kompatibilitet:
IE: Kernen varierer fra 6 til 10 versioner afhængigt af operativsystemet, og arbejdsbyrden ved webudvikling for at være kompatibel med disse versioner kan ikke undervurderes.
CEF: Den bruger Webkit-kernen, og set fra karakteristika-synspunktet kan en CEF-version svare til et Chrome-versionsnummer, så webudvikling har et klart sæt funktioner og eliminerer arbejdsbyrden med kompatibilitet.
HTML5-standard og nye funktioner:
IE: Selvfølgelig understøtter ældre versioner af IE ikke de nyeste HTML-funktioner og standarder.
CEF: Der er ingen tvivl om, at Webkit og Chrome er i front med at understøtte nye funktioner.
Open source og tværplatforms:
Altså: Ikke open source, begrænset til Windows-platformen
CEF: Open source, Webkit og Chromium, der bruges, er alle open source, open source betyder flere tilpasningsmuligheder; Og det spænder over Windows, Mac og Linux.
Off-screen rendering (OSR):
F.eks.: Du kan opnå rendering uden for skærmen gennem nogle hacks, men arbejdsbyrden er ikke lille, og det understøttes ikke officielt.
CEF: Der er en dedikeret off-screen renderingstilstand og tilhørende API.
Penetration:
IE: Alle Windows-brugere har IE, hvilket er fordelen ved IE (men nogle brugere har forkerte IE-indstillinger, hvilket vil føre til ubrugelighed, såsom jscrip{filtering}t.dll ikke registreret, hvilket resulterer i, at man ikke kan bruge Javascrip{filter}t)
CEF: Du skal selv installere og pakke det
Webkit
Hvorfor bevidst sammenligne CEF og Webkit?
Jeg læste for nylig en god artikel om, hvad Webkit er, hvad det ikke er, og hvorfor der er så mange Webkit-porte: "Hvad udviklere skal vide om WebKit"
Her er et groft resumé:
Webkit er parsing- og arrangementsmotoren for websider, som deles af alle Webkit-baserede browsere. Standardporten til Webkit er Safari, som er den version, der downloades fra Webkit-kildekodekompileringen. Der findes andre Webkit-porte, herunder Chromium, QtWebkit osv., som har forskellige implementeringer inden for 2D-grafik, GPU-acceleration, Javascrip-motor, lyd-/videodekodning osv.
CEF vs webkit (faktisk Chromium vs Webkit)
V8-motoren, skias 2D-rendering, Chromiums GPU-accelererede implementering osv., med hjælp fra Chromiums fremragende implementering er CEF også blevet en fremragende Webkit-port.
CEF-ulemper:
Vær venlig, CEF har også sine egne mangler og begrænsninger, og du kan ikke bare nævne fordelene, her vil jeg introducere fordele og ulemper ved CEF:
Volumen:
I den nyeste version af CEF bør summen af alle DLL'er være tæt på 40M, og det anslås, at det vil være 10M+ efter komprimering. Hvis dit projekt i sig selv ikke er stort og ikke kan modtage det, så er CEF ikke noget for dig.
Selvfølgelig bør dette volumen stadig være acceptabelt for spil, der nu beregnes af G.
For almindelige kundeprojekter afhænger det af, om projektet selv skal bruge de funktioner, der er implementeret af CEF, og om det er værd at øge installationspakken af produktet så meget. Selvfølgelig er der også nogle implementeringskompromiser her, såsom download efter installation (jeg synes personligt ikke, det er meningsfuldt, for brugere, der installerer pakker, kan jo også vælge at downloade software for at gøre det hurtigere)
Cache:
Chromes cache er designet til kun at have én proces, der læser og skriver, og det samme gælder for CEF.
For klienter, der skal åbnes flere gange, kan kun en forskellig cache-mappe angives for hver procesinstans. Dette øger dog uden tvivl harddiskforbruget og forårsager også, at nogle filer, der oprindeligt blev cachet, bliver downloadet flere gange (for eksempel cacher proces A jQuery.js, proces B skal anmode om og cache én gang, fordi den cacher forskellige mapper jQueyr.js
OSR:
OSR er i øjeblikket ikke som real window mode, som kan accelereres af GPU, og OSR kan kun gengives med software, hvilket betyder, at nogle CSS 3D-effekter ikke kan understøttes.
Dog bliver egenskaberne ved OSR stadig forbedret, og jeg synes personligt, det stadig er værd at se frem til.
Hvad du skal dele senere
Efter at have skrevet så meget, kan det betragtes som en introduktion til CEF, og jeg vil skrive nogle tekstiler i fremtiden, altså hvordan man bruger CEF, herunder:
CEF-kodeanskaffelse, kompilering, indlejring, behandling af API-kald af sider og klienter, OSR off-screen rendering, caching, brugerdefinerede protokoller, CEF1 & CEF3 osv.
Nå, det var alt for i dag.
|
Opslået på 22/09/2017 16.19.26
|
|
|
Opslået på 25/02/2019 09.14.24
|
Udlejer|
Opslået på 12/08/2023 20.08.02
|
