"현재의 네이티브 앱들의 기능과 유사한 형태의 웹 어플리케이션을 구현할 때 가장 난해한 부분은 어떤 것일까요? 아마 그래픽스, 성능, 네트워크 등 다양한 의견이 나오리라 생각됩니다만, 단언컨데 현재 가장 어려운 부분 중의 하나는 오프라인입니다. 서비스워커는 브라우저 측에서 동작하는 이벤트 기반의 시스템 Worker입니다. 이를 이용하여 오프라인 앱을 위한 리소스 관리, 원격 푸시 등을 직접 관리할 수 있습니다. 네이티브 어플리케이션에서는 일반화되어 있는 개념이기도 하지만 기존의 웹 개발에 익숙한 분들에게는 생소한 접근일 수 있습니다만 반드시 알아두어야 할 기능이라고 할 수 있겠습니다."
TL;DR;
초기부터 웹은 다양한 서버에 저장되어 있는 문서를 연결하기 위해 요청(Request) 및 응답(Response)의 메커니즘을 기반으로 동작하도록 설계되었습니다. 다시 말해 서버와 클라이언트가 네트워크를 통해 리소스를 송수신하도록 처리하고 있으며, 이 때문에 웹 페이지 자체의 성능 외에도 근본적으로 오프라인을 기반으로 하는 실행 환경은 아닌 것입니다.
서비스워커는 1차적으로는 이러한 오프라인의 문제를 해결하기 위한 시작점입니다. 물론 서비스워커가 해결하고자 하는 문제의 범위는 이보다 더 넓습니다. 오프라인은 시작일 뿐이지만 비유하자면 네이티브 어플리케이션의 동작 흐름을 웹으로 가져오기 위한 가장 중요한 기능이라고 할 수 있겠습니다.
이 튜토리얼에서는 서비스워커를 이용하여 브라우저의 캐시 시스템을 생성하고 관리하는 방법과 이를 통해 웹 페이지에서 사용하는 모든 리소스에 대한 오프라인 동작을 수행하는 방법을 알아봅니다.
> 서비스워커란
서비스워커는 웹페이지나 사용자 인터랙션이 필요하지 않은 기능들을 위한 기회를 제공하고, 웹페이지와는 별개로 여러분의 브라우저에 의해 백그라운드에서 실행되는 스크립트 기반의 워커(Worker)입니다.
이 기능은 앞으로 여러가지 연동 기능을 예정하고 있으며 네트워크 요청을 가로채고, 응답을 조작하기 위한 프로그래밍 가능한 캐시를 제어할 수 있는 기능을 현재 크롬에서 제공합니다.
> 서비스워커의 생명주기
서비스워커는 웹페이지와 완전하게 별개인 생명주기(Life Cycle)를 가지고 있으며, register를 통해 백그라운드에서 서비스워커의 설치 과정을 시작합니다.
설치 과정에서 리소스를 캐싱하고자 할 때 모든 파일이 성공적으로 캐싱되고 나면 서비스워커는 설치 상태가 되지만 만약 어떠한 파일이라도 다운로드나 캐싱에 실패한다면, 설치 과정 역시 실패하고 서비스워커는 활성화되지 않습니다.
설치가 이루어졌을 때 이어서 활성화 단계가 수행되며, 이는 우리가 서비스워커 갱신하기 섹션에서 다룰 기존 캐시의 관리를 위한 시점으로 활용할 수 있습니다.
활성화 단계 후에 서비스워커는 페이지가 등록한 서비스워커는 범주(scope) 내에 닿는 모든 페이지를 제어하게 되며 페이지로부터 네트워크 요청이나 메세지가 생성될 때 발생하는 fetch와 message를 제어하게 됩니다.
단순화한 서비스워커의 생명 주기
> 서비스워커를 사용하기 위한 몇 가지 사항
서비스워커는 지대한 영향을 줄 수 있는 서비스워커 모듈의 신뢰성을 위해 HTTPS 기반으로만 동작합니다. 또한, 현재 시점에서 캐시 시스템은 폴리필을 통해서만 사용할 수 있습니다.
이 튜토리얼은 Chrome 35 버전부터 포함되는 Object.observe()에 대한 기초적인 설명부터 이를 데이터 바인딩으로 확장하는 구현 사례, 성능에 대한 분석을 담고 있습니다.
"데이터 바인딩은 흔히들 얘기하는 데이터(혹은 모델) 레이어와 표현 레이어를 분리하는 편리하고 강력한 개념이자 방법이며 이미 꽤 오랜동안 그리고 대다수의 프레임워크에서 데이터 바인딩을 지원하고 있습니다. 특히 데이터 바인딩에서 양방향 혹은 데이터의 변경을 자동으로 추적하여 뷰를 업데이트하는 방법은 데이터(정확히는 객체나 객체 내의 속성, 프로토타입 등)에 대한 관리 외에 UI까지 신경써야 하는 개발 과정을 크게 단순화시켰습니다만 이를 지원하기 위해 지속적으로 UI와 연결(Binding)된 데이터에 대한 추적을 지원해야 하며 경우에 따라서는 바인딩을 유지하기 위한 별도의 프로그래밍 방법이 필요한 경우도 있었습니다. ECMAScript7에서 추가된 .observe() 메소드는 이러한 데이터를 추적하기 위한 방법을 순수 스크립트 객체까지 확대하였습니다.
데이터의 변경을 추적하거나 기존 프레임워크에서 데이터 바인딩을 유지하기 위한 실행 비용이 부담스러웠다면 이 튜토리얼에서 observe()에 대한 이해를 통해 힌트를 얻어보시기 바랍니다."
TL;DR;
ECMAScript 7에 정의되고 Chrome 36 베타부터 탑재된 Object.observe() 메소드는 데이터 바인딩(data-binding)과 가장 밀접하게 관계된 새로운 자바스크립트 추가 기능입니다. 이는 MVC 라이브러리들에서 사용하는 감시 모델(Observing Model)에 대한 구현 방식을 획기적으로 전환할 기능이기도 합니다.
자바스크립트에서 객체에 대한 데이터 감시(Observation)의 대상은 보통 다음과 같습니다.
순수한 자바스크립트 객체들에 대한 변경
속성(Property)들이 추가, 변경되거나 삭제되었을 때
배열들이 가진 요소(Element)가 합쳐지거나 나누어졌을 때
객체의 프로토타입에 대한 변경
Object.observe()- 이하 O.o() -는 별도 라이브러리 없이 자바스크립트 객체들의 변경을 비동기적으로 감시하기 위한 방법입니다. 이는 객체들에 대한 일련의 변경 사항들을 변경이 일어난 시간 순서에 따라 전달받을 수 있는 감시자(감시 객체, Observer)를 통해 프레임워크나 라이브러리에 구현되어 있는 객체 감시 방법들에 대한 성능 개선 효과와 동일한 API를 유지하면서도 빠르고 단순한 구현을 제공하며 별도의 프레임워크 없이 양방향 데이터 바인딩을 구현할 수 있습니다.
> 데이터 바인딩의 중요성과 최근까지의 방법들
데이터 바인딩의 가장 큰 장점은 모델-뷰-컨트롤의 분할입니다. 데이터 바인딩은 복잡한 사용자 인터페이스가 데이터 모델들 내에 있는 여러 개의 속성들과 뷰들 내의 여러 엘리먼트들 간의 관계를 연결하여야 하는 곳에 있을 때 특히 유용합니다. 이는 데이터를 DOM으로부터(그리고 DOM으로) 어플리케이션의 내부 혹은 외부와의 동적인 연결을 제어하는 반복적인 코드 작성 시간을 크게 절약합니다.
최근까지 프레임워크 등에서 널리 쓰인 Dirty-checking의 경우 객체의 변경을 추적하기 위한 방법을 제공합니다만 대체적으로 동작 비용이 감시되는 객체들의 전체 숫자에 비례하여 성능과 관련된 문제가 존재하고 서버로부터 받은 데이터를 이들 객체로 변경하는 작업들이 개발자에게 요구됩니다.
O.o()는 브라우저 내의 데이터를 자체적으로 감시하기 위한 방법을 구축함으로써 요즘 널리 사용되고 있는 느린 구현 방식에 의존하지 않고 자바스크립트 프레임워크에 모델 데이터의 변경을 감시할 수 있는 방법을 제공합니다.
> Object.observe()
Object.observe()는 순수(Raw) 데이터 객체들(정규 자바스크립트 객체들)의 지원을 통해 데이터를 감시할 수 있으며 항상 모든 것에 대해 Dirty-check를 할 필요가 없는 방법으로 잠재적으로 많은 장점을 가지고 있습니다.
O.o()의 특징을 요약하면 다음과 같습니다.
Specifying changes of interest
관심있는 변경 사항들만 사용자가 지정하여 추적하거나 알림(Notification) 개념을 통해 작업
Notifications
단위의 마지막(대체적으로는 현재 실행 중인 이벤트 핸들러의 종료 시)에 변경 사항을 받아 효과적인 처리가 가능합니다.
Synthetic change record & Accessor properties
기본적으로 접근자의 경우는 내부적으로 함수일 뿐이므로 감시의 대상이 되지는
특정한 접근자 혹은 연산 속성(Computed Property)의 경우에도 필요하다면Notifier.notify() 등을 이용하여 사용자가 객체 내에서 추적이 필요한 경우를 선택적으로 혹은 직접 지정할 수 있습니다.
Single callback observers
복수의 객체들에 대해 동시에 동일한 콜백으로 변경을 추적할 수 있습니다. 이는 특히 다양한 객체에 대한 변경이 동일한 기능으로 연결될 때 효과적입니다.
Large-scale changes
개별적인 변경 사항을 추적하는 대신에 여러개의 변경 사항을 묶어서 보다 큰 단위 관점에서의 변경을 추적할 수 있습니다.
Array Observation
일반적인 객체 이외에도 배열의 변경 등에 대한 변경을 추적할 수도 있습니다.
> 성능
Dirty-checking은 여러분이 감시하고 있는 모든 객체의 숫자에 성능이 비례하며 (변경의 검출을 위해) 데이터 사본의 유지를 필요로 하지만 O.o()의 경우 변경의 횟수에 성능이 비례하므로 여러모로 성능 상 더 효율적입니다.
Dirty-checking
Object.observe()
> 프레임워크와 Object.observe()
이미 말씀드린 바와 같이 O.o()는 네이티브로 구현된 기능을 통해 프레임워크와 라이브러리에 그들의 데이터 바인딩 성능을 개선할 수 있는 방법을 제공합니다. 만약 O.o()가 지원 가능한 환경이라면 자바스크립트를 이용한 복잡한 프로세스 대신 높은 성능 개선을 기대할 수 있을 것입니다. Angular나 Ember 등의 주요 프레임워크들 역시 이를 지원하거나 지원하기 위한 로드맵을 진행 중입니다.
오랜만에 포스팅을 하는군요. 최근 Google I/O 때문인지 HTML5Rocks의 신규 튜토리얼 등록도 미뤄지고 있고 해서 딱히 업데이트할 내용이 없다는 것이 핑계라면 핑계입니다만, 마침 크롬/크로미움 36 버전의 업데이트 관련한 소식 중에 신나는 것들이 있어서 공유하고자 합니다. :)
"아직 36버전의 공식 업데이트까지 기간이 남았기 때문에 최종 버전이라고 생각하시면 곤란합니다. ㅎㅎ 대신 중요한 추가 항목들이 생기면 이 포스트에 업데이트하도록 하겠습니다."
Chrome/Chromium 36 버전 중요 업데이트 미리보기
개인적으로 36 버전 업데이트에서 눈에 띄는 몇가지는 관심을 가지고 있는 신규 규격들의 적용입니다. 아래에 언급하고 있지 않은 기능 중에서 WebComponents와 같은 규격들에 대한 업데이트도 지속적으로 업데이트되고 있습니다. 올해는 재밌군요. :)
> CSS transform의 Prefix 제거
기존에 CSS transform을 적용하기 위해서는 -webkit-transform: ...처럼 prefix가 포함된 형태로 기술해야 했지만 36버전부터는 transform: ... 과 같이 prefix가 없는 상태로 기술이 가능해집니다. :)
> WebAnimations 자바스크립트 API 추가
Web Animations는 기존의 선언적인 방식에서 벗어나서 자바스크립트를 기반으로 능동적으로 CSS3 Animation 및 Transition, SVG 애니메이션을 처리할 수 있는 새로운 HTML5 규격입니다.
작년 말 Blink 엔진에서 WebAnimations 규격을 지원하기 위한 네이티브 엔진 교체가 이루어졌었습니다만 이때까지는 WebAnimation에서 정의하고 있는 자바스크립트 API가 빠진 상태로 기존 CSS3 애니메이션이 제대로 동작하는지만 확인할 수 있어 별로 차이를 느끼지 못하셨을 겁니다. (아마 엔진이 변경되었다는 사실조차 모르시는 분들이 많으실 것 같네요.)
이제 36버전부터 웹 애니메이션의 API 중 element.animate()가 사용 가능해집니다. 물론 Chrome for Android에서도 마찬가지입니다.
ServiceWorker는 웹 페이지와는 독립적인 생명주기(life-cycle)를 가진 이벤트 기반 시스템으로 SharedWorker의 일종이지만 근본적으로는 어플리케이션과 별개의 스레드를 운용하며 필요하다면 개발자의 캐싱(Caching) 관리가 가능하게 하거나 네트워크를 통한 사용자 요청에 대하여 응답을 제어할 수 있게 되는 등 오프라인 지원을 위한 다양한 (특히 리소스의 제어에 유용한) 기능을 제공합니다.
현재 ServiceWorker 규격 정의가 W3C에서 현재 진행 중이며 데스크톱 크롬 36과 안드로이드용 크롬 36부터 ServiceWorker의 초기 구현이 포함됩니다. 구현 상태와 규격은 아래 사이트에서 참조하시기 바랍니다.
"콜백에 의한 비동기 처리는 우리에게 성능이라는 한가지 장점과 사소해보이는 몇가지 단점을 같이 선물하였습니다. UI가 동작 중인 메인스레드에서 실행되는 자바스크립트에서 콜백에 의한 비동기 처리는 발생할 수 있는 성능 상의 문제를 해결하기 위한 최선의 방법이었습니다만 성능의 이점 대신 코드 작성은 좀 더 어려워졌고 선형적으로 디버깅할 수 있는 방법은 크게 복잡해졌습니다.
코드에서 무엇을 어떻게 처리할 것인지는 여러분의 몫입니다만 불행하게도 디버깅 역시 그러하며 특히나 비동기 처리라면 개발 환경을 넘어선 코드에 대한 깊은 이해를 요구하는 경우가 많으며 최근과 같이 외부에서 작성된 자바스크립트 라이브러리들을 사용하는 환경에는 더욱 더 그렇습니다.
크롬에서 추가된 비동기 자바스크립트에 대한 호출 스택과 왓치(Watch) 기능은 이러한 영역에서의 괴로움을 크게 줄여줄 것입니다."
TL;DR;
콜백 함수를 통해 비동기로 동작할 수 있는 능력은 자바스크립트를 특별하게 만드는 강력한 기능이지만 자바스크립트는 순차적으로만 실행되지 않으므로 디버깅 과정에서는 우리를 괴롭게 만듭니다.
다행스럽게도 이제 크롬 카나리 개발자 도구(DevTools)에서 비동기 자바스크립트 콜백이 포함된 호출 스택의 모두를 확인할 수 있습니다. 개발자 도구에서 비동기 콜 스택 기능을 활성화하면 다양한 지점에서 각 지점에서의 상태를 자세히 볼 수 있으며 스택을 추적해 가면서 런타임 실행에서 특정 지점의 어떤 변수 값을 분석할 수도 있습니다.
Build with Chrome은 Chrome 브라우저에 실행되며 LEGO® 벽돌들을 이용하여 구조물을 만들어낼 수 있으며 이를 Google Maps와 연동하여 전세계의 지도 위에 위치시킬 수 있는 인터랙티브 3D 컨텐츠입니다. 이 튜토리얼은 Build with Chrome이 2014년 다시 런칭하며 적용하였던 모바일 및 터치 지원 과정에서 발생한 주요 이슈에 대한 사례연구를 담고 있습니다. (저자인 Hans Eklund가 일하고 있는 North Kingdom은 그동안 '호빗 체험'이나 'RO.ME'과 같은 프로젝트를 만들어온 회사입니다. 포트폴리오도 재밌는 것이 많으니 한번 살펴보시기 바랍니다.)
"Build with Chrome이 2014년에 터치 스크린 및 모바일 디바이스를 지원하도록 적용하는 과정에서 발생한 성능, 터치 그리고 멀티 스크린 대응과 같은 주요 문제들은 다른 인터랙티브 3D 컨텐츠에서도 반복되는 문제입니다. 만약 비슷한 컨텐츠 개발을 계획 중이라면 읽어보시기 바랍니다."
TL;DR;
데스크탑 크롬용으로 개발되었던 Build with Chrome은 다시 릴리즈되는 과정에서 모바일 디바이스들을 지원하는 기능이 새로 추가되었습니다. 이 과정에서의 가장 큰 이슈들은 사용자 경험과 디자인에 대한 해결이었으며 기술적인 도전은 많은 화면 크기, 터치 이벤트 그리고 성능 이슈들을 관리하는 것이었습니다. 터치 디바이스 상에서의 WebGL 쉐이더 사용에 대한 몇가지 도전과제들이 있었지만 이는 기대했던 것보다 꽤나 잘 동작했습니다. 디바이스들은 점점 더 강력해지고 있으며 WebGL 구현들은 빠르게 개선되고 있으므로 가까운 시일 내에 더 많은 디바이스에서 WebGL을 더 많이 사용할 수 있을 것이라고 예상할 수 있습니다.
> 반응형 프론트엔드
터치와 마우스 입력을 사용하는 디바이스 모두를 지원해야 했으나, 작은 터치 스크린 상에서 동일한 UI를 사용하는 것은 공간 제약을 제대로 해결할 수 없었고 사용자의 손가락이 상호작용을 하는 동안 작은 스크린의 많은 부분을 커버하였으므로 픽셀들보다 물리적인 스크린 사이즈에 대해 정말 고려하고 실제 컨텐츠에 전념할 수 있도록 가능한 많은 공간을 확보하는 것이 중요합니다.
Build with Chrome의 경우 터치 디바이스에서 자연스럽게 느끼도록 만들고 정말 터치 입력을 의도한 것처럼 느끼도록 하기 위해 미디어쿼리를 이용하여 2가지의 UI 변경 버전을 개발하였습니다.
마우스와 터치를 지원하는 큰 화면
큰 화면 버전은 마우스를 지원하는 모든 데스크탑 컴퓨터와 큰 화면을 가진 터치 디바이스에 제공되며 터치 지원과 몇가지 제스쳐가 추가된 오리지널 데스크탑 버전과 유사합니다.
터치만 지원하는 작은 화면
이 모바일 디바이스들과 작은 태블릿용 버전은 멀티-터치를 요구하며 화면 상의 공간을 최대화하기 위한 대부분의 작업은 잘 사용하지 않는 UI 요소들을 최소화하거나 멀티 터치 제스쳐로 변경하고 풀스크린 모드를 지원하는 것이었습니다.
> WebGL 성능과 지원
현재의 터치 디바이스들은 꽤 강력한 GPU들을 가지고 있지만 여전히 데스크탑의 상대가 되기는 어려우므로 성능, 특히 동시간에 많은 구조물을 렌더링할 필요가 있는 3D 탐색 모드에 대해 텍스쳐, 구조물 로딩이나 구조물들의 애니메이션 및 렌더링 등 많은 것들이 동시에 처리되어 GPU와 CPU 모두를 크게 요구했으므로 모바일 디바이스에서는 구조물에 꽤 가깝게 줌하도록 하여 동시에 많은 구조물을 렌더링할 필요가 없도록 하는 접근을 취했습니다. 다만, WebGL 기능이 없는 디바이스의 경우 WebGL의 사용없이 빌드와 3D 탐색 기능을 유사하게 동작할 수 있는 충분히 훌륭한 해결방법을 찾지는 못했습니다.
> 화면 방향 관리하기
모바일 디바이스에 적용을 시작할 때 세로 모드(Portrait mode)에서 가로 모드(Landscape mode)에 대해 고려할 필요가 있습니다. Build with Chrome의 경우 컨텐츠의 흐름을 유지하고 편안한 방식의 상호작용을 제공하면서 가로와 세로 방향으로 모두 동작하는 대신 가로 모드만을 지원하기로 하였습니다.
대부분의 컨텐츠 레이아웃은 CSS에 의해 제어되지만 방향과 관련된 것은 자바스크립트에서의 구현을 필요로 하였으며 이를 위해 window.orientation을 사용하는 것은 좋은 크로스-디바이스 솔루션이 아니라는 것을 확인하였으므로 window의 .innerWidth와 .innerHeight의 비교하였습니다.
> 터치 지원 추가하기
웹 컨텐츠에 대한 터치 기능의 추가 지원은 합리적이며 올바른 것입니다. 마우스와 터치를 동시에 지원하기 위한 포인터 이벤트는 W3C에 표준으로 제출되었습니다만 아직 인터넷 익스플로러에서만 구현되어 있습니다. 따라서 터치 이벤트들 또한 다루는 것이 필요할 것입니다. 이 글은 이 이벤트들을 어떻게 사용하는지에 대한 기초들을 다루고 있습니다.
멀티터치 제스쳐
핀치(Pinch)와 회전 제스쳐를 관리하기 위해 두번째 손가락이 화면에 얹어질 때마다 두손가락 사이의 거리와 각도를 저장했습니다.
마우스와 터치의 동시 지원
오늘 날에는 마우스와 터치 입력을 둘 다 지원하는 디바이스가 있으므로 터치 지원의 검출만으로 마우스 입력을 무시하는 대신 동시에 전부를 지원하지 않는다면 몇가지 예상치 못한 동작을 발생할 수 있습니다.
마우스, 터치 그리고 키보드 입력 처리
이벤트 핸들러 내에서의 입력을 변수에 저장하고 requestAnimationFrame의 렌더 루프에서 입력에 반응하도록 하여 렌더링 성능 등의 오버헤드를 최대한 회피하고 마우스 입력 등으로의 확장을 보다 용이하도록 합니다.
또한 각 이벤트 핸들러에서 event.preventDefault()는 브라우저가 스크롤이나 전체 페이지의 스케일을 조정하는 것과 같은 예상치 못한 동작을 발생할 수 있는 터치 이벤트의 지속적인 처리를 막을 수 있습니다.
당연한 얘기지만 모든 최적화는 문제가 되는 지점을 개선하는 작업입니다. 당연한 얘기겠지만 이러한 이유로 성능 병목 지점을 찾는 것이 가장 첫번째 단계입니다. 문제의 원인을 찾으면 여러가지 테크닉 중 어떤 것을 선택해서 해결할 수 있는지에 대한 방법을 결정할 수 있을 것입니다. 이 튜토리얼은 Find Your Way to Oz의 개발 과정에서 성능 문제를 개선하기 위해 병목 지점들을 찾는데 사용된 방법을 다루고 있는 사례 연구이기도 하며 실질적인 가이드라인이기도 합니다.
"가비지 콜렉션이나 로직 오버헤드, 렌더링 오버헤드 혹은 리소스 로딩으로 인한 jank 등 하나의 어플리케이션에서 성능에 영향을 주는 요인은 굉장히 많습니다. 점진적으로 하나씩 개선해나가는 방식도 좋지만 가능하다면 가장 큰 요인 중 가장 쉽게 해결할 수 있는 것들부터 찾아나가거나 다른 기준에 의해 성능을 개선할 수도 있을 것입니다. 만약 이러한 방식을 원하신다면 그 무엇보다도 우선시되어야 할 작업은 최적화가 아닌 진단입니다."
TL;DR;
최근 몇 년 동안 자바스크립트 가상 머신 기술의 놀라운 진보에도 불구하고, 최근 한 연구는 Google 어플리케이션이 그들의 시간 중 50~80%를 V8에서 보내고 있음을 증명하였습니다. CPU 사이클은 하나의 제로-썸 게임입니다. 시스템 리소스를 더 적게 사용하도록 하는 것은 더 높은 성능을 보여주는 방법이며 고성능 실시간 어플리케이션에서 무엇보다 중요합니다.
성능 문제를 해결하는 것은 범죄를 해결하는 것과 유사합니다. 여러분은 조심스럽게 증거를 조사하고 의심되는 원인들을 확인하고 다른 해결책들을 실험하는 것이 필요합니다. 이러한 과정 내내 문제를 실제로 고쳤는지 확인할 수 있도록 반드시 측정된 결과들을 문서화해야 합니다.
이 튜토리얼은 Find Your Way to Oz의 모호한 성능 문제를 찾아내고 자바스크립트를 최적화와 프로파일링한 방법들을 다루고 있습니다. Oz의 경우 가설을 통해 최종적으로 선택된 두 개의 용의자가 있었으며 이를 V8 엔진의 로그와 V8 내부의 최적화에 관련된 추적을 통해 정확한 문제점을 도출하고 자바스크립트 for-in 구문의 수정을 통해 성능을 개선하였습니다.
> 자바스크립트의 로그를 이용한 성능 요인 검출 방법
V8 자바스크립트 엔진은 내장된 로깅 시스템을 가지고 있습니다.
터미널에서 "--no-sandbox --js-flags="--prof --noprof-lazy --log-timer-events" 인자들을 이용하여 크롬을 실행하고 어플리케이션을 구동한 뒤 종료하면 현재 디렉터리 안에 v8.log 파일이 생성됩니다. 이렇게 생성된 로그는 tick processor와 plot-timer-event를 통해 분석할 수 있습니다.
> V8 최적화의 추적
V8의 자바스크립트 성능 관련 팁들에서 언급된 바 있듯이 V8은 높은 성능을 위해 실행 시간에 자바스크립트에 대한 많은 최적화를 수행합니다. 만약 이 과정에서 의심되는 문제가 있다면 터미널에서 "--js-flags="--trace-deopt --trace-opt-verbose" 인자를 통해 크롬을 실행하여 상세 로그를 확인할 수 있습니다.
+Eric Bidelman이 재밌는 포스트를 올렸네요. 바로 Web Speech API입니다. 아주 간단한 형식으로 되어 있는 API들이지만 손쉽게 TTS(Text To Speech)를 수행하며, 반대로 STT(Speech To Text)를 수행할 수도 있습니다. 현재는 크롬에서만 지원하고 있는 기능이지만 유용하게 사용할 수 있는 기능입니다. 무엇보다 쉬워서 재밌네요! :)
그리고나서 다음과 같이 utterance 객체의 .voice의 설정을 통해 다른 목소리를 설정할 수 있습니다.
var msg =newSpeechSynthesisUtterance('I see dead people!');
msg.voice = speechSynthesis.getVoices().filter(function(voice){return voice.name =='Whisper';})[0];
speechSynthesis.speak(msg);
불행하게도 이는 음성 합성(Speech synthesis)를 수행하기 위해 문서화되지 않은 기능(그리고 비공식적인 API)을 사용하였습니다. 자 이제 우리는 다시 번역을 말할 수 있는 완전한 Web Speech API를 가지게 되었습니다! 데모는 Synthesis API를 사용하도록 업데이트해두었습니다.
브라우저 지원
현재 Chrome 33 버전은 Web Speech API를 완전하게 지원하며 iOS7의 사파리는 일부의 기능을 지원하고 있습니다.
기능의 지원여부 검사
(크로미움의 경우처럼) 각 브라우저들은 Web Speech API를 각 부분을 따로 지원하고 있을 것이므로 다음과 같이 각 기능을 분리하여 검사할 수 있습니다.
if('speechSynthesis'in window){// Synthesis support. Make your web apps talk!}if('SpeechRecognition'in window){// Speech recognition support. Talk to your apps!}
블링크는 크롬의 오픈소스 렌더링 엔진입니다. 블링크 팀은 개발자들이 부딪히는 이슈들을 고민하며 웹을 혁신하고 있습니다.
여기에는 지난 4월의 런칭으로부터 시작하는 수많은 감춰진 개선사항들이 있습니다.
첫번째로 우리는 더 이상 필요로 하지 않는 절반가량의 소스를 삭제했으며 아직도 이는 끝나지 않았습니다! 그리고 리포팅 의사 표시를 한 크롬 사용자들로부터 익명으로 리포팅된 종합적인 통계들에 기반한 코드 제거에 대해 묵과하지 않고 있습니다.
우리는 새로운 개발자 API를 크롬의 탑재 스케줄과 동일하게 매 6주마다 발행하고 있습니다.
블링크로부터 포크했을 때 가장 큰 변경은 다음과 같은 인텐트(Intent) 시스템을 추가하는 것입니다. 웹 플랫폼을 변경하려 하기 전 매번 우리는 기능의 추가나 삭제를 위한 우리의 의도를 표현하기 위해 블링크 개발자 그룹을 통해 공개 발표를 해왔습니다. 그리고나서 움직였고 코드를 작성했습니다! 그리고나서 기능을 체크인한 바로 다음날이면 카나리 빌드에 이미 탑재된 상태였습니다. 이러한 기능은 기본적으로 Off된 상태이지만 about:flags를 이용하여 이를 활성화할 수 있습니다.
chromestatus.com에서 우리가 작업한 기능들, 탑재한 기능들, 제거할 계획을 가지고 있는 것들을 확인할 수 있습니다. 또한 크롬 배포 블로그에서 버그들에 대한 링크들과 추적 대쉬보드를 확인할 수도 있습니다.
또다른 큰 변경사항은 WebKit 접두어를 삭제하고 있는 것입니다. 의도는 블링크의 접두어를 사용하기 위함이 아니라 (그저 컴파일 시의 플래그만이 아닌) 런타임 플래그를 가지기 위함입니다.
안드로이드 웹뷰는 아주 커다란 도전이었습니다만 HTML5Test는 이들이 더 좋아졌음을 보여줍니다. 웹 플랫폼 API들이 어디에서나 하나의 세트를 가지는 관점에서 데스크탑에 훨씬 더 가까워졌습니다. (웹 오디오는 이에 대한 훌륭한 예제입니다!)
그러나 어떻게 소세지 기계가 동작하나요? 각각의 모든 변화들은 나중에 추가적으로 실행할 모든 크로미움 테스트는 말 할 필요도 없이 블링크가 30,000개 이상의 테스트를 즉시 거치도록 했습니다. 우리는 24시간 보안관, 수천개의 봇들, 수천개의 벤치마크 그리고 갑자기 중단되지 않음을 확신하기 위해 몇백만개의 깨진 웹 페이지를 엔진으로 던지는 시스템들을 사용하고 있습니다. 우리는 모바일이 두드러지게 느리고 이는 우리가 개선을 위해 훨씬 더 열심히 일해야한다는 뜻임을 알고 있습니다.
우리는 랩탑, 휴대폰 그리고 태블릿으로 연결되어 있으며 아마도 곧 개인 디바이스들과 액세서리들로도 충분해질 것입니다. 우리는 신뢰할 수 없거나 가끔은 적대적인 네트워크로부터도 인터넷을 액세스합니다. 삶의 많은 부분이 온라인으로 이동하며 우리의 데이터와 우리 사용자의 데이터를 보호하기 위한 단계가 중요해졌습니다.
무엇보다 개발자로써의 우리는 SSL의 필요성과 실현 가능성에 대해 이해할 필요가 있습니다.
SSL이란 무엇일까요? 이는 전송 계층 보안(Secure Sockets Layer)를 의미하고 인터넷 간의 통신 보안을 제공하기 위해 디자인된 암호화 프로토콜입니다. 암호화와 완전성을 통해 인터넷 연결을 통한 스누핑(Snooping)이나 데이터 훼손(Tempering)을 방지하기 위한 프라이버시를 보장합니다. SSL은 결점이 있지만 주도적인 방식-그리고 실제로는 유일한 방식-이며 인터넷 상의 데이터 통신 보안의 어떠한 것이라도 보장할 수 있는 방식입니다.
SSL Pulse에 따르면 1년 전에는 우리의 SSL 적용은 15% 미만 밖에 안되었지만 현재는 50%가 넘습니다.
다음과 같이 2가지 약어(Acronyms)가 있습니다.
TLS: SSL과 거의 마찬가지의 목적 및 의도를 가집니다. 보다 정확하게는 SSL 3.1의 명칭이 TLS로 변경되었으며 TLS는 IETF 표준 명칭입니다. 그러나 이는 교환 가능합니다!
HTTPS: SSL를 통한 HTTP이며, 그저 SSL과 표준 HTTP의 보안 능력을 계층화한 것입니다. 처음 클라이언트-서버 간의 Handshake는 통신을 암호화하기 위한 SSL 프로토콜의 두번째 부분에서 사용되는 공용 키를 생성하기 위해 공용/개인 키 암호화를 사용합니다.
인터넷 상의 네트워킹은 안전하고, 즉각적이며 빠르다고 느낄 수도 있습니다. 이는 우리가 주로 웹사이트에 대해 얘기하는 것과 비슷한 느낌입니다. 그러나 실제로는 이는 직접적인 연결이 아닙니다. 우리의 통신은 디바이스와 웹 사이트 간의 WiFi 라우터나 ISP 그리고 잠재적인 다른 중간 프록시를 통해 움직입니다. HTTPS가 없이는 모든 연결은 평문 속에 존재합니다.
문제는 사용자가 아주 가끔 HTTPS를 정의하는 완전한 URL을 타이핑하거나 HTTP를 사용한 링크를 클릭하는 것입니다. 더 나쁘게 얘기하자면 중간자 공격을 시작하거나 HTTPS를 HTTP로 변경할 수 있습니다. 2009년에 소개된 SSLstrip으로 불리는 도구가 바로 그러한 일을 수행합니다. 2010년에 발표된 Firesheep은 열려있는 WiFi 네트워크에서 깔끔하게 전송된 쿠키들을 바로 청취할 수 있으며 이는 다른 사람의 페이스북 계정에 로그인하거나 채팅을 엿들을 수 있다는 것을 의미합니다.
그러나 SSL은 (비교적) 저렴하고 빠르며 배포하기 쉽습니다. (ssllabs.com과 +Ilya Grigorik 의 저서 '고성능 브라우저 네트워킹'을 확인해보시기 바랍니다.) 상용이 아닌 경우 여러분은 startsll.com으로 부터 무료로 인증을 받을 수도 있습니다! Public Key Pinning은 웹사이트 운영자들이 당사자들이 그들의 사이트 인증서를 실제로 이슈화할 수 있는 인증 범위를 제한할 수 있도록 디자인되었습니다.
"올해(2010) 1월, Gmail은 기본사항으로 모든 것에 대해 HTTPS를 사용하도록 변경되었습니다. ..이를 위해 우리는 추가적인 장치나 특별한 하드웨어 없이 이를 배포해야 했습니다. 우리의 프론트엔드 생성 장비들 상에서 SSL 계정들은 1% 이하의 CPU 부하와 10KB 이하의 연결당 메모리 사용량 그리고 2% 이하의 네트워크 부하를 차지하며... 만약 지금 여기까지만 읽고 싶으시다면 그냥 하나만 기억하세요. SSL은 더 이상 연산량에 있어 비싸지 않습니다." – Overclocking SSL, Adam Langley (Google)
마지막으로 우리가 일반적으로 볼 수 있는 몇가지 버그들은 다음과 같습니다.
혼합된 컨텐츠:
HTTPS뿐만이 아니라 HTTP를 사용하는 사이트들. 컨텐츠가 로딩될 때 권한에 대한 클릭을 해야하므로 여러분의 사용자는 짜증이 날 수 있습니다. (크롬, 파이어폭스는 실제로 iframe들이 컨텐츠를 혼합하는 것을 막습니다.) 예를 들어 <style src="//foo.com/style.css">와 같이 HTTPS 페이지 내의 모든 리소스들을 상대 경로 혹은 상대-스키마(Scheme-Relative)를 사용하여 반드시 HTTPS로 로딩하도록 합니다.
안전하지 않은 쿠키들:
HTTP 연결을 통해 깨끗하게 보내는 경우. 쿠키 헤더들 상의 보안 속성의 설정을 통해 이를 회피하도록 합니다. 여러분은 SSL 전송 보안(SSL Transport Security, HSTS)를 요구하도록 새로운 "Strict Transport Security"를 사용할 수도 있습니다.
요점(Takeaways)
만약 프라이버시와 사용자 데이터의 완전성을 관리하고 싶으시다면 SSL을 사용하여야 합니다.
이는 그 무엇보다 빠르고 쉬우며 저렴합니다.
혼합된 컨텐츠 버그나 올바른 HTTP 헤더 부분의 설정없는 일반적인 구현들을 회피하여야 합니다.
상대 경로 혹은 상대-스키마 URL을 사용합니다.
HSTS와 인증서 피닝(Certification pinning)과 같은 훌륭한 신규 기능을 확인해보시기 바랍니다.
웹 상의 새로운 디바이스나 플랫폼들의 확산 속에서 우리는 오디오, 비디오 그리고 실시간 통신의 커다란 성장을 보고 있습니다. 온라인 미디어는 모든 종류의 미디어를 우리가 소비할 수 있도록 방식을 바꾸고 있습니다.
영국 정부의 사례에서 53%의 성인이 TV를 보는 동안 모바일 디바이스를 사용하여 미디어를 소비하고 공유하는 '미디어 멀티-태스크'를 한다는 것을 발견할 수 있습니다. 많은 나라에서 TV를 보는 것은 감소하고 있고 온라인 시청은 증가하고 있습니다. 예를 들어 중국의 경우 2009년에 70% 달했던 베이징 가정의 TV 시청이 2012년 단 30%로 감소하였습니다. W3C 2013년 하이라이트에 따르면 '작년동안 모바일 장비에서의 비디오 시청이 2배로 증가하였습니다. 미국의 경우 올해 디지털 미디어의 일일 사용에 대한 평균 시간이 TV 시청을 넘었습니다. 시청은 더 이상 일반적인 행동이 아닙니다. 미국에서는 87%의 엔터테인먼트 소비자들이 TV를 시청하는 동안 최소한 1개 이상의 세컨-디바이스를 사용하고 있다고 말하고 있습니다.' Cisco에 따르면 '비디오는...2017년 글로벌 사용자 트래픽의 80%에서 90%를 차지할 것`이라고 합니다. 이는 매초마다 몇백만분의 비디오가 보여진다는 것과 거의 동일합니다.
그렇다면 웹 개발자들은 무엇을 해야 할까요? 오픈 웹을 위한 미디어 API의 생태계는 멀티플랫폼 간에 동작하는 표준화되고 상호 호환되는 기술입니다.
요점(Takeaways)
WebRTC는 브라우저에서의 실시간 통신을 제공하며 이제 모바일과 데스크탑 상에서 폭넓게 지원됩니다. 전체적으로 이미 12억개 이상의 WebRTC 종단점들이 존재합니다.
Chrome Dev Summit의 플랫폼 부분에 대한 +Seth Ladd의 요약이 업데이트 되었습니다. 요즘 확장을 선언한 Dart로 시작하여 Chrome Apps, PNaCl에 대한 요약입니다. 공통적으로 표준적인 웹 기술은 아닙니다만 반대로 말하면 현재 웹의 보완재에 해당하는 기술이 어떤 것들이 있는지 살펴볼 수도 있겠군요. :)
"HTML5는 순수한 표준 규격으로써의 기술을 일컫기도 하지만 HTML5과 관련된 기술을 통칭하는 개념으로 사용되기도 합니다. 표준된 규격도 중요하지만 상호보완재의 역할은 규격을 기반으로 한 기술의 범위를 넓혀주기도 합니다."
다트(Dart)
다트는 자바스크립트로 컴파일되며 때로는 직접 작성한 자바스크립트보다도 더 빠른 코드를 생성하기도 합니다. 다트의 공동 설립자 캐스퍼 런드(Kasper Lund)가 dart2js 컴파일러가 빠르고 문법적으로 옳은 자바스크립트를 생성하기 위해 지역 및 전역 최적화를 어떻게 수행하는지에 대해 설명합니다. 트리 흔들기(Tree shaking), 형식 추론(Type inference) 그리고 최소화(minification)을 이용하여 다트는 여러분의 웹 앱을 최적화할 수 있도록 도울 것입니다.
크롬 앱스는 개발 단순성, 웹의 보안성 및 구글 드라이브 같은 심리스(Seamless)한 구글 서비스들 통해 강력함과 네이티브 앱의 사용자 경험을 제공합니다. 크롬 앱스는 맥, 윈도우즈, 리눅스 그리고 크롬OS뿐만이 아니라 iOS 그리고 안드로이드까지 즉시 사용할 수 있도록 합니다.
Portable Native Client는 이식성, 네이티브 어플리케이션의 보안서 있는 실행 모델을 크롬에서 가능하게 하는 기술입니다. Native Client 프로젝트에 대한 이러한 확장은 네이티브 코드의 성능과 저수준 제어를 웹의 보안성과 이식성에 대한 희생없이 모던 웹브라우저에서 가능하도록 합니다.
PNaCl은 개발자가 그들의 네이티브 어플리케이션을 플랫폼 독립적인 형태로 생산할 수 있으며 이를 어떠한 설치과정도 없이 웹 브라우저에서 실행할 수 있도록 합니다. 크롬은 네이티브에 근접하는 성능을 달성하기 위해 PNaCl 어플리케이션을 실행 시간에 기계어로 번역합니다. 다른 브라우저에서 PNaCl 어플리케이션은 Emscripten과 pepper.js를 사용하여 최소의 성능으로 기능을 유지할 수 있습니다.
오늘은 +Paul Lewis가 Chrome Dev Summit의 성능과 관련된 세션들의 요약을 업데이트했네요. 개인적으로도 관심이 많은 영역입니다만 도구화, 렌더링, 네트워크, 모바일에 대한 최적화가 한곳에 있으니 다들 읽어보시면 좋을 듯 합니다. 이전과 마찬가지로 자세한 내용은 전문을 참고하시기 바랍니다.
이제 여러분은 데스크탑에서 알고 사랑해온 크롬 개발자도구를 사용하여 안드로이드 크롬(Chrome on Android)를 프로파일링할 수 있게 되었습니다.
성능 개선은 데이터를 수집하여 검토한 것을 기록하고 액션을 취하는 작업의 반복적인 루프입니다.
페이지에 대해 중대한 렌더링 경로 상의 애셋(Asset)의 우선순위를 결정하세요.
페인팅을 피하세요. 이는 엄청나게 비싼 비용을 소모합니다.
앱 내에서 메모리 변동(Churn)과 임계시간의 코드 실행을 피하세요.
#perfmatters: 네트워크 성능 최적화
네트워크와 지연시간은 일반적으로 사이트의 전체 페이지 로딩 시간의 70%를 차지합니다. 이는 정말 큰 비율입니다만 또한 사용자를 위한 아주 큰 장점으로 뛰어넘는 개선을 만들 수 있다는 것을 의미하기도 합니다. 이 발표에서 +Ilya Grigorik은 절대적인 최소 시간으로 네트워크 부하를 유지하도록 도와주는 환경을 만들도록 해주는 작은 변화뿐만이 아니라 로딩 타임을 개선할 수 있는 크롬에서의 최근 변경들에 대해 다뤘습니다.
SPDY / HTTP/2.0는 전송 속도의 엄청난 개선을 제공합니다. (일단 3가지만 나열하자면) nginx, 아파치 그리고 Jetty에서 사용 가능한 우아한 SPDY 모듈이 있습니다.
QUIC은 UDP의 최상위에 구축된 새롭고 실험적인 프로토콜입니다. 아직 초기지만 사용자가 (성능과의 전쟁에서) 승리할 수 있도록 해줍니다.
#perfmatters: 60fps 레이아웃 및 렌더링
여러분의 프로젝트에서 60fps에 닿는다는 것은 사용자와의 약속과 프로젝트의 성공에 중대하게 즉각적으로 연관되어 있습니다. 이번 발표에서 +Nat Duca와 +Tom Wiltzius는 크롬의 렌더링 파이프라인에 대해 설명하고 프레임을 떨어뜨리는 몇가지 일반적인 경우와 그를 회피하기 위한 방법을 다룹니다.
프레임은 16ms입니다. 이는 자바스크립트, 스타일 계산, 페인팅, 합성(Compositing)을 포함하는 과정입니다.
페인팅은 매우 비싼 비용을 소모합니다. 페인팅의 폭풍은 불필요하게 비싼 페인트 동작을 반복합니다.
레이어는 페인팅된 엘리먼트들을 캐싱하는데 사용됩니다.
입력 핸들러들(터치, 마우스휠 리스너들)은 반응성을 죽일 수도 있습니다. 가능하다면 이를 피하세요. 그럴 수 없는 곳에서는 이를 최소화해야 합니다.
#perfmatters: 즉각적인 모바일 웹앱
중대한 렌더링 경로(Critical Rendering Path, 이하 CRP)는 페이지 페인팅을 시작할 수 있기 전까지 브라우저가 필요로 하는 어떠한 것(JavaScript, HTML, CSS, 이미지 등)과도 연관될 수 있습니다. CRP에서 애셋의 전달 우선순위를 결정하는 것은 셀룰러 네트워크 상의 스마트폰같이 네트워크가 제한적인 디바이스의 사용자들을 위한 필수적이고 까다로운 것입니다. +Bryan McQuade가 구글의 팀이 어떻게 PageSpeed Insights 웹사이트를 위해 애셋들을 선정과 우선순위의 결정 과정을 진행하는지에 대해 설명하고, 20초의 로딩 시간을 단 1초로 바꿀 수 있었는지에 대해 이야기합니다!
Polymer는 웹 컴포넌트의 놀라운 미래로 가는 하나의 관문입니다. 우리는 사용자 엘리먼트(Custom element)를 쉽게 만들고 구축할 수 있기를 바래왔습니다. 작년동안 팀은 혁신적인 규격에 대한 Polyfill 세트를 위해 열심히 일했습니다. 우리는 그 최상위에 웹 컴포넌트를 더 쉽게 구축하기 위한 편리하고 간편한 라이브러리(sugaring library)를 만들었으며 마지막으로 여러분의 앱에서 재사용할 수 있는 UI와 유틸리티 엘리먼트들의 세트를 공들여 만들고 있습니다. 2013 Chrome Dev Summit에서 저는 Polymer의 각 부분들과 "모든 것이 엘리먼트"라는 마법주문 뒤에 감춰진 철학에 대해 깊이 파고 들어가 보았습니다.
90년대의 웹 페이지 구축은 제한적이었지만 강력했습니다. 단지 곧 없어질 몇가지 엘리먼트를 가지고 있었을 뿐입니다. 강력한 부분이요? ...모든 것이 선언적이었습니다. 이는 자바스크립트의 덩어리 없이도 페이지를 생성하고 폼 컨트롤을 추가하고 "앱"을 생성하는데 놀라울 정도로 간편했습니다.
겸손하기 그지없는 <select> 엘리먼트를 보세요. 여기에는 엘리먼트 내에 구축된 엄청나게 많은 기능이 있으며 다음과 같이 그를 정의하는 것으로 간편하게 사용할 수 있습니다.
HTML 속성들을 통한 사용자화(Customizable)
속성을 통해 설정 가능한 기본 UI를 사용한 자식들(예. <option>)의 렌더링
<form> 같은 다른 컨텍스트 내에서의 활용성
DOM API: 속성들과 메소드들
흥미있는 것이 발생했을 때의 이벤트 전달
웹 컴포넌트는 이러한 웹 개발의 전성기로 되돌아가기 위한 도구를 제공합니다. <select>를 연상시키지만 2014의 사례를 위해 디자인된 새로운 엘리먼트를 생성할 수 있는 것입니다. 예를 들어 AJAX가 오늘날 발명되었다면 아마도 다음과 같은 HTML 태그가 될 것입니다. (예제)
이는 Polymer에서 우리가 취하고 있는 정확한 접근 방법입니다. 단일한 덩어리로 된 자바스크립트 기반의 웹앱을 구축하는 대신 재사용가능한 엘리먼트를 생성해봅시다. 시간이 흐르고나면 전체 앱을 작은 엘리먼트들로 구성하도록 성장할 것입니다. 그리고 전체 앱은 다음과 같이 하나의 엘리먼트가 될 수도 있습니다.
만약 웹 컴포넌트 뒤의 표준을 내밀지 않았다면 제가 태만한 탓입니다. 결국 Polymer는 이러한 혁신적인 기초 API들에 기반하고 있습니다.
지금은 웹 개발의 매우 흥미진진 시기인 듯 합니다. 웹 플랫폼에 추가되는 다른 새로운 기능과는 달리, Web Components를 구성하는 API들은 눈부시거나 사용자를 대상으로 하고 있지 않습니다. 이들은 순수하게 개발자 생산성을 위한 것입니다. 4가지 API 각각이 그 자체로 유용하지만 함께 사용하면 마법과도 같은 일이 벌어집니다!
최상위 1000개 사이트에 대해 모바일 친화 여부에 대한 분석 후에 우리는 다음과 같은 몇가지 문제 영역을 발견했습니다. 53%는 여전히 데스크탑만으로 체험을 제공하고 있으며 82%의 사이트는 모바일 디바이스와의 상호작용에 대한 이슈들을 가지고 있고 64%의 사이트들은 사용자들이 읽는데 문제가되는 텍스트를 가지고 있습니다.
사용자들은 접근성에 대한 넓은 범위의 각기 다른 요구사항을 가지는 아주 많은 디바이스를 통해 여러분의 사이트와 서비스에 접근할 것입니다. 올바른 시멘틱 엘리먼트들과 올바른 ARIA 역할들의 사용에 의해 브라우저과 보조적인 기술들이 여러분의 페이지를 이해하는데 많은 개선을 할 수 있도록 도와줄 수 있습니다.
우리 모두는 개발자들이 웹뷰를 사용한 구축 시 제한된 HTML5 기능, 디버깅 도구의 부재, 빌드 도구의 부재와 같은 문제들을 예전에 가지고 있었음을 알고 있습니다. 안드로이드 4.4(KitKat)의 Chromium powered WebView의 소개를 통해 이제 개발자들이 웹뷰를 사용하여 훌륭한 네이티브 앱을 개발하기 위한 거대한 범주의 새로운 도구들을 가지게 되었음을 알리고자 합니다.
웹뷰는 크롬에서 사용하는 것과 동일한 도구로 완전한 리모트 디버깅을 지원합니다. 또한 Grunt를 사용한 믿을 수 있는 웹 개발 워크플로우를 가지게 되었으며 이를 Gradle을 통해 여러분의 네이티브 도구 스택에 통합할 수 있습니다. 통합된 세계들에 더 깊게 들어가, 여러분의 네이티브 코드를 자바스크립트로 테스트하기 위해 크롬 개발자도구를 사용할 수 있는 현명한 기법들을 살펴봅니다.
우리가 데스크탑, 모바일, 태블릿, 웨어러블 그리고 다른 형태의 디바이스에 대한 개발을 해야한다면 어떻게 덜 스트레스를 받도록 워크플로우를 최적화할 수 있을까요? 여기 LiveReload, Grunt, Yeoman 그리고 새롭게 베일을 벗은 Mini Mobile Device Lab을 통해 빠르게 반복적인 작업을 처리할 수 있는 튼튼한 멀티디바이스 접근방법이 있습니다. 만약 테스트하고자 하는 실제 디바이스가 없다면 클라우드를통해 이를 가능하게 하는 몇몇 서비스 제공자들이 있습니다.
이 토크로부터 우리는 Jake는 프리젠테이션할 때 신발을 신지 않고 Business Kinlan은 곧 발매될 새로운 책을 가지고 있으며 오프라인이 되는 것은 브라우저 벤더들에게 심각하게 받아들여지고 있고 여러분은 곧 오프라인 시에도 잘 동작하는 훌륭한 체험을 구축할 수 있도록 도와줄 도구들을 손에 쥐게 될 것이라는 많은 사실들을 배울 수 있습니다. :)
커맨드라인 API의 copy() 메소드가 이제 객체에 대해 동작합니다. 일단 가서 콘솔 패널에 copy({foo:'bar'})를 입력하고 어떻게 문자열화가 되는지와 객체의 형식화된 버전이 클립보드에 어떻게 남아 있는지 확인하시기 바랍니다. [crbug.com/289348]
콘솔 패널에서 document의 첫번째 마우스 이벤트 리스너를 검색하기 위해getEventListeners(document).mousewheel[0];를 실행하여 보시기 바랍니다. 계속해서 이벤트 리스너를 제거하기 위해 $_.remove();를 실행하여 보시기 바랍니다.($_는 가장 최근에 평가된 표현의 값입니다.) [crbug.com/309524]
CSS 경고의 제거
"Invalid CSS property value(유효하지 않은 CSS 속성값)"과 같은 스타일 경고는 이제 제거되었습니다. 브라우저의 핵(hack)을 포함하여 실제 CSS에 대해 더 견고한 구현을 만들기 위한 노력은 계속되고 있습니다. [crbug.com/309982]
타임라인 동작의 파이차트 요약
타임라인 패널은 이제 Details pane 내에 렌더링 비용의 소스를 시각적으로 보여주는 파이 차트를 포함합니다. - 이는 슬쩍 보는 것만으로도 성능의 병목지점을 파악하는데 도움을 줄 것입니다.
이제 pane 자체에서 알려주는 팝오버 디스플레이를를 사용하여 더 많은 정보를 발견할 수 있습니다. 이를 보기 위해 타임라인 기록을 시작하고 프레임을 선택하여 파이차트를 포함하는 새로운 Details pane을 보시기 바랍니다. 프레임뷰를 볼 때 평균 FPS (1000ms/프레임)과 같은 흥미로운 상태값을 선택한 프레임에 대해 볼 수 있습니다. [crbug.com/247786]
이미지 리사이즈 이벤트 상세정보
이제 이미지의 리사이즈 및 디코딩 이벤트가 타임라인 패널에 엘리먼트 패널 내의 DOM 노드에 대한 링크를 포함합니다.
서랍을 열면 이제 많은 pane들이 표시되며 그 중의 하나가 새로 그리는 영역을 표시하는(역주: 이전의 기능에서는 Show paint rectangles로 설정할 수 있는 기능입니다.) 렌더링 패널, FPS 메터기 등입니다. 이것이 이제 설정(Settings) > "Show 'Rendering' view in console drawer"가 가능하도록 기본 설정이 되었습니다.
이미지의 Data URL 복사
리소스 패널의 이미지들은 이제 그들의 컨텐츠를 data URI (data:image/png;base64,iVBO...) 형태로 복사할 수 있습니다. 이를 사용하기 위해서는 Frames > [Resource] > Images에서 이미지 리소스를 찾아 이미지 미리보기 화면에서 오른쪽 클릭으로 컨텍스트 메뉴를 열고 ‘Copy Image as Data URL’를 선택하면 됩니다. [crbug.com/321132]
Data URI 필터링
만약 그것들이 없다고 생각되신다면 Data URIs는 이제 Network 탭에서 걸러내질 수 있습니다. 다른 리소스 필터 타입을 보기 위해서는 필터 아이콘()을 클릭하시기 바랍니다. [crbug.com/313845]
네트워크 타이밍 버그의 수정
만약 이미지가 다운로드되는데 300,000년이 걸린다는 것을 본적이 있으시다면 사과드리겠습니다. ;) 이러한 네트워크 리소스에 대한 잘못된 시간 계산은 이제 수정되었습니다. [crbug.com/309570]
네트워크 기록 동작에 대한 조작성 향상
네트워크 기록 동작이 약간 달라졌습니다. 첫번째로 기록 버튼이 타임라인이나 CPU 프로파일에서 기대하던 것처럼 동작합니다. 그리고 여러분들이 원했던 방식으로 개발자도구가 열려있는 동안 페이지를 리로딩한다면 네트워크 기록은 자동으로 시작할 것입니다. 그리고 나서 자동으로 꺼지므로 페이지 로딩 뒤의 네트워크 동작을 캡쳐하고 싶으시다면 이를 다시 켜시면 됩니다. 이는 여러분의 임시적인 네트워크 요청으로 인한 결과의 왜곡없이 폭포수 모델을 손쉽게 시각화할 수 있도록 해줍니다. [crbug.com/325878]
이미 이에 대해 포스팅한 바를 보셨을 것입니다. Web Animaiton은 기존의 CSS 애니메이션 및 트랜지션, SVG 애니메이션과 SMIL 등 기존의 애니메이션 요소를 자바스크립트로 동적 제어가 가능하도록 정의하고 있는 새로운 애니메이션 규격입니다. -그렇다고 해서 아주 새로운 것은 아닙니다. 기존 CSS 애니메이션/트랜지션이나 SVG, SMIL 등의 기존 기술에 대한 '제어'를 주된 목표로 두고 있다고 이해하셔도 무방합니다.-
이에 대한 시작으로 Web Animations의 자바스크립트 API 구현을 참조할 수 있는 Polyfill 라이브러리인 web-animtations.js이 진행되고 있습니다. 현재 블링크(Blink)에는 이 기능을 네이티브로 구현하는 작업이 진행 중인데 이에 대한 첫 단계로 크롬 카나리에서 기존 CSS 애니메이션과 트랜지션 엔진이 Web Animation 구현 엔진으로 대치되어 배포되고 있습니다.
사용자들은 멀티 디바이스 UI들에 대해 부드러운 60fps 애니메이션을 기대합니다. 웹의 현재 애니메이션 기본형을 가지고 그러한 성능 품질을 달성하는 것은 어려울 수 있습니다. 다행히도 Blink의 새로운 애니메이션을 구현하고 있으며 크롬 카나리에 막 탑재되었습니다!
블링크의 내부가 단순화되고 Web Animation 1.0 규격의 새로운 API 기능을 포함하는 바탕이 마련된 것에 대해 매우 기쁘게 생각합니다.
지금까지 CSS 애니메이션과 CSS 트랜지션은 분리되어 구현되었으며 독립적으로 작성되어 동시에 재생할 필요가 없었습니다. 지난 몇년간 브라우저 구현자들은 동기화나 애니메이션 체인, 순차적으로 재생되고 애니메이션의 특정한 위치로의 이동, 애니메이션의 재생 속도 변경이나 역재생 등과 같은 것을 지원하는 다음 세대의 애니메이션 모델을 위해 일해왔습니다. 이러한 노력이 W3C의 Web Animations 1.0을 정립하도록 하였습니다.
블링크팀은 Web Animation을 세상에 내보이기 위한 첫 걸음으로 기존 블링크의 CSS 애니메이션/트랜지션에 대한 C++ 구현을 Web Animaiton 엔진으로 대치하는 것입니다. 현재 그 마일스톤에 도달하여 많은 개발자들이 아무것도 깨지지 않고 구현에 매진하는 것이 더 중요하며, 무엇이 좋아졌고 나쁜지나 변경이 필요한 부분에 대한 피드백을 주기를 원하고 있습니다.
다음은 자바스크립트로 애니메이션의 생성, 변경, 조회를 제공하는 API의 구현이 될 것입니다. API는 여전히 자바스크립트 개발자에게 완전한 애니메이션 제어를 보여주면서 애니메이션이 (선언적인 문법을 사용하여 자바스크립트가 애니메이션을 생성하는 것을 관리하고 브라우저가 이를 컨트롤하여) 더 효율적으로 동작할 수 있도록 합니다.
우리는 강력한 애니메이션 조작을 위해 필요한 어떠한 기능도 놓지지 않았음을 확신하기 위해 제안된 API에 대한 활발한 피드백을 찾고 있습니다. 어떠한 새로운 기능이나 규격이라도 변경이 지속되고 있으므로 이제 여러분의 목소리를 들을 시간입니다. - public-fx@w3.org 메일링 리스트를 구독하고 기여하는 것이 이상적입니다. (그리고 제목에 [Web Animations]를 넣어주시면 효과적입니다.)
이미 CSS 애니메이션과 트랜지션을 강력하게 하고 있는 새로운 엔진을 지금 사용해보시고 어떤 이상한 점이라도 Chromium 버그 트래커에 포스팅해서 알 수 있도록 해주시기 바랍니다. 우리는 차세대 애니메이션 역량을 블링크로 제공하고 또한 새로운 모델의 구현에 커밋한 웹킷과 모질라와 같은 다른 브라우저 개발자와 일할 수 있기를 기대합니다.
)을 클릭하시기 바랍니다. [