Hva er CEF?
CEF er en forkortelse for Chromium Embedded Framework, som er en åpen kildekode-nettleserkontroll basert på Google Chromium-prosjektet, og støtter Windows-, Linux- og Max-plattformene. I tillegg til å tilby C/C++-grensesnitt, finnes det også porter for andre språk.
Fordi det er basert på Chromium, støtter CEF HTML5-funksjonene implementert i Webkit og Chrome, og er relativt nær Chrome når det gjelder ytelse.
CEF tilbyr også følgende funksjoner: tilpassede plugins, tilpassede protokoller, egendefinerte Javascrip-objekter og utvidelser; Kontrollerbar ressurslasting, navigasjon, kontekstmenyer osv.
Hvem bruker CEF
La oss bruke noen praktiske eksempler for å illustrere hva alle har gjort med CEF:
Ulike nettlesere
Tidlige dual-core nettlesere (IE + Webkit) brukte noen CEF som en Webkit-kjerne-nettleserkontroll.
Men for nettlesere er det faktisk viktig å utvide direkte i Chrome, og alle gjør det nå (ulike raske nettlesere).
Evernote-klient (på Windows)
Evernote lar brukere lime inn nettsider i notater, og tilbyr også plugins for å lagre nettsider som notater.
Det må være behovet for å gjengi siden korrekt på klienten, og denne oppgaven overlates til CEF.
GitHub-klient (på Windows)
GitHub har også pakket libcef.dll, fra et ytelsesperspektiv må ReadMe-siden som brukes til å vise prosjektet være CEF, og brukergrensesnittet andre steder kan også delvis implementeres med sider.
QQ
QQ har implementert noen funksjoner og grensesnitt ved å integrere IE for lenge siden. Siden i fjor har QQ introdusert CEF, som erstatter noen steder som tidligere brukte IE, slik at noen nye funksjoner basert på Webkit kan brukes, og samtidig har det fått fordeler innen hastighet, stabilitet og kompatibilitet.
Adobe Edge Animate & Adobe Edge Reflow
Adobe har lansert et komplett sett med moderne nettsider (eller HTML5?) Edge.
Adobe Edge Animate, for animasjon, kan oppnå komplekse animasjoner ved å redigere tidslinjen og lage originaler (kalt symboler i Edge Animate).
Edge Reflow er designet, det responsive nettet. Noen oversetter det som responsiv, noe som faktisk er adaptivt.
De to ovennevnte programmene er i hovedsak rettet mot nettleseren til Webkit-kjernen, så det er nødvendig å legge inn en Webkit-kjerne for å tilby et WYSIWYG-forhåndsvisnings- og redigeringsgrensesnitt. De brukte alle CEF. (Forskjellen mellom CEF og ren Webkit vil bli introdusert senere)
Q+
Under konseptet Web App tilbyr Q+ et kjøremiljø for nettsider (enkelt sagt: en boks med klienten og noen tilgjengelige API-er), og støtter IE- og Webkit-kjerner.
For webutviklingsstudenter trenger ikke Webkit-kjernen (egentlig CEF) vi introduserte å ta hensyn til IEs versjonskompatibilitetsproblemer, noe som ikke bare forbedrer utviklingseffektiviteten, men også lar oss dra nytte av noen nye HTML5-funksjoner. På den tiden ble Q+s applikasjonsmarked, meldingssenter, bakgrunner, musikkwidgets og andre applikasjoner alle utviklet basert på Webkit-kjernen.
Q+-prosjektet kan sies å ha gjort flere forsøk på CEF, som for eksempel:
Den utviklede musikkwidgeten bruker HTML5-lydtaggen;
Noen applikasjoner bruker offline-funksjonaliteten til HTML5 (altså med en manifestfil), men selvfølgelig er det noen overraskelser, og jeg har fått mye erfaring.
Pakkede Webkit-utviklingsverktøy.
Egendefinerte protokoller: For eksempel kan tilgang til qplus:// protokoller omdirigeres til en spesiell mappe.
Off-screen rendering (OSR): Ved å bruke off-screen rendering + Windows lagdelt vindu, opprettes et uregelmessig websidevindu (hva er formen på det ugjennomsiktige området på nettsiden, hva er formen på vinduet)
Hvorfor integrere CEF for klienter?
Med så mange eksempler er dette spørsmålet mye enklere å si:
Den brukes til å vise nettsider og bruke ulike webtjenester;
Bruk nettsider til å lage UI;
Bruk HTML5-funksjoner, som lyd, lerret osv., inkludert CSS3-funksjoner.
Off-screen rendering (OSR):
Den såkalte OSR er å gjengi hele siden på et bitmap uten å lage et ekte vindu. Selvfølgelig ikke bare rendering, men også en rekke API-er for å håndtere mus, tastaturhendelser, inputmetode-hendelser osv.
Denne funksjonen er spesielt nyttig når ekte vinduer ikke kan brukes, slik som på lagdelte vinduer, eller når det renderes til teksturer i spill.
Ved å bruke OSR-funksjoner kan noen interessante effekter lages, som:
AlloyTeam laget Webtop, som bruker OSR for å lage en nettleser, spiller osv.
Det finnes et Awesomium-prosjekt som også støtter OSR, og det finnes allerede spillprosjekter som bruker Awesomium til å rendre nettsider i spill. (Når man ser på utdatafilen til Awesomium, bør det ligne på implementeringen av CEF, det er alt en pakke av Chromium, og CEF som Awesomium kan gjøre, bør også gjøres)
På fritiden lagde jeg en demo og brukte CEF til å rendre nettsider på OpenGL Texture, noe som kan betraktes som et lite forsøk på å anvende CEF på spillet, som vist i figuren:
Nettleserdemo i spillet
Hvorfor CEF?
IE
IE har vært en innebygd nettleserkontroll i lang tid, og for å være presis har vi nå mange alternativer til IE.
CEF vs IE:
Forenlighet:
Altså: Kjernen varierer fra 6 til 10 versjoner avhengig av operativsystemet, og arbeidsmengden for webutvikling for å være kompatibel med disse versjonene kan ikke undervurderes.
CEF: Den bruker Webkit-kjernen, og fra et kjennetegnsperspektiv kan en CEF-versjon tilsvare et Chrome-versjonsnummer, slik at webutvikling har et klart sett med funksjoner, og eliminerer arbeidsmengden med å vurdere kompatibilitet.
HTML5-standard og nye funksjoner:
IE: Selvfølgelig støtter ikke eldre versjoner av IE de nyeste HTML-funksjonene og standardene.
CEF: Det er ingen tvil om at Webkit og Chrome er i front når det gjelder å støtte nye funksjoner.
Åpen kildekode og plattformuavhengig:
Altså: Ikke åpen kildekode, begrenset til Windows-plattformen
CEF: Åpen kildekode, Webkit og Chromium som brukes, er alle åpen kildekode, åpen kildekode gir flere muligheter for tilpasning; Og det dekker Windows, Mac og Linux.
Off-screen rendering (OSR):
Altså: Du kan oppnå rendering utenfor skjermen gjennom noen hacks, men arbeidsmengden er ikke liten, og det støttes ikke offisielt.
CEF: Det finnes en dedikert renderingsmodus utenfor skjermen og tilhørende API.
Penetrasjon:
IE: Alle Windows-brukere har IE, som er fordelen med IE (men noen brukere har feil IE-innstillinger, noe som vil føre til ubrukelighet, som jscrip{filtering}t.dll ikke registrert, noe som resulterer i manglende evne til å bruke Javascrip{filter}t)
CEF: Du må installere og pakke det selv
Webkit
Hvorfor bevisst sammenligne CEF og Webkit?
Jeg leste nylig en god artikkel om hva Webkit er, hva det ikke er, og hvorfor det finnes så mange Webkit-porter: «Hva utviklere trenger å vite om WebKit»
Her er en grov oppsummering:
Webkit er parsing- og arrangementsmotoren for nettsider, som deles av alle Webkit-baserte nettlesere. Standard Webkit-porten er Safari, som er versjonen som lastes ned fra Webkit-kildekodekompileringen. Det finnes andre Webkit-porter, inkludert Chromium, QtWebkit, osv., som har ulike implementasjoner innen 2D-grafikk, GPU-akselerasjon, Javascrip-motor, lyd-/videodekoding osv.
CEF vs webkit (egentlig Chromium vs Webkit)
V8-motoren, skias 2D-rendering, Chromiums GPU-akselererte implementering, osv., med hjelp av Chromiums utmerkede implementering, har CEF også blitt en utmerket Webkit-port.
CEF Ulemper:
Vær snill, CEF har også sine egne mangler og begrensninger, og du kan ikke bare nevne fordelene, her vil jeg introdusere ulempene og ulempene ved CEF:
Volum:
I den nyeste versjonen av CEF bør summen av alle DLL-er være nær 40 millioner, og det anslås at det vil være 10 millioner etter komprimering. Hvis prosjektet ditt i seg selv ikke er stort og ikke kan motta det, er ikke CEF noe for deg.
Selvfølgelig, for spill som nå beregnes med G, bør dette volumet fortsatt være akseptabelt.
For vanlige kundeprosjekter avhenger det av om prosjektet selv trenger å bruke funksjonene implementert av CEF, og om det er verdt å øke installasjonspakken av produktet så mye. Selvfølgelig finnes det også noen implementeringskompromisser her, som nedlasting etter installasjon (personlig synes jeg ikke dette er meningsfullt, tross alt kan brukere som installerer pakker også velge å laste ned programvare for å gjøre det raskere)
Cache:
Chromes cache er designet for å kun ha én prosess som leser og skriver, og det samme gjelder for CEF.
For klienter som må åpnes flere ganger, kan kun en annen cache-mappe spesifiseres for hver prosessinstans. Dette øker imidlertid utvilsomt bruken av harddisken, og fører også til at noen filer som opprinnelig ble cachet, lastes ned flere ganger (for eksempel cacher prosess A jQuery.js, prosess B må be og cache én gang fordi den cacher forskjellige kataloger jQueyr.js
OSR:
OSR er for øyeblikket ikke som ekte vindusmodus, som kan akselereres av GPU, og OSR kan kun gjenges med programvare, noe som betyr at noen CSS 3D-effekter ikke kan støttes.
Likevel blir egenskapene til OSR fortsatt forbedret, og jeg mener personlig at det fortsatt er verdt å se frem til.
Hva du bør dele senere
Etter å ha skrevet så mye, kan det betraktes som en introduksjon til CEF, og jeg vil skrive noen tørrvarer i fremtiden, altså hvordan man bruker CEF, inkludert:
CEF-kodeinnhenting, kompilering, innbygging, behandling av API-kall for sider og klienter, OSR-rendering utenfor skjermen, caching, tilpassede protokoller, CEF1 og CEF3, osv.
Vel, det var alt for i dag.
|
Publisert på 22.09.2017 16:19:26
|
|
|
Publisert på 25.02.2019 09:14:24
|
Vert|
Publisert på 12.08.2023 20:08:02
|
