여러 회사가 이미 WebKit에서 Chromium으로 옮겨갔다. Qt가 Chromium을 기반으로 웹엔진을 개발하겠다고 발표해서 WebKit Community가 좀 시끄러웠다. Google이 Apple보다는 개방적으로 프로젝트를 운영하기 때문에 이러한 현상은 계속될 것 같다. Google에는 Chromium 관련 내부 mailing list 조차 없다고 하니, 열린 개발 방식이 얼마나 무서운지 새삼 느낄 수 있었다. 이제 Chromium Project가 모든 것을 다 빨아들이고 있다. 여기 승선하지 못하면 왠지 뒤떨어진다는 느낌을 갖게 되는 것도 무리는 아닌 것 같다.
이번 Conference에서 소개된 Blink 현황과 기술적인 내용을 살펴보자.
먼저, Blink의 성능 향상과 위한 노력이 진행중이다. 성능은 Parsing, DOM, HTML, SVG, CSS 처리, Style resolution, Layout, Rendering 등등 전반적으로 모든 부분에서 개선 중이다. Blink내 Web Engine이 가져야할 핵심 기능이 아닌 Platform관련 코드 (예, keycode 변환), Networking(예, WebSocket Protocol), Rasterization 코드를 제거할 계획이다.
이외에 Chromium과 Blink의 모둘화 작업도 진행중이며, Blink와 V8의 garbage collection기능을 통합할 계획이다. Blink는 WebKit과 같이 Smart Pointer를 사용했는데, 이 부분이 모두 변경될 것 같다.
- Layout과 Style resolution을 parallel로 처리
- iframe을 별도의 process에서 실행
- Editing과 XSLT를 JS로 구현?
- Übercompositor 적용( UI와 Web Content를 Browser process에서 한번에 compositing하기) 등등
많은 시도들이 앞으로 일어날 예정이다.
Mobile과 관련된 Session이 하나 있었는데, Android Blink가 Desktop가 다른 점와 Mobile 환경의 여러 제약점, 빌드 방법 등을 소개하였다.
Android Blink는 platform코드 일부가 Java로 코딩되어 있어서 JNI로 Blink로 연결되어 있다. Mobile기기는 core개수, memory크기, GPU성능이 많이 뒤지지만 사용자는 초당 60FPS의 성능을 요구하기 때문에 여러가지로 어려운 상황이다. 프로세스를 많이 만들수도 없고 cache memory를 넉넉하게 사용할 수도 없다. Network도 안정적이지 않고 비용이 든다. 그렇기 때문에, mobile은 특히 Chromium에게는 도전적인 부분이다. 이미 WebKit 기반의 Safari는 mobile에 많이 최적화되어 있지만, Chrome이 이제 시작 단계이다.
Performance 관련해서 Trace Event Profiling Tool이 소개되었는데, 아주 흥미로웠다. 툴을 이용해서 병목 지점을 찾고 code까지 고치는 것을 보여주었다. 특히, frame viewer를 이용해서 Skia paint를 단계별로 replay할 수 있는 기능까지 제공한다.
Rendering관련해서, 사실 Blink가 fork한 WebKit코드는 10년의 역사를 갖고 있고 계속 기능이 추가되다 보니 몇 개의 주요 class의 경우 코드 길이가 매우 길다. RenderBlock이 6.8k, RenderBox가 4.7K이고 RenderLayer의 경우 HW 가속 및 svg관련 코드를 포함하고 있다. 또한 repaint도 불필요한 repaint를 줄이기 위해 최적화가 필요하다. 예로 table의 경우 여러번 다시 그리는 경우가 많다고 한다. 일부 웹사이트는 CSS 파일 크기도 커서 thread CSS parser를 도입할 필요가 있고, RenderStyle Cache 종류도 많고 복잡도가 높아서 개선이 필요하다고 한다.
Editing은 WebKit에서 독립하면서 maintainer가 없었는데, 이번에 새로 맡은신 분이 Editing 현황을 잘 소개해주었다. 연세가 지극하신 개발자인데, 유머있는 발표가 인상적이였다. 사실, WebKit/Blink의 모든 코드를 다 이해하는 사람은 없다. 특히, Editing부분 소수의 사람만이 이해하고 있는 다소 복잡다고 높고 버그가 많다고 알려져있지만, 발표자는 전혀 그렇지 않으니 많이 기여하라고 이야기해주었다. 재밌는 것은 Rich Edit 기능을 JS로 구현할수도 있다는 사실이다. Web Engine의 일부 기능을 JS로 구현하는 것은 성능이나 메모리 사용 때문에 주저할 수도 있겠지만, 복잡도가 높아서 Engine에서 분리할 수 있다면 나쁘지 않은 선택일 수도 있다.
Open Source 개발자에게 특히 외부 contributor에게는 뭔가 일할 부분을 찾는 것이 쉽지 않다. 그냥 보면 모두 완벽해 보이기 때문이다. 하지만 이런 자리에서 문제점을 확인하고 뭔가 기여할 만한 부분을 찾는 것은 굉장한 소득이다. 그리고, 내 patch를 review한 개발자와 만나 앞으로 개발 방향을 듣고 의견을 나누는 일도 좋았다.
여전히 웹은 진화 발전하고 있다. 이럼 흐름에 직접 기여할 수는 기회를 갖게 되어 기쁘다.
여전히 웹은 진화 발전하고 있다. 이럼 흐름에 직접 기여할 수는 기회를 갖게 되어 기쁘다.
