WebKit2 - High Level Document
WebKit2는 분리된 프로세스모델을 지원하기 위해 고안된 새로운 API Layer이다.
Why is it named WebKit2?
오리지날과 호환되지 않는 API변경이 있기 때문에 이름이 다르다. 이 라이브러리는 /System/Library/WebKit2.framework 위치에 설치될것이다.
C API
WebKit2는 C-based non-blocking API를 제공하며 대부분 플랫폼을 구별하지 않는다. non-blocking API를 지원하기 위해 몇가지 기술이 사용되는데 다음과 같다.
- 통지형태의 클라이언트콜백 : 무언가 이벤트가 발생하였음을 알린다. ex: didFinishLoadForFrame
- 정책형태의 클라이언트콜백 : 어떤 동작에 대한 정책을 정할 수 있게 해준다. ex: decidePolicyForNavigationAction
- 정책 설정 : 콜백없이 미리 정의된 정책을 지정할 수 있게 해준다. ex: WKContextSetCacheModel, WKContextSetPopupPolicy
- 추출된 코드 : 다른 옵션이 실패하는 경우 WebProcess에 로드될 수 있는 코드이며 DOM에 접근하고자 할 때 유용하다. 아직 계획중이며 구현은 안되어 있다. ex: WebBundle
주요한 API 클래스들은 아래와 같다:
WKContextRef
- 모든 페이지들에 대해 캡슐화를 제공한다. 하나의 Context의 모든 페이지들은 동일한 방문링크셋, 로컬스토리지, 그리고 프리퍼런스들을 공유한다.
WKPageNamespaceRef
- 서로 스크립트할 수 있는 모든 페이지들.Encapsulates all pages that can script each other.
WKPageRef
- 브라우징 기본 유닛, Basic unit of browsing. Stays the same as the main frame changes.
WKView[Ref]
- 플랫폼툴킷에서 훅킹하는 네이티브뷰. 윈도우에서는 HWND, 맥에서는 NSView에 해당한다.
Port-Specific APIs
포팅에 국한된 API들이 있을 수 있다. 이 경우 기존 포팅에는 영향을 받지 않도록 한다.
Process Architecture
WebKit API Layer내에서 프로세스관리메커니즘을 빌드하는 스택을 변경한다.
다음은 전통적인 웹킷포팅 아키택쳐를 보여준다.
모든것이 하나의 프로세스안에 있다. 그리고 application과 WebKit API간의 경계가 있다. 이는 단순하고 재사용면에서도 편리하다.
다음은 WebKit2의 구성이다.
이제 하나의 프로세스 경계가 있다. 그리고 API 경계가 자리잡고 있다. WebKit의 일부는 UI Process에서 동작하는데 application logic이 살아 있다. WebKit의 나머지는 WebCore, JS Engine과 함께 WebProcess에 살아 있다. Webprocess는 UI process와 분리되어 있다. 이는 응답성, 견고성, 보안성 그리고 멀티코어에 적합하다.
How is This Different from Chromium WebKit?
크로미엄은 멀티프로세스에 다르게 접근한다.
Notice that in this case, the the process boundary is *above* the API boundary. Chromium WebKit does not directly provide a multiprocess framework, rather, it is optimized for use as a component of a multiprocess application, which does all the proxying and process management itself. The Chrome team at Google did a great job at trailblazing multiprocess browsing with Chrome. But it's difficult to reuse their work, because the critical logic for process management, proxying between processes and sandboxing is all part of the Chrome application, rather than part of the API layer. So if another WebKit-based application or another port wanted to do multiprocess based on Chromium WebKit, it would be necessary to reinvent or cut & paste a great deal of code.
That was an understandable choice for Google - Chrome was developed as a secret project for many years, and is deeply invested in this approach. Also, there are not any other significant API clients. There is Google Chrome, and then there is the closely related Chrome Frame.
WebKit2 has a different goal - we want process management to be part of what is provided by WebKit itself, so that it is easy for any application to use. We would like chat clients, mail clients, twitter clients, and all the creative applications that people build with WebKit to be able to take advantage of this technology. We believe this is fundamentally part of what a web content engine should provide.
Internals
There are two key subsystems that support the process division :
- CoreIPC - an abstraction for general message passing, including event handling. The current implementations use mach messages on Mac OS X, and named pipes on Windows.
- DrawingArea - an abstraction for a cross-process drawing area. Multiple drawing strategies are possible, the simplest is just a shared memory bitmap.
There are two other important abstractions, which may be pushed down to WebCore or WTF over time:
- Run Loops
- Work Queues
Current Status
WebKit2 should be considered an early technology demo. It is not yet production quality. But it's possible to try it out and see how it works at this early stage.
How to try it Out
build-webkit의 맥과 윈도우버전은 이제 WebKit2를 디폴트로 빌드한다. WebKit2는 Safari에 탑재되지 않았다. WebKit2를 테스트하려면 Tools/MiniBrowser로 해야 한다.
How to run layout tests
WebKit2를 테스트하려면 layout test에 "-2" 또는 "--webkit-test-runner" 옵션을 주어 다음처럼 실행한다.
run-webkit-tests --debug -2
많은 테스트가 무시될것인데 지속적으로 그 수는 줄어들것이다.
