알아봅시다, Polymer: Web Components & Web AnimationsChang W. Doh
GDG Korea WebTech : 시작하세요, Polymer, Oct, 11, 2014.
Let's learn about specifications before diving into Polymer:
- Web Components
- Web Animations
This slide includes resources from HTML5Rocks, Polymer and PolyTechnic.
[NAVER D2]html5 canvas overview
HTML5 Canvas 소개 및 특징
- 소개 및 지원브라우저
- CanvasRenderingContext2D
- 즉시모드 / 보류모드
- Mouse Event 처리
Canvas 로 할 수 있는 것
- Drawing Shape
- Pixel Manipulation
- Animation
Canvas와 WebGL
Canvas와 Flash
Cavnas 적용사례
알아봅시다, Polymer: Web Components & Web AnimationsChang W. Doh
GDG Korea WebTech : 시작하세요, Polymer, Oct, 11, 2014.
Let's learn about specifications before diving into Polymer:
- Web Components
- Web Animations
This slide includes resources from HTML5Rocks, Polymer and PolyTechnic.
[NAVER D2]html5 canvas overview
HTML5 Canvas 소개 및 특징
- 소개 및 지원브라우저
- CanvasRenderingContext2D
- 즉시모드 / 보류모드
- Mouse Event 처리
Canvas 로 할 수 있는 것
- Drawing Shape
- Pixel Manipulation
- Animation
Canvas와 WebGL
Canvas와 Flash
Cavnas 적용사례
[111015/아꿈사] HTML5를 여행하는 비(非) 웹 개발자를 위한 안내서 - 1부 웹소켓.sung ki choi
ajax 등장 이전부터, ajax, comet, 그리고 html5의 웹소켓까지 기술의 흐름을 간략하게 정리해 보았습니다.
웹 어플리케이션의 개발을 다뤄보지 않은 개발자들을 대상으로 처음부터 웹소켓을 다루기 전에,
1. 이전 세대의 통신 기법은 어떤 모양이었는지
2. 웹소켓이 왜 환영받을 만한 기술인지
... 등을 공감할 수 있기 위한 목적으로 PT를 작성 하였습니다.
어느 해커쏜에 참여한 백엔드 개발자들을 위한 교육자료
쉽게 만든다고 했는데도, 많이 어려웠나봅니다.
제 욕심이 과했던 것 같아요. 담번엔 좀 더 쉽게 !
- 독자 : 백엔드 개발자를 희망하는 사람 (취준생, 이직 희망자), 5년차 이하
- 주요 내용 : 백엔드 개발을 할 때 일어나는 일들(개발팀의 일)
- 비상업적 목적으로 인용은 가능합니다. (출처 명기 필수)
MEAN 스택을 사용한 IoT 개발 예제를 설명합니다.
* MEAN 스택 기본 내용 소개
* Node.js와 Express를 활용한 간단한 CRUD 서버 작성 방법(아주 단순하지만 (인증을 제외한 나머지) RESTful 서버의 기본 내용을 구현함)
* MongoDB와 Mongoose ODM를 사용한 영속적인 자료 저장 방법
* AngularJS를 사용한 아주 간단한 모니터링 도구 구현(하지만 의존성 주입, 양방향 자료 결합, 라우팅 활용 방법이 모두 들어 있음)
* 모든 예제는 bitbucket(git 호스팅 서비스)에 공개되어 있음
Polymer의 기술기반인 Web Componets를 구성하는 표준 스펙들인 Custom Elements, HTML Imports, HTML Templates 그리고 Shadow DOM을 간략히 살펴본다.
Polymer의 아키텍처 및 기본적인 사용방법 그리고 material design이 적용된 paper elements 등을 살펴본다.
[111015/아꿈사] HTML5를 여행하는 비(非) 웹 개발자를 위한 안내서 - 1부 웹소켓.sung ki choi
ajax 등장 이전부터, ajax, comet, 그리고 html5의 웹소켓까지 기술의 흐름을 간략하게 정리해 보았습니다.
웹 어플리케이션의 개발을 다뤄보지 않은 개발자들을 대상으로 처음부터 웹소켓을 다루기 전에,
1. 이전 세대의 통신 기법은 어떤 모양이었는지
2. 웹소켓이 왜 환영받을 만한 기술인지
... 등을 공감할 수 있기 위한 목적으로 PT를 작성 하였습니다.
어느 해커쏜에 참여한 백엔드 개발자들을 위한 교육자료
쉽게 만든다고 했는데도, 많이 어려웠나봅니다.
제 욕심이 과했던 것 같아요. 담번엔 좀 더 쉽게 !
- 독자 : 백엔드 개발자를 희망하는 사람 (취준생, 이직 희망자), 5년차 이하
- 주요 내용 : 백엔드 개발을 할 때 일어나는 일들(개발팀의 일)
- 비상업적 목적으로 인용은 가능합니다. (출처 명기 필수)
MEAN 스택을 사용한 IoT 개발 예제를 설명합니다.
* MEAN 스택 기본 내용 소개
* Node.js와 Express를 활용한 간단한 CRUD 서버 작성 방법(아주 단순하지만 (인증을 제외한 나머지) RESTful 서버의 기본 내용을 구현함)
* MongoDB와 Mongoose ODM를 사용한 영속적인 자료 저장 방법
* AngularJS를 사용한 아주 간단한 모니터링 도구 구현(하지만 의존성 주입, 양방향 자료 결합, 라우팅 활용 방법이 모두 들어 있음)
* 모든 예제는 bitbucket(git 호스팅 서비스)에 공개되어 있음
Polymer의 기술기반인 Web Componets를 구성하는 표준 스펙들인 Custom Elements, HTML Imports, HTML Templates 그리고 Shadow DOM을 간략히 살펴본다.
Polymer의 아키텍처 및 기본적인 사용방법 그리고 material design이 적용된 paper elements 등을 살펴본다.
2022년 11월 18일 코엑스에서 개최한 공공솔루션마켓에서 발표한 강연 자료입니다.
디지털 전환이 가속화됨에 따라 더욱 중요해진 디지털 경험 모니터링과 장애 및 병목 등 성능을 개선한 실 사례를 공유드립니다.
생생한 강연 영상으로 확인해 보세요!
https://youtu.be/_Cdms2TxO3M
모바일 앱 성능 분석 방법 101 (Mobile Application Performance Analysis Methodology 101) YoungSu Son
모바일 앱 성능 분석 방법에 대해서 설명을 드립니다
- 기존 서버 APM과 모바일에서의 성능 기준의 차이
- 모바일 제약사항및 아키텍처
- 안드로이드는 어떻게 발전해 왔나
- Vectorization
- Loop
- Redex / Optimized Layout
- Garbage Collector
- 제조사가 보장해야 되는 성능
- 개발사가 고민해야 되는 영역
- 실사례 설명
- 갤럭시노트 2의 점유율
- Xiaomi 폰의 국내 4위 시장 점유율
- 여러가지 모바일 성능 리포트
커지고 있는 웹 애플리케이션에서 성능은 점점 더 중요한 요소가 되고 있습니다. 사용자와의 접점에서 긴밀한 상호작용을 요구하는 프런트엔드, 보다 빠르게 로딩되고 부드럽게 구동되어야 하는 웹 애플리케이션을 만들기 위해 노력하는 분들과 함께 이야기를 나눕니다.
목차
1. 로딩 최적화 방법
2. PWA 케이스 소개
3. 렌더링 최적화 방법
대상
- 프런트엔드 성능 개선을 시작하고 싶은 개발자
- 느린 웹 페이지를 빠르게 만드는 데 관심 있는 프런트엔드 개발자
- 로딩/렌더링 최적화에 대한 힌트를 얻고 싶은 개발자
GDG DevFest 2017 - Inspections of Kotlin implementations by Bytecode.
세션 이후 "Kotlin은 Java의 wrapper인가요?" 라는 질문을 몇번 받았습니다.
—
답변: 그렇지 않습니다.
특정한 언어로 구현된 코드는 파싱을 거쳐 추상화된 형태(AST)와 추가 정보들을 가지는 1차적인 결과물로 처리됩니다. 보통 이런 역할을 하는 것은 컴파일러에서 전단부(frontend)라고 호칭하며 이러한 AST 등의 결과물은 대상 머신이나 플랫폼에 맞추어 처리됩니다.
이를 바로 실행하면 인터프리터라고 하지만, 실행 가능한 형태(Executable)로 생성하는 경우라면 컴파일러 후단부(Backend)가 이를 수행합니다.
백엔드의 타겟 코드는 충분히 다양한 대상을 다룰 수 있으므로, 우리가 다양한 백엔드 구현을 통해 동일 코드를 멀티 플랫폼을 대상으로 실행할 수 있도록 할 수 있는 것입니다.
코틀린 역시 대상으로 하는 플랫폼(과 머신)은 현재 다음과 같은 실행 가능한 형태를 지원하고 있습니다. (물론 아직 모든 타겟이 완벽하지는 않겠죠.)
1. Bytecode 포맷에 따른 JVM(안드로이드 포함)
2. JavaScript에 의한 브라우저나 Node.js
3. llvm을 이용하여 여러 타겟의 네이티브 코드
이 자료는 이 중 1번을 기반으로 디컴파일된 코드를 살펴보고 코틀린의 코드 생성 목적이나 언어 설계의 원인(어떤 painpoint)를 찾아보는 과정의 일부였을 뿐입니다.
언어는 항상 요구되는 표현을 위해 가장 적합한 형태로 변화해나갑니다. 프로그래밍 언어는 비교적 단기간에 만들어지는 언어이고, 그에 따라 특정 사람과 집단의 목적에 충실합니다. 다만, 이 관점에서 봤을 때도 Kotlin이 Java의 wrapper로써 설계되었을 것보다는 다양한 타겟 플랫폼이 고려되고 있는 하나의 프로그래밍 언어로 받아들여 주시기를 바랍니다. :)
2016년 11월 5일 있었던 GDG DevFest 2016 Seoul 행사에서 진행된 `Boot Camp: 초보 개발자를 위한 웹 프론트엔드 개발 101` 워크숍의 소개 부분 슬라이드입니다.
- 행사 URL: https://festi.kr/festi/gdg-korea-2016-devfest-seoul/program/92/
Instant and offline apps with Service WorkerChang W. Doh
2 parts of talking at Google Developer Summit 2016 Seoul
- How to optimize loading performance your web app
- Introducing to Service Worker & Offline 101
24. 20년 전의 렌더링 파이프라인
우리가 말하는 비디
오 메모리
버텍스가 모여서
폴리곤에
텍스쳐를 입혀서
디스플레이 이미지로
25. 하드웨어 가속 렌더링의
성능 최적화를 위한 첫걸음:
GPU가 잘하는 것과 못하는 것의 이해
26. GPU가 잘하는 것
“GPU는 수신된 데이터로 무언가를 그리는데 적합”
1. 텍스쳐를 가지고 이미지를 빠르게 출력 가능
2. 이미 가진 텍스쳐는 다시 받지 않고 재활용
3. 회전, 확대, 축소, 기울임, 반투명 처리 등
4. 위 기능들의 동시 처리하는 것도 매우 최적화
28. 비디오 메모리로의 데이터 전송 속도
FACT> “비디오 메모리로의 데이터 전송은 느림”
CPU
Main Memory
GPU
Video Memory
BUS
29. 이슈: 비디오 메모리로의 전송 속도
“데이터 전송 시간 = 데이터의 크기 / BUS 속도”
● 일반적으로 예상되는 데이터 크기:
o GPU 명령 < 버텍스 < 텍스쳐 이미지
30. 더 큰 이슈: CPU 처리 시간
FACT> “GPU의 데이터는 CPU에서 생성 후 전송”
CPU
데이터
GPU
2 VRAM
1
3
렌더링
예> 코드에 의해
텍스쳐로 사용될
이미지를 생성
즉, 렌더링의 관점에서 GPU에서 사용될 데이터를 새로 만들어서 이를 전송하는 과정은 하나의 과정!
31. 중간 점검: 렌더링 성능의 주요 인자
1. GPU는 회전/확대/축소/기울임/반투명 처리 등에 최적화
a. 이 범주의 기능으로 렌더링이 처리될 수 있도록
2. GPU에서 사용할 데이터를 준비하는 것은 CPU의 몫
a. CPU가 새로운 데이터를 만드는 작업은 최소화
3. CPU가 준비한 데이터는 비디오 메모리에 전송 필요
a. 데이터의 전송을 최소화할 수 있도록...
34. 크롬의 렌더링
1. 웹 페이지는 파싱을 통해 DOM 트리로 해석되어 메모리에 적재
2. DOM 트리를 렌더링 트리로 생성 후 각 노드들을 개별적인 이미지로 생성
3. 트리 구조 및 스타일에 따라 이미지를 배치 및 합성하여 출력
35. 레이어 모델
레이어(Layer)?
웹페이지를 렌더링하기 위해 필요한 이미지 단위의 요소
● 각 레이어는 최종적으로 표현될 이미지를 생성하는 단위
● 생성된 이미지는 텍스쳐로서 GPU에 업로드
● 레이어들을 배치/합성하여 최종적인 웹페이지 표현
NOTE!
● 레이어의 이미지는 CPU에서 생성!
o 즉, 레이어에서 생성되는 이미지는 CPU 시간 소모!
4개의 레이어로 이루어진 웹 페이지의 예
37. 이슈: Reflow
● Reflow = Layout = Layouting
o DOM 노드가 가지는 레이아웃 정보(Geometry)가 변경되
면 레이아웃은 재배치를 위한 계산이 필요
Header
DIV
Footer
Header
DIV
Footer
38. 이슈. Reflow로 발생할 수 있는 일
Node Node
Node
Node
Node#A
Node
Node#A
{
border: 30px;
}
Invalidate Invalidate
Invalidate
1. 레이아웃의 변경이 트리를 따라 전파 (CPU)
2. 많은 경우 레이어 이미지의 갱신 필요 (CPU)
3. 레이어 이미지가 변경되면 VRAM의 텍스쳐 갱신 필요 (RAM to VRAM Bandwidth!!!)
INVALIDATE!!
39. 이슈: Repaint
● Repaint = Redraw
o 레이아웃 내 컨텐츠가 변경 시 텍스쳐를 새로 생성 필요
CPU
데이터
GPU
2 VRAM
1
3
렌더링
이 그림 기억하십니까?
40. 이슈: Reflow/Repaint 발생 요인
● DOM 노드의 동적인 추가/삭제/업데이트
● DOM 노드의 감춤/표시
o display: none
o visibility: hidden
● DOM 노드의 이동, 애니메이션
● 스타일시트의 추가 혹은 스타일 속성의 변경
o 미디어 쿼리 역시
● 브라우저 사이즈 변경
● 폰트 변경
● 스크롤
● …
42. 정리: 크롬에서의 전반적인 렌더링 흐름
1. DOM으로부터 노드들을 개별적으로 혹은 그룹 지어 레이어 단위들로 분리
2. 레이아웃을 계산하고 각 레이어들이 그려져야 할 영역의 크기 위치 등을 계산
a. 위치/크기 정보 등을 계산하기 위한 CPU의 계산 오버헤드가 발생
3. 레이어들 각각은 렌더링을 위해 비트맵으로 출력
a. CPU에서 레이어 이미지를 생성하는 오버헤드가 발생
4. 생성된 비트맵을 GPU에 텍스쳐로 업로드
a. GPU의 비디오 메모리로 전송하는 오버헤드는 발생
5. 계산된 레이아웃으로 레이어의 텍스쳐 이미지들을 최종 스크린 이미지로 합성
44. 최적화에 대한 그래픽 모듈의 구현 관점
● 네이티브 어플리케이션 관점:
o 최대한 가벼운 렌더링 프로세스의 구성이 목적
> 3D 혹은 2D 게임 개발의 예
“이번 게임은 꽤 그래픽 출력이 많기 때문에 CPU와 GPU 사이의 병목 구간을 최소
화할 수 있도록 텍스쳐의 생성/업로드를 병목 구간 전에 미리 처리하고, 텍스쳐 캐싱
정책을 블라블라한 모델에 따라 관리하도록 모듈을 !@#!@$ 하게 작성합니다.
또한 우리 게임에서 특별하게 발생할 몇몇 상황에도 이러한 렌더링 모듈에 대한 커스
텀 구현으로 이를 회피할 방법을 찾을 수 있을 것입니다.” - A개발팀장의 커피톡
45. 웹 페이지에서의 렌더링 최적화는...
● 빠른 렌더링 패스를 구현하는 것이 아니다!!!
o 렌더링 패스는 철저하게 브라우저의 영역
o 웹 렌더링 성능 최적화는 만드는 것이 아니라 병목 구간의 발
생 요인을 피해가는 것!
● 피해야 할 성능의 위험 인자
o CPU에서 텍스쳐 이미지를 생성하는 요인들
o 가급적이면 레이아웃 변경의 요인도!!
46. 가장 간단한 Hack: 레이어의 분리
크롬에서 DOM 노드가 레이어로 분리되는 조건들
1. 3D 혹은 Perspective를 표현하는 CSS transform 속성을 가진 경우
2. 하드웨어 가속 디코딩을 사용하는 <video> 엘리먼트
3. 3D 컨텍스트 혹은 하드웨어 가속 2D 컨텍스트를 가지는 <canvas> 엘리먼트
4. (플래시와 같은) 플러그인 영역
5. 투명도(opacity) 속성 혹은 transform 애니메이션의 사용
6. 가속 가능한 CSS 필터를 가진 경우
7. Compositing Layer를 하위 노드로 가진 경우
8. 낮은 z-index를 가진 형제 노드가 Compositing Layer를 가진 경우
47. 가장 간단한 Hack: 레이어의 분리
분리 조건 요약: 해당 DOM 노드가 주변 노드와는 별도로 렌더링되어야 빠른 경우
예1> 투명도(Opacity): 겹쳐진 다른 이미지와 픽셀 단위의 블렌딩(Blending)되는 경우.
하지만 애니메이션에서만 성능 이슈가 발생하므로 애니메이션일 경우만 분리
예2> 매번 표시되는 프레임이 변경되는 <video> 엘리먼트.
개발자의 Hack! translateZ(0);
● translateZ(0);는 노드의 Z축 값으로 0을 주는 무의미한 코드
● 그러나 레이어 분리 조건의 첫번째 항목에 해당
48. 강제적인 레이어 분리가 만능은 아니다!
● 왜?
o 레이어 분리는 필연적으로 텍스쳐 이미지 분리를 의미
§ 추가적인 메모리 소모
o 메모리는 유한하다!
§ 메모리 공간 부족 시 기존 데이터 릴리즈 후 새로운 데이터의 업로드
● 최악의 경우가 반복되면...
§ 레이어 분리를 통한 성능 이점을 송수신 오버헤드로 상쇄
● 따라서, 레이어 분리는 최소화 필요!!!
49. 하드웨어 가속으로 얻는 성능은
절대로 공짜가 아님! :)
모든 것에 가능성을 두고 확인!
50. References
1. 브라우저는 어떻게 동작하는가.
2. 크롬의 렌더링 가속: 레이어 모델
3. GPU Accelarated Compositing in Chrome
4. Scrolling Performance
5. Jank Busting for Better Rendering Performance
6. CSS 페인트 타임과 페이지 렌더 가중치
7. 불필요한 페인팅 회피하기
8. 불필요한 페인팅 회피하기: Animated GIF 버전
9. 고성능 애니메이션
10. Rendering: repaint, reflow/relayout, restyle
11. How (not) to trigger a layout in WebKit
62. Mission Impossible:
● Truely controlling offline resources
o Application Cache? OMG!
o Everything managed by your webbrowser!
● Plus, background processing
o Remote Push Notification, Alarm, Background-update
of resources, ...
o Everything run on your webpage!
63. ‘ServiceWorker’ solves...
● Truely controlling offline/network stack
o Programmable cache control
o Custom response
● Plus, background processing
o Remote Push Notification
o Task Scheduler(e.g. Local Notification)
o BackgroundSync
o ...
65. Overview: Service Worker
● Event-driven scripts
o that run independently of web pages
● ServiceWorker has
o Access to domain-wide events such as network
fetches
o scriptable caches
§ The ability to respond to network requests
from certain web pages via script
§ A way for applications to "go offline"
70. What can we do with ServiceWoker?
● Eliminating loading time
o Developer knows what is most important resource in
our webpages.
§ We can control ‘request/response flow’ and
‘cache’ with ServiceWorker.
§ and Front-end developers just write their code
without other libraries to control data-flow.
o Your page will be loaded in an instant!!!
● Other features come and see us soon. :)
73. this.addEventListener("fetch", function(e) {
var request = e.request;
if (this.scope.indexOf(request.origin) == -1) { return; }
// Basic read-through caching.
e.respondWith(
caches.match(request, "core").then(
function(response) { return response; },
function() {
// we didn't have it in the cache, so add it to the cache and return it
return caches.get("core").then(
function(core) { log("runtime caching:", request.url);
// FIXME(slighltyoff): add should take/return an array
return core.add(request).then(
function(response) {
return response;
});
// ...
74. References
1. ServiceWorker first draft published
2. Specification
3. Explainer
4. Implemetation Considerations
5. Service Workers: Bring your own magic
6. Topeka Demo @Google I/O 2014
7. webapplication.kr