Naver Tech Concert Day-2

04. 안드로이드 웹뷰의 모든것

  • 발표자 : 이형욱 (NAVER / Whale Core)

  • 동영상 : https://tv.naver.com/v/4635576/list/272653

  • 슬라이드 : https://www.slideshare.net/NaverEngineering/24-121486425

  • 세션설명 : 안드로이드에서 웹컨텐츠를 렌더링 하는데 많이 사용하고 있는 웹뷰의 동작 원리 대한 설명과 이를 바탕으로 한 웹 성능 최적화를 위한 여러가지 툴 사용법을 설명하는 세션입니다.

  • 목차 :

    1. History of Android WebView

2. Summary of how browsers work

3. Rendering pipeline overview

4. How chromium makes a frame?

5. VSync aligned touch input & frame output

1. Android WebView overview

1.1 안드로이드 웹뷰란?

안드로이드에서 제공하는 뷰

사용하는 케이스

  • 안드로이드 기본 브라우저에서 사용
  • 앱에서 거의 대부분의 배너 광고에서 사용
  • 웹(HTML) 기반 앱에서 사용
  • 안드로이드 네이티브 뷰와 함께 사용

혹자는 안드로이드에 숨어있는 제 3의 플랫폼이다 라고도 함.

1.2 안드로이드 웹뷰의 역사

J(젤리빈 / 4.1 / API 16~18) 이하

custom WebKit-based "classic" WebView

K(킷캣 / 4.4 / API 19)

Chromium 30/33-based WebView

L(롤리팝 / 5.0 / 21) 이상

Unbundled Evergreen WebView

1.3 안드로이드 웹뷰와 파편화

  • 안드로이드 제조사에서 경쟁적으로 WebKit을 Customization

  • 안드로이드 버전별 서로 다른 WebKit 사용

    • Android 4.3 이전 버전은 WebKit 기반의 렌더링 엔진을 사용
    • Android 4.4 부터는 Blink 기반의 렌더링 엔진으로 교체

  • 현재는 사용자 웹뷰 업데이트 유무에 따라 서로 다른 버전을 사용 (앱 업데이트 없이도 이슈 생길 수 있음)

1.4 WebKit 브라우저 엔진의 역사

KHTML, KJS(1999.05 ~)

Apple Forks KHTML, KJS in 2001 -> WebKit (2001 ~), Open Source in 2005

Google Forks WebKit in 2013 -> Blink (2013.04 ~)

Webkit을 2008년 크롬 브라우저에서 사용하면서부터 유명해짐.

구글에서 개발인력이 더 늘면서 Blink로 포크 뜨게 됨.

1.5 안드로이드 웹뷰의 구조

Blink 엔진의 구조도

크로미움에서 브라우저 프레임워크 및 컴포넌트를 제공하며, 이를 브라우저 앱들이 사용함.

1.6 크롬과 크로미움의 차이점

크로미움 : 오픈소스

크롬 : 크로미움으로 상품화, 유료 비디오 코덱, 어도비 플래시, QA

2. How chromium works

2.1 브라우저는 어떻게 동작하는가?

크로미움은 브라우저 엔진으로, HTML을 처리하여 화면에 렌더링 역할.

HTML, CSS, JS를 입력으로 받아 파싱하여 렌더링함.

2.2 HTML Parser

<html>
   <head>
       <title>NAVER</title>
    </head>
    <body>
        <div>
            <h1>Hello</h1>
            <p>World</p>
        </div>
    </body>
</html>

DOM : Document Object Model

  • Docuement = HTML, well-formed XML
  • Object Model = Data + Method

DOM Tree로 만들어 놓으면 가공하기가 쉬워짐.

2.3 CSS Parser

body { font-size:16px }
p { font-weight: bold }
span { color:red }
p span { display:none }
img { float:right }

CSSOM : CSS Object Model

  • DOM 과 비슷하게 CSS도 CSSOM이 있음
  • CSS는 HTML Element의 스타일을 정의
  • 외부 링크로 정의된 경우 렌더링이 블로킹 됨
  • Cascade down 개념을 구현하기 위해 트리 구조 (상속개념)

2.4 Java Script Engine

구글에서 포크 뜨면서 자바스크립트 엔진을 다르게 썼었음.

  • 웹킷 : JSC (JavaScript Core)
  • 구글 : V8

두 엔진이 한동안 다르게 동작하였으나, 현재는 위 그림대로 동작하게 됨.

2.5 Render Tree

Rescalculate Style의 결과

  • Render Tree = DOM Tree + CSSOM Tree
  • DOM Tree와 Render Tree는 1:1 관계가 아님
  • 화면에 보이는 요소들을 중심으로 정리 (HEAD나 아래의 p span 등은 안보이는 요소라 트리에 없음)
body { font-size:16px }
p { font-weight: bold }
span { color:red }
p span { display:none }
img { float:right }

2.6 Layout

렌더링 전에 레이아웃팅(좌표 계산)을 거쳐야 함.

Layout 알고리즘

  • 각 박스의 넓이는 viewport (ICB) 기준
  • 각 박스의 높이는 contents (fonts)를 기준
  • 윈도우 사이즈를 변경하거나 폰트 변경시 Global Layout
  • Dirty bit system으로 incremental layout

2.7 Paint

결정된 레이아웃팅 결과를 가지고 페인팅.

브라우저의 페인팅은 프린트와 유사함. 굉장히 오래 걸리고 로드가 많이 걸리는 잡임.

2.8 VSync 기반 멀티 쓰레드 렌더링

브라우저도 안드로이드와 마찬가지로 VSync 기반으로 렌더링함. (16.6ms 내에 한 프레임을 찍어야 함)

현실은 요새 같이 웹이 표현할게 많고 고도화된 상태에서 60FPS 한 프레임에 표현하기 어려워짐.

크로미움쪽은 Compositor Thread를 도입함. (빠르게 스크롤시 흰 화면이 보이는 경우가 해당됨)

Raster Thred도 도입됨.

기존에 메인 스레드에서만 할 수 있는 Paint에서 Draw를 직접 안하고 Recording만 하고,

Raster에서 Bitmap만드는 과정을 분리하여 처리함.

안드로이드에서 2D 그래픽스를 담당하는 오픈소스.

크로미움에서도 사용 중.

3. How chromium powered WebView works

3.1 안드로이드에서 크로미움은 어떻게 동작하는가?

크로미움 브라우저는 멀티프로세서 기반의 브라우저.

UI 담당하는 프로세스와 렌더링를 담당하는 프로세스, GPU를 담당하는 프로세스 등 4가지 프로세스 구성

  • Browser 프로세스 : 크롬 액티비티 등이 동작하는 앱 프로세스.
  • Renderer 프로세스 : 안드로이드 서비스를 활용한 UI가 없는 프로세스. 렌더링이나 로케이팅 등 처리.
    • 보안에 취약하기 때문에 샌드박싱 되어 있음. (메모리와 CPU 리소스만 사용함)
  • GPU 프로세스 : CPU 자원을 접근해야 해서 샌드박스가 안되어 있음.
  • OS Winodw system : 안드로이드 SufaceView를 사용해 브라우저 화면을 렌더링함.

3.2 웨일 브라우저의 뷰 구조

SurfaceView만 사용하는 것은 아님.

3.3 크로미움 웹뷰의 구조적 차이점

Graphics components

  • Whale (Chrome)

    • SufaceView 사용 : 렌더링 성능을 위함. 자체적인 렌더링 싸이클을 가짐. (안드로이드 뷰보다 빠름)
    • Vsync based rendering
    • Async uploads using EGLImage and glTexSubImage2D() (OpenGL 함수들 사용)

  • Chromium powered webview

    • "Draw functor" : inject draw calls into system GL context

      • 안드로이드에서 하드웨어 엑셀레이션 동작시 HWPUI가 동작함. 안드로이드 뷰를 호출해 렌더링함.

        이를 Draw functor에 위임하게 됨.

    • Android based rendering

    • Private API. The WebView injects a callback onto the display list. (일반적인 웹뷰에선 못 씀.)

Architecture

  • Whale (Chrome)

    (Multi-process)

    • UI thread
    • GPU Process
    • Texture upload thread
    • Per renderer process :
      • Blink thread
      • Compositor thread
      • Raster thread

  • Chromium powered webview

    (Single-process/Multi-process)

    • Combined UI + Compositor thread
    • Android RenderThread (+ in-porcess GPU thread)
    • Canvas/WebGL GPU thread
    • Blink thread
    • Raster thread

큰 차이는 Compositor thread가 Whale(Chrome)의 경우 독립적이나 Chromium의 경우 UI thread와 합쳐짐.

(Chromium의 경우 View이기 때문에)

3.4 안드로이드 렌더링 파이프 라인 (KitKat 4.4 이하)

KitKat까지는 메인 쓰레드에서 렌더링함.

메인 쓰레드에선 보통 I/O를 담당해서 빠르게 처리하게 하는데, 렌더링도 메인 쓰레드에서 했지만 메인 쓰레드에서 할 일이 너무 많아짐.

3.5 크로미움 웹뷰 렌더링 파이프 라인 (KitKat 4.4 이하)

onDraw시 Private API인 DrawFunctor를 통해 함수 포인트를 연결해 하드웨어 캔버스가 호출됨.

그리고 콜백이 호출되어 Record, Raster, Composite 들이 돌게 됨.

KitKat까지는 Composite를 메인 쓰레드에서 하느라 좋은 구조는 아니었음.

3.6 안드로이드 렌더링 파이프 라인 (Lollipop 5.0 이상)

렌더 쓰레드가 도입됨. (크로미움의 Raster 쓰레드와 비슷함.)

크로미움과 안드로이드의 기술 발전 흐름은 유사함. (크로미움에서 괜찮으면 안드로이드에도 적용되는 느낌)

3.7 크로미움 웹뷰 렌더링 파이프 라인 (Lollipop 5.0 이상)

onDraw 때 Record와 Raster 쓰레드만 돌고 메인 쓰레드는 거의 안돌게 됨.

Render 쓰레드에서 플레이백하여 Composite하는 구조가 됨.

메인 쓰레드가 많이 Free해짐. 성능 좋아짐.

이 때부터 unbundled임. (AOSP에 없음. 크로미움 참조해야 함.)

쓰레드가 많아져서 쓰레드간 동기나 제어가 중요함.

크로미움엔 스케쥴러 모듈이 있어 메인 쓰레드에서 제어 및 스케쥴링을 하게 됨.

크로미움 웹뷰의 완성도가 많이 올라갔고, HTML5도 많이 지원하게 됨.

'IT > 행사' 카테고리의 다른 글

[행사] Naver Tech Concert Day-2 06  (1) 2019.01.14
[행사] Naver Tech Concert Day-2 05  (0) 2019.01.14
[행사] Naver Tech Concert Day-2 03  (0) 2019.01.14
[행사] Naver Tech Concert Day-2 02  (0) 2019.01.14
[행사] Naver Tech Concert Day-2 01  (0) 2019.01.14

+ Recent posts

티스토리툴바