CEF란 무엇인가요?
CEF는 Chromium Embedded Framework의 약자로, 구글 크로미움 프로젝트를 기반으로 한 오픈 소스 웹 브라우저 제어제로, Windows, Linux, Max 플랫폼을 지원합니다. C/C++ 인터페이스 제공 외에도 다른 언어를 위한 포트도 존재합니다.
크로미움을 기반으로 하기 때문에 CEF는 Webkit과 Chrome에 구현된 HTML5 기능을 지원하며, 성능 면에서 크롬과 비교적 비슷합니다.
CEF는 또한 다음과 같은 기능을 제공합니다: 맞춤형 플러그인, 맞춤형 프로토콜, 맞춤형 Javascrip 객체 및 확장; 제어 가능한 리소스 로딩, 내비게이션, 컨텍스트 메뉴 등.
누가 CEF를 사용하고 있나요
모두가 CEF를 통해 해온 일을 몇 가지 실용적인 예로 들어보겠습니다:
다양한 브라우저
초기 듀얼코어 브라우저(IE + Webkit)에서는 일부 CEF를 Webkit 커널 브라우저 제어로 사용했습니다.
하지만 브라우저 쪽에서는 크롬에서 직접 확장하는 것이 사실 왕이며, 요즘은 모두가 그렇게 하고 있습니다(다양한 빠른 브라우저들).
에버노트 클라이언트 (윈도우용)
에버노트는 사용자가 웹 페이지를 노트에 붙여넣을 수 있게 하며, 웹 페이지를 노트로 저장하는 플러그인도 제공합니다.
클라이언트에서 페이지를 올바르게 렌더링해야 하는 필요성일 텐데, 이 작업은 CEF에 맡겨져 있습니다.
GitHub 클라이언트 (Windows용)
GitHub는 성능 측면에서 프로젝트를 표시하는 ReadMe 페이지가 CEF여야 하며, 다른 곳의 UI도 부분적으로 페이지로 구현될 수 있도록 libcef.dll패키지화했습니다.
QQ
QQ는 오래전에 IE를 임베딩하여 일부 기능과 인터페이스를 구현한 적이 있습니다. 작년부터 QQ는 CEF를 도입하여 이전에 IE를 사용하던 일부 지역을 대체하여 Webkit 기반의 새로운 기능을 사용할 수 있게 했고, 동시에 속도, 안정성, 호환성 면에서 우위를 점했습니다.
어도비 엣지 애니메이트 및 어도비 엣지 리플로우
Adobe는 최신 웹페이지(또는 HTML5?)를 완성한 세트를 출시했습니다. 엣지.
애니메이션용 Adobe Edge Animate는 타임라인을 편집하고 원본(Edge Animate에서는 심볼이라고 부름)을 생성함으로써 복잡한 애니메이션을 구현할 수 있습니다.
Edge Reflow는 반응형 웹을 설계하는 것입니다. 어떤 사람들은 이를 반응형으로 번역하는데, 이는 사실 적응형입니다.
위 두 소프트웨어는 기본적으로 Webkit 커널의 브라우저에 맞춰져 있으므로, WYSIWYG 미리보기 및 편집 인터페이스를 제공하기 위해 Webkit 커널을 내장해야 합니다. 모두 CEF를 사용했습니다. (CEF와 순수 Webkit의 차이는 나중에 소개될 예정입니다)
Q+
웹 앱 개념 하에서 Q+는 웹 페이지 실행 환경(간단히 말해 클라이언트 박스와 일부 사용 가능한 API)을 제공하며, IE와 Webkit 커널을 지원합니다.
웹 개발 학생들을 위해 소개한 Webkit 커널(실제로는 CEF)은 IE의 버전 호환성 문제를 고려할 필요가 없어, 개발 효율성을 높일 뿐만 아니라 새로운 HTML5 기능도 활용할 수 있게 해줍니다. 당시 Q+의 애플리케이션 시장, 메시지 센터, 배경화면, 음악 위젯 및 기타 애플리케이션들은 모두 Webkit 커널을 기반으로 개발되었습니다.
Q+ 프로젝트는 CEF에 더 많은 시도를 했다고 할 수 있습니다. 예를 들면:
개발된 음악 위젯은 HTML5 오디오 태그를 사용합니다;
일부 애플리케이션은 HTML5의 오프라인 기능(즉, 매니페스트 파일과 함께)을 사용하지만, 물론 우여곡절이 있고 저는 많은 경험을 쌓았습니다.
패키지 Webkit 개발 도구.
사용자 지정 프로토콜: 예를 들어, qplus:// 프로토콜에 대한 접근을 특수 폴더로 리디렉션할 수 있습니다.
오프스크린 렌더링(OSR): 오프스크린 렌더링 + 윈도우 레이어드 윈도우를 사용하여 불규칙한 웹페이지 창을 생성합니다(웹페이지의 불투명 영역의 모양, 창의 모양이 무엇인지)
왜 고객을 위해 CEF를 임베딩해야 할까요?
예시가 많아 이 질문은 훨씬 쉽게 말할 수 있습니다:
웹 페이지를 표시하고 다양한 웹 서비스를 사용하는 데 사용됩니다;
UI 작업에는 웹 페이지를 활용하고;
오디오, 캔버스 등과 같은 HTML5 기능을 사용하고, CSS3 기능도 포함합니다.
오프스크린 렌더링(OSR):
이른바 OSR은 실제 창을 만들지 않고 전체 페이지를 비트맵에 렌더링하는 것입니다. 물론 렌더링뿐만 아니라 마우스, 키보드, 입력기 이벤트 등을 처리하는 일련의 API도 포함됩니다.
이 기능은 레이어드 윈도우처럼 실제 창을 사용할 수 없거나 게임에서 텍스처로 렌더링될 때 특히 유용합니다.
OSR 기능을 사용하면 다음과 같은 흥미로운 효과를 만들 수 있습니다:
AlloyTeam은 OSR을 이용해 브라우저, 플레이어 등을 만드는 Webtop을 만들었습니다.
OSR을 지원하는 Awesomium 프로젝트도 있고, 이미 Awesomium을 사용해 게임 내 웹 페이지를 렌더링하는 게임도 있습니다. (Awesomium 출력 파일을 보면, CEF 구현과 유사할 것이고, 모두 Chromium 패키지이며, Awesomium 할 수 있는 CEF 역시 그대로 구현되어야 합니다)
여가 시간에 데모를 만들어 CEF를 사용해 OpenGL 텍스처에서 웹페이지를 렌더링했는데, 이는 그림에서 볼 수 있듯이 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를 가지고 있는데, 이것이 IE의 장점입니다(하지만 일부 사용자는 잘못된 IE 설정을 가지고 있어 jscrip{filtering}t.dll 등록되지 않아 Javascrip{filter}t 사용이 불가능해집니다).
CEF: 직접 설치하고 패키징해야 합니다
웹킷
왜 일부러 CEF와 Webkit을 비교하는가?
최근에 Webkit이 무엇인지, 무엇이 아닌지, 그리고 왜 Webkit 포트가 이렇게 많은지에 관한 좋은 기사를 읽었습니다: "개발자들이 알아야 할 WebKit 정보"
대략적인 요약은 다음과 같습니다:
Webkit은 웹페이지의 파싱 및 배열 엔진으로, 모든 Webkit 기반 브라우저에서 공유됩니다. 기본 Webkit 포트는 Safari로, Webkit 소스 코드 컴파일에서 다운로드된 버전입니다. Chromium, QtWebkit 등 2D 그래픽, GPU 가속, Javascrip 엔진, 오디오/비디오 디코딩 등 다양한 구현을 가진 다른 Webkit 포트도 있습니다.
CEF 대 웹킷 (사실은 Chromium 대 Webkit)
V8 엔진, 스키아의 2D 렌더링, 크로미움의 GPU 가속 구현 등, 크로미움의 뛰어난 구현 덕분에 CEF는 훌륭한 웹킷 이식작이 되었습니다.
CEF 단점:
친절하게 말씀해 주세요. CEF도 단점과 한계가 있으며, 장점만 언급할 수 없습니다. 여기서 CEF의 단점과 단점을 소개하겠습니다:
볼륨:
최신 CEF는 모든 DLL의 합이 약 4,000만 명에 가까워야 하며, 압축 후에는 10M+에 이를 것으로 추정됩니다. 프로젝트 자체가 크지 않고 받을 수 없다면, CEF는 적합하지 않습니다.
물론, 이제 G로 계산되는 게임의 경우, 이 부피는 여전히 허용될 것입니다.
일반 클라이언트 프로젝트의 경우, 프로젝트 자체가 CEF가 구현한 기능을 사용해야 하는지, 그리고 제품 설치 패키지를 크게 늘리는 것이 가치가 있는지에 따라 다릅니다. 물론, 설치 후 다운로드 같은 구현상의 타협도 있습니다(개인적으로는 이 점이 의미가 있다고 생각하지 않습니다. 패키지를 설치한 사용자는 소프트웨어 다운로드를 선택해 속도를 높일 수도 있으니까요)
캐시:
크롬의 캐시는 하나의 프로세스만 읽고 쓰도록 설계되어 있으며, CEF도 마찬가지입니다.
여러 번 열어야 하는 클라이언트의 경우, 각 프로세스 인스턴스별로 서로 다른 캐시 폴더만 지정할 수 있습니다. 하지만 이로 인해 하드 디스크 사용량이 증가하고, 원래 캐시된 파일들이 여러 번 다운로드되는 경우도 생깁니다(예: 프로세스 A가 캐시를 jQuery.js 하고, 프로세스 B는 서로 다른 디렉터리를 캐시하기 때문에 한 번만 요청하고 캐시해야 합니다jQueyr.js
OSR:
현재 OSR은 GPU로 가속할 수 있는 실제 창 모드와 달리 OSR은 소프트웨어로만 렌더링할 수 있어 일부 CSS 3D 효과를 지원할 수 없습니다.
하지만 OSR의 특성은 여전히 개선 중이며, 개인적으로는 여전히 기대할 가치가 있다고 생각합니다.
나중에 공유할 내용
이렇게 많이 쓴 후에는 CEF 입문서로 볼 수 있으며, 앞으로도 CEF 사용법에 관한 몇 가지 드라이 코그드를 쓸 예정입니다. 예를 들어 다음과 같습니다:
CEF 코드 획득, 컴파일, 임베딩, 페이지 및 클라이언트의 API 호출 처리, OSR 오프스크린 렌더링, 캐싱, 커스텀 프로토콜, CEF1 및 CEF3 등.
오늘은 여기까지입니다.
|
게시됨 2017. 9. 22. 오후 4:19:26
|
|
|
게시됨 2019. 2. 25. 오전 9:14:24
|
집주인|
게시됨 2023. 8. 12. 오후 8:08:02
|
