2013년 12월 30일 월요일

[튜토리얼/한글화] CSS 페인트 타임과 페이지 렌더 가중치 (CSS Paint Times and Page Render Weight)

HTML5Rocks 'CSS 페인트 타임과 페이지 렌더 가중치(CSS Paint Times and Page Render Weight By +Colt McAnlis)' 한글 튜토리얼이 업데이트되었습니다.

이전에 포스팅한 렌더링 관련 튜토리얼들은 웹킷 혹은 크롬의 렌더링 모델이 취하는 구조나 그로 인한 렌더링 성능의 형태 및 최적화에 대해 논의한 글이었습니다. 그리고 이 튜토리얼은 조금 다른 관점에서의 렌더링 성능과 관련하여 가중치와 그 측정 방법에 대해 논의하고 있습니다. 특히, CSS의 속성들의 조합이 그 각각의 페인트 시간의 합보다 더 많은-심지어 훨씬 더 많은- 시간을 소모할 수 있다는 것은 특별히 더 염두에 두어야 할 내용 중의 하나입니다. :)

"GPU 기반으로 가속되는 그래픽스의 성능 향상은 웹에서도 많은 효과를 가능하도록 만들었습니다. 그러나 그래픽스 시스템이 가지는 특성으로 인해 이러한 효과들이 조합되는 경우 중 어떠한 것들은 우리가 기대하는 바와는 달리 더 많은 렌더링 시간을 차지하여 예상치 못한 성능 상의 영향을 주기도 합니다."



TL;DR;


크롬에서의 하드웨어 가속 경로는 페이지를 페이지의 시각적요소를 레스터화하여 타일들로 출력(Paint)하며 이를 합성(Compositing)을 통해 최종적으로 출력합니다. 그리고 CSS에 의한 렌더링 모듈은 각각이 다른 동작을 수행합니다. 그렇다면 그러한 다른 CSS 속성이 여러분의 페이지를 렌더링하는 비용에 어떤 영향을 줄까요?


  • 일반적으로 더 비싼 렌더링 비용이 드는 CSS 속성들이 있습니다. 예를 들어 opacity는 빠르게 처리되지만 그라데이션이나 그림자는 그렇지 않습니다.
  • CSS 속성의 조합은 그들 부분의 합보다 훨씬 더 많은 페인트 시간을 가질 수 있습니다. 즉, A와 B에 해당하는 2가지의 CSS가 하나의 엘리먼트에서 결합될 때 예상과는 다르게 A + B보다 렌더링의 시간이 더 걸린다는 것입니다.


정확하게 판별하자면 CSS의 속성뿐만이 아니라 그 값과 그에 이어지는 다른 속성과의 조합에 따라 성능은 달리 나타날 수 있습니다. (어떤 CSS 속성들이 비용을 발생하는지는 크롬 개발자도구의 Continuous Paint mode를 사용하여 알 수 있습니다.) 이 튜토리얼은 이러한 성능을 어떻게 평가할 수 있는지에 대한 기초적인 이해에 도움될 것입니다.


번역 링크

[튜토리얼/한글화] 객체 풀 기반의 정적 메모리 자바스크립트(Static Memory Javascript with Object Pools)

HTML5Rocks '객체 풀 기반의 정적 메모리 자바스크립트(Static Memory Javascript with Object Pools By +Colt McAnlis)' 한글 튜토리얼이 업데이트되었습니다.

아시다시피 자바스크립트에서는 자바와 마찬가지로 개발자가 직접 메모리를 관리할 필요가 없습니다. 이 둘은 전혀 다른 언어 스펙을 가지고 있지만 메모리 관리에 대해서는 가비지 콜렉션(Garbage Collection, 이하 GC)을 사용하기 때문입니다. 이번 튜토리얼은 이러한 GC의 동작을 회피하기 위해 정적으로 메모리 공간을 할당하고 이를 지속적으로 재사용하는 모델을 자바스크립트를 기반으로 설명합니다.

이번 번역은 김훈민님께서 수고해주셨습니다.  :)

"GC는 개발자가 메모리를 직접 관리하는 대신 경험적으로 효율적이라 판단되는 형태로 메모리를 자동으로 수거하고 관리합니다. 그러나 메모리의 할당/해제는 아주 오래된 성능 병목지점의 하나이기 때문에 직접적으로 관리하지 못하는 모델에서는 순간적인 지연으로 인한 멈칫거리는 현상이 발생하고는 합니다. 정적 메모리 모델은 모든 것에 대한 해답은 되지 못하지만 GC가 유일한 메모리 관리 모델인 이러한 경우들에서는 유일한 해결 방법이기도 합니다."



TL;DR;


가비지 콜렉터는 자동 메모리 관리의 한 형태입니다. 가비지 콜렉터는 가비지, 또는 프로그램이 사용하다가 더이상 필요가 없어진 객체가 점유하고 있는 메모리를 수거합니다. 그러나 메모리를 수거하는 과정은 비용이 들어감으로 인해 일정 시간이 지나면서 웹 게임/웹앱의 성능이 심하게 저하되는 이유 중의 하나는 가비지 콜렉션(Garbage collection) 실행으로 인한 것이라 할 수 있습니다. 이에 대한 해결 방법은 "메모리 변동(memory churn)"이라 불리는 지나친 객체 생성/제거를 가능한 막는 것이며 이것이 GC 동작을 줄이는 방법의 핵심입니다.

정적 메모리 JavaScript는 애플리케이션의 시작 시점에 실행하는 동안에 필요한 모든 메모리를 사전할당(pre-allocating)하고 객체가 더 이상 필요없어지면 실행 중에 메모리를 관리하는 테크닉입니다. 이 방법은 객체를 가비지 콜렉팅이 대상가 되지 않도록 유지하므로 GC가 성능에 미치는 영향을 줄일 수 있습니다. 함께 사용할 수 있는 추가적인 방법으로 객체 사전할당(Pre-allocating objects)을 통해 실행중에 동적으로 발생하는 객체 할당의 양을 줄일 수 있습니다.

그러나 객체 풀 자체가 GC가 발생하는 조건에 좀 더 가까워지도록 만들기 때문에 모든 애플리케이션에 적용할 수는 없으며 주의해서 사용해야 하는 테크닉이기도 합니다.

번역 링크

참고 글

2013년 12월 29일 일요일

[업데이트] Yeoman 월간 다이제스트 #2 (The Yeoman Monthly Digest #2)

+Addy Osmani가 'Yeoman 월간 다이제스트 #2'를 포스팅했습니다. 더불어서 +Jimmy Moon 님이 이번에 +Yeoman 코어팀 멤버가 되셨네요. 축하합니다! 기념해서 이번 요약 설명은 +Jimmy Moon님의 포스팅으로 대신합니다. :)

"+Yeoman 월간 다이제스트 2호가 발간 되었습니다. 이번호 에서는 grunt pro-tips 을 포함해서 역시 Yeoman 을 활용하는 다양한 Video, Tutorial 이 있습니다. MadJs, NetbraskaJS Meetup 의 강좌 비디오가 있구요 AngularJs, Ember.Js 그리고 Node.js 를 활용한 강좌와 Cordova 를 이용해서 만드는 Webapp 강좌가 있습니다. 
yo 는 1.0.7-pre 가 npm 에 올라와 있구요. Backbone, AngularJs, Ember.JS, WebApp, Polymer 그리고 Chrome App Generator 공식 제네레이터들이 버전업 되었습니다. 그외로 프레젠테이션으로 유명한 Reveal.js, Javascript 3D Library three.js 등의 커뮤니티 제네레이터들을 선정했습니다."

월간 다이제스트의 전문은 아래를 참고하시기 바랍니다.


Yeoman

Yeoman 월간 다이제스트 #2 전문


안녕, 안녕? 행복한 연휴되시길! 여러분이 좋아하시는 모자 쓴 남자와 함께 무엇이 새로워졌는지를 훤히 알 수 있는 우리의 공식적인 글들, 팁들, 생성기들 그리고 비디오들을 담고 있는 Yeoman의 월간 다이제스트의 2번째 이슈에 오신것을 환영합니다. 아래의 소식에서 도움되는 것을 찾을 수 있기를 바랍니다!


프로페셔널한 Grunt 조언들(Pro Tips)


존재하는 모든 Grunt 플러그인을 시도해는 것은 구미가 당기는 일입니다. 엄청 많고 많죠!! 게다가 흥분하기도 쉽습니다. 이를 깨닫기까지 여러분은 실제 사용보다 더 오랜 시간동안 터미널을 노려보고 있어야 할 것입니다. 이는 빌드를 하는 동안에도 좌절하는 일이지만 실제 터미널을 지켜보는 동안에도 훨씬 더 많이 좌절하게 만들 것입니다.

다행히도 커뮤니티는 개발 사이클은 한층 더 빠르게 만드데 노력을 기울여 왔습니다.
  • 커스텀 작업 트릭을 이용한 Grunt 의 컴파일 시간의 감소
  • 변경된 파일들에 대해서만 Grunt 작업을 실행하기 위한 grunt-newer의 사용
  • 작업을 병렬로 수행하는 grunt-concurrent을 실행하여 여러 작업들을 동시에 실행할 수 있도록 함
그외의 조언들은 다음과 같습니다.




생성기


yo 1.0.7-pre 버전은 현재 NPM에서 테스트 가능하며 차주 중에 2014년 로드맵에 대해 더논의할 것이 없는지 확인할 것입니다. 그 사이에 공식 생성기와 여러분들이 작성했던 것에 대한 새로운 업데이트들이 아래와 같이 흘러넘칠 지경입니다.


공식 생성기에 대한 업데이트


  • Backbone 0.2.2 버전 릴리즈
    • RequireJS와 CoffeeScript 지원
    • --appPath 옵션 지원
  • AngularJS 0.7.1 버전 릴리즈
    • Angular 1.2.6과 grunt-bower-install 지원
  • Ember.js 0.8.0 버전 릴리즈
    • Ember 1.2 문법에 대한 스캐폴딩 업데이트
    • CoffeeScript 지원
    • 템플릿 기능(Templating)
    • REST 라우터
  • WebApp 0.4.5 및 0.4.6 버전 릴리즈
    • 개선된 HTMLMin 포함
    • bower 인스톨 버그 수정
    • CSS 의존성을 지원하는 grunt-bower-install 포함
  • Polymer 생성기 0.0.8 버전 릴리즈
    • Web Component 연결(Concatenization) 및 다른 업데이트들
  • Chrome app 0.2.5 버전 릴리즈
    • 라이브리로드(Livereload)의 지원 개선
    • 앱 생성기의 재작성
    • 패키징을 위한 빌드 태스크
    • 새로운 권한 코드 등

jQuery, Gruntfile, CommonJS, NodeJS 및 Mocha를 포함한 다른 공식 생성기 역시 업데이트되었습니다.


커뮤니티 위주의 생성기들




요, 새해입니다(yo newyear!)


끝났습니다! 만약 다음 이슈에서 제안하시고 싶은 Yeoman 리소스들이 있다면, 트위터 @yeoman 혹은 구글플러스 +Yeoman에 그것들을 편안하게 제안해주시기 바라며 저희는 반드시 제안된 것들을 확인하도록 하겠습니다. 행복한 연휴되시고 환상적인 새해 맞으시기를 바랍니다!

이 이슈의 리뷰를 해준 Stephen Sawchuk, Sindre Sorhus 그리고 Pascal Hartig에게 특별히 감사드리며...


"Yeoman은 어떠한 프레임워크에 특화된 기반 구조(scaffold)들을  조합 가능한 생성기(Generator)를 이용한 작업흐름을 도와주는 도구입니다. Yeoman에 대해서는 Yeoman과 Polymer를 이용한 웹앱 개발(Building Web Apps With Yeoman And Polymer) 튜토리얼에서 자세하게 다루고 있으니 관심있으신 분들은 참고하시기 바랍니다."

2013년 12월 27일 금요일

[업데이트] 크롬 개발자도구 12월 요약(Chrome DevTools Digest December 2013)

크롬 개발자도구에 대한 요약이 11월 다이제스트에 이어 +Umar Hansa가 작성한 12월 버전이 나왔네요. 이전에는 튜토리얼이었지만 이번은 포스팅으로 제공되어 따로 번역에 대한 링크 없이 이 포스팅에서 전문을 다루도록 하겠습니다.

"여기서 다루는 기능은 기본적으로 크롬 Canary에서 동작합니다. 일반적으로 Official은 대부분 8~10주 뒤에 적용되므로 혼동이 없으시기 바랍니다. Chrome Canary Version은 여기에서 다운로드하시기 바랍니다."


크롬 개발자도구 12월 다이제스트


최근 많은 개선된 기능들이 크롬 개발자도구에 포함되고 있으며 몇 가지는 작은 것이지만 몇가지는 아주 큰 기능들입니다. 오늘은 엘리먼트 패널의 업데이트에 대한 이야기부터 시작하여 콘솔, 타임라인 등으로 주제를 넓혀나가보려 합니다.

비활성화되어 있는 스타일 규칙의 복사가 코멘트처럼 처리


Styles pane에서 전체 CSS 규칙을 복사하는 것은 이제 토글로 꺼둔것을 포함하며 클립보드에는 코멘트처리한 것처럼 존재하게 됩니다. [crbug.com/316532]

CSS 경로로써 복사하기


‘Copy as CSS path’가 이제 엘리먼트 패널의 DOM 노드의 메뉴 아이템에서 사용가능합니다. (Copy XPath 메뉴와 유사합니다.)


CSS 셀렉터의 생성은 여러분의 스타일시트/자바스크립트에 제한되지 않으며 WebDriver 테스트의 로케이터 전략으로 대체될 수도 있습니다.[crbug.com/277286]

쉐도우 DOM 엘리먼트 스타일 보기


이제 쉐도우 루트의 자식 엘리먼트는 별도로 확인 가능한 스타일을 가집니다. [crbug.com/279390]

콘솔의 copy()가 객체에 대해 동작


커맨드라인 API의 copy() 메소드가 이제 객체에 대해 동작합니다. 일단 가서 콘솔 패널에 copy({foo:'bar'})를 입력하고 어떻게 문자열화가 되는지와 객체의 형식화된 버전이 클립보드에 어떻게 남아 있는지 확인하시기 바랍니다. [crbug.com/289348]

콘솔을 위한 정규표현 필터


콘솔 패널에서 정규 표현식을 이용한 콘솔 메시지의 필터가 가능합니다.[crbug.com/318308]

손쉬운 이벤트 리스너 제거


콘솔 패널에서 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 노드에 대한 링크를 포함합니다.


이미지 URL 링크는 리소스 패널에서 관련된 리소스를 찾을 수 있도록 해줍니다. [crbug.com/244159]

GPU 프레임


GPU에서 발생하는 프레임들은 이제 최상단 및 메인 스레드 상의 프레임 위에서 보여집니다. [crbug.com/305863]

popstate 리스너 상에서의 브레이크


'popstate'는 이제 Sources panel의 사이드바에서 이벤트 리스너 중단점처럼 사용이 가능합니다. [crbug.com/88112]

렌더링 설정의 서랍(Drawer) 기능


서랍을 열면 이제 많은 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]

개발자도구의 테마가 이제 Extension을 통해 가능


사용자의 스타일시트가 개발자도구에 대한 커스텀 스타일을 적용하기 위한 크롬 익스텐션을 허가하는 개발자도구의 실험실 기능("Allow custom UI themes" 체크박스)을 통해 가능합니다. Sample DevTools Theme Extension에서 예제를 보실 수 있습니다. [crbug.com/318566]


개발자도구 요약의 이번 에디션은 여기까지입니다. 기존 것을 보신 적이 없으시다면 11월 에디션도 확인해보시기 바랍니다.

참조 링크

2013년 12월 23일 월요일

[업데이트] 블링크의 CSS 애니메이션/트랜지션 엔진이 웹 애니메이션으로 대체되었습니다.

이미 이에 대해 포스팅한 바를 보셨을 것입니다. Web Animaiton은 기존의 CSS 애니메이션 및 트랜지션, SVG 애니메이션과 SMIL 등 기존의 애니메이션 요소를 자바스크립트로 동적 제어가 가능하도록 정의하고 있는 새로운 애니메이션 규격입니다. -그렇다고 해서 아주 새로운 것은 아닙니다. 기존 CSS 애니메이션/트랜지션이나 SVG, SMIL 등의 기존 기술에 대한 '제어'를 주된 목표로 두고 있다고 이해하셔도 무방합니다.-

이에 대한 시작으로 Web Animations의 자바스크립트 API 구현을 참조할 수 있는 Polyfill 라이브러리인 web-animtations.js이 진행되고 있습니다. 현재 블링크(Blink)에는 이 기능을 네이티브로 구현하는 작업이 진행 중인데 이에 대한 첫 단계로 크롬 카나리에서 기존 CSS 애니메이션과 트랜지션 엔진이 Web Animation 구현 엔진으로 대치되어 배포되고 있습니다.

현재는 JS API가 존재하지 않으므로 외부에서는 차이점을 느끼기 힘들겠지만 대략 2월 말에는 공식 버전으로도 배포가 될 예정입니다. (물론 이는 JS API를 포함하지는 않습니다.) 아래는 HTML5Rocks에 +Alex Danilo 가 올린 업데이트 'New Web Animations engine in Blink drives CSS Animations & Transitions'에 대한 번역입니다. 실제 API의 구현 및 동작에 대해서는 아래 참조 링크에서 확인하시기 바랍니다. :)


전문


사용자들은 멀티 디바이스 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 버그 트래커에 포스팅해서 알 수 있도록 해주시기 바랍니다. 우리는 차세대 애니메이션 역량을 블링크로 제공하고 또한 새로운 모델의 구현에 커밋한 웹킷과 모질라와 같은 다른 브라우저 개발자와 일할 수 있기를 기대합니다.

참조링크

2013년 12월 18일 수요일

[튜토리얼/한글화] 레이서 게임의 구축(Case Study: Building Racer)

HTML5Rocks '사례연구: 레이서 게임의 구축(Case Study: Building Racer)' 한글 튜토리얼이 업데이트되었습니다.

이전 튜토리얼인 사례연구: Racer의 사운드(Case Study: The Sounds of Racer)에서는 레이서 게임 내의 사운드 구축을 위한 개발 과정과 기술에 대해서 다루었습니다면 이번 튜토리얼에서는 게임을 구축하기 위한 나머지 과정, 특히 렌더링에 대한 내용을 주로 다루고 있습니다. HTML5 게임이나 인터랙티브 컨텐츠를 개발하시거나 계획 중이시라면 읽어보시면 좋을 듯 합니다. 이번 번역은 신현진님(+Hyunjin Shin)께서 수고해주셨습니다.  :)




TL;DR;


레이서는 5명의 친구가 폰이나 태블릿을 이용하여 게임을 진행할 수 있도록 Google Creative Lab과 Plan8의 사운드를 기반으로 8주간 진행되어 Google I/0 2013에서 발표된 실제 이론에 기반한 웹 기반 크롬 실험 형태의 게임입니다. 이번 글에서는 개발자 커뮤니티에서 주로 질의되었던 몇가지 동작 방식에 대한 내용과 레이서의 주요 기능 및 질의 사항에 대한 응답을 정리하였습니다.

트랙을 그리기 위해 해상도를 설정하고 이를 그리기 위한 로직, CSS 애니메이션과 CSS 스프라이트를 통한 렌더링 팁, 실제 게임 내에서 자동차를 렌더링하기 위해 트랜스폼을 어떻게 사용하였는지와 실제 디바이스 간의 동기화를 위해 지연 시간을 계산하고 이를 보정한 방법을 실제 코드와 함께 설명합니다.

아래는 그 중 일부 중요한 내용만 따로 차용한 것입니다.
  • 모바일 디바이스의 해상도 변화에 대응하기 위한 해상도 설정
  • CSS 스프라이트시트를 이용한 스프라이트 애니메이션
  • 궤적의 변화에 따른 애니메이션 처리를 위한 실시간 트랜스폼 연산 및 적용
  • 동기화를 위한 지연 시간의 계산 및 라운드 트립
자세한 내용은 본문을 참조하시기 바랍니다.

번역 링크

참고 글

2013년 12월 16일 월요일

[튜토리얼/한글화] 자바스크립트 Promise: 또 다른 시작(JavaScript Promise: There and Back Again)

HTML5Rocks에 내리는 눈과 함께 기대했던 +Jake Archibald 의 "자바스크립트 Promise: 또 다른 시작(JavaScript Promise: There and Back Again)"이 업데이트되었습니다.
"참고로 There and Back Again은 영화 The Hobbit 3부작 중 마지막 편의 제목이기도 합니다. 뜻밖의 여정, 스마우그의 폐허는 일단 나왔으니 이어서 붙인 장난스러운 제목일지도 모르겠군요. :)"
자바스크립트의 비동기 동작으로 인해 콜백이 콜백을 부르고 다시 콜백이 콜백을 부른 과정이 중첩되다보면 내가 콜백인지 콜백이 나인지 헷갈릴 정도의 Callback Hell에 빠지게 됩니다. Promise는 이러한 비동기 동작을 손쉽게 처리할 수 있도록 고안된 비동기 프로그래밍 모델입니다.

이번 튜토리얼은 거의 작정하고 만든 듯이 완벽 해설서에 가깝습니다. Polyfill을 이용해서 당장 적용해보실 수도 있으니 비동기 콜백에 지치거나 그 지옥 한가운데에 있으시다면 잠시 코딩을 멈추시고 일단 읽어보시길 바랍니다.



TL;DR;


이 글은 브라우저의 지원 사항 및 Polyfill 소개, 다른 라이브러리와의 호환성, 복잡한 비동기 코드를 쉽게 만들기, XMLHttpRequest의 Promise화, Promise 객체의 체이닝(Chaining) 및 에러 핸들링, 병렬과 시퀀싱, Promise API 레퍼런스 등에 대해 다루며 이에 대한 예제들이 포함되어 있습니다. 지금까지 나온 Promise 관련 튜토리얼 중에 가장 자세한 내용이 아닐까 싶네요.


  • 이벤트는 비동기적인 모듈의 동작 결과를 처리하는 최고의 방법 중의 하나입니다만 콜백 형태의 호출이 꼬리를 물어가는 콜백 지옥(Callback Hell)에 빠지게 되는 것은 개발자에게는 일종의 불행과도 같습니다. Promise는 이를 순차적인(동기화)된 듯한 개발 방법을 제공합니다. 코드가 읽기 쉬워지고 콜백의 분기처리를 익숙한 순차적인 처리가 가능해지기 때문에 복잡한 콜백이 얽히는 과정에는 훌륭한 모델을 제공할 수 있습니다.
  • Promise에 대한 개념을 잡아보고 현재 브라우저 지원 상황 및 대체 라이브러리(Polyfill), 다른 라이브러리들과의 호환성을 소개합니다.
  • 실제 예제로는 복잡한 비동기 코드를 좀더 쉽게 만들기 위한 코드를 예제로 동기화된 모듈로부터 비동기화된 모듈, 그리고 최종적으로는 Promise화된 모듈의 구현 사항들을 순서대로 진행합니다.
  • 이 과정에서 Promise의 연결을 구현하는 체이닝(Chaining)과 에러 핸들링, 그리고 비동기적인 처리를 동시 수행하면서 필요한 로직을 Promise를 통해 순차적으로 처리하는 방법을 다루고 Promise API 레퍼런스를 수록하고 있습니다.


튜토리얼 링크

[업데이트] 안드로이드 버전 32부터 300ms 탭 딜레이 제거 가능!

전통적으로 모바일 브라우저는 PC의 그것과는 조금 다른 300ms의 클릭 딜레이를 가져왔습니다. PC의 경우 주로 마우스를 사용하였으므로 사실 클릭의 딜레이는 시스템에 따라 더블클릭을 구분하기 위한 시간차 정도였거나 없는 경우가 대다수였습니다만 터치를 기반으로 하는 모바일 디바이스의 경우 사용자의 탭 제스쳐 자체가 이후의 많은 연결 동작(예를 들어 스크롤, 핀치 줌 등)과의 이슈가 존재했습니다.



이러한 300ms의 딜레이가 모바일 디바이스에서 웹 사용자들에게 미묘하고 지속적으로 늦은 반응을 인식하게 만든 장본인이기도 합니다. 아무튼 시스템이 다음 동작을 판별하기 위한 일반적인 시간 딜레이값이 300ms 였습니다만 사용자가 핀치 줌 제스처를 이용하는 것을 비활성화함으로써 Chrome For Android Version 32부터 이를 제거할 수 있습니다.


간략하게 정리하면 다음과 같은 선결 조건이 있습니다.

  • Chrome For Android version 32 이상 혹은 Firefox for Android
  • 다음과 같이 메타 태그를 통해 핀치 줌(Pinch Zoom) 제스처를 사용하는 사용자 스케일을 막을 것

<meta name="viewport" content="width=device-width, user-scalable=no">

참조링크


"마이크로소프트에서 제안했던 Pointer 이벤트(터치와 마우스를 동시에 지원하는 이벤트 규격)에 브라우저 벤더들이 동의를 하는 것 같은데 표준안 처리 이전에라도 빠르게 다른 브라우저에서도 구현되었으면 좋겠네요."

2013년 12월 13일 금요일

[튜토리얼/한글화] 중간계의 프론트엔드: 멀티디바이스 개발의 여정(The Front-end of Middle-earth: A walkthrough of multi-device development)

HTML5Rocks에 새로운 튜토리얼 "중간계의 프론트엔드: 멀티디바이스 개발의 여정(The Front-end of Middle-earth: A walkthrough of multi-device development)"이 등록되었습니다.

이전에 게시되었던 튜토리얼이 모바일 상에서 WebGL, 3D Transform, 성능 최적화에 대한 개괄적인 접근을 다루었다면 이번 튜토리얼은 멀티 디바이스(PC, 태블릿, 폰)에 대한 직접적인 개발 방법을 논의하고 있습니다.

"오늘이 호빗의 개봉일이네요. 영화만큼이나 흥미로운 튜토리얼, 잘 감상하시길..."


TL;DR;


이전 튜토리얼이 모바일에서의 WebGL을 주로 다루었다면 이번 글은 나머지 HTML5 프론트엔드의 구현 사항에 대한 여러가지 이슈들과 해결 방법들에 대해 논의합니다.

멀티 디바이스 지원을 위한 스타일의 정의, 페이지의 전환을 위한 기법들, 랜딩 페이지를 다루기 위한 History API의 사용, 풀스크린의 지원, 애니메이션 시퀀스와 그 처리 방법, 리소스의 최적화, 페이지 성능 등에 대해 실제적인 사례를 기반으로 설명하고 있습니다. 실제 사이트를 참고하시면서 보시면 도움이 되리라 생각합니다.

튜토리얼 링크

2013년 12월 10일 화요일

[튜토리얼/한글화] 크롬의 렌더링 가속: 레이어 모델(Accelerated Rendering in Chrome : The Layer Model)

HTML5Rocks '크롬의 렌더링 가속: 레이어 모델(Accelerated Rendering in Chrome : The Layer Model)' 한글 튜토리얼이 업데이트되었습니다.

최근 제가 렌더링 최적화에 대한 튜토리얼은 되도록이면 이전 것들까지 번역하려고 노력하고 있는데 레이어(Layer) 모델은 브라우저가 렌더링을 하기 위한 동작에 대해 이해하는 가장 기초적인 개념이 될 것입니다. 이와 더불어 3D 그래픽스에 대한 약간의 지식만으로도 훨씬 더 나은 하드웨어 가속 렌더링에 대한 이해가 가능하므로 읽어보시기를 권장합니다.




TL;DR;


대다수의 웹 개발자들에게 웹 페이지의 일반적인 모델은 DOM이며  렌더링은 일반적으로 이러한 페이지의 표현 형태를 화면상의 이미지로 변환하는 과정입니다. 모던 브라우저들은 이 렌더링에 있어 최근 몇년동안 "하드웨어 가속"이라고 불리는 성능적 뒷받침을 받기 위해 노력해왔습니다.  이 글은 크롬에서 웹 컨텐츠의 하드웨어 가속 렌더링의 기반이 되는 기본 모델에 대해 설명합니다.

아래는 그 중 일부 중요한 내용만 따로 차용한 것입니다. 자세한 내용은 본문을 참조하시기 바랍니다.

DOM의 스크린 출력을 위한 개념적인 과정

  • DOM을 레이어들로 분리
  • 개별 레이어를 비트맵으로 출력
  • GPU 텍스쳐로 업로드
  • 다양한 레이어의 합성을 통해 스크린 출력


레이어(Layers)

  • DOM 구조는 렌더링할 때 브라우저는 개발자에게 직접 보여지지 않는 중간 표현의 연속 과정을 가지게 됩니다. 이 구조들 중 가장 중요한 것은 레이어입니다.
  • 레이어의 컨텐츠를 소프트웨어 비트맵으로 출력하여 GPU에 텍스쳐로 업로드
  • 업로드 후 합성(Composition)에 해당하는 렌더링은 가속됨


레이어 사용상의 주의점

  • 시스템과 GPU의 메모리의 낭비
  • 가시성 추적에 의한 로직 상의 부하
  • 레이어의 숫자/크기/겹침에 따른 픽셀화(Rasterizing)에 소모되는 시간의 증가 등


번역 링크

[튜토리얼/한글화] 사례연구: Racer의 사운드(Case Study: The Sounds of Racer)

HTML5Rocks '사례연구: Racer의 사운드(Case Study: The Sounds of Racer)' 튜토리얼이 업데이트되었습니다.

웹에서 오디오나 비디오는 사실 플래시만큼이나 애증의 대상입니다. 웹 컨텐츠를 가장 쉽게 풍성하게 보여주기도 하지만 그만큼이나 컨트롤은 어렵습니다. 이 튜토리얼은 슬롯 트랙에서 플레이되는 자동차 게임인 '레이서(Racer)'의 사운드 구현에 관련된 내용들을 담고 있습니다. 사실 오디오와 관련해서 웹 상에서 많은 리소스들이 있지는 않기 때문에 웹 오디오로 고민하시는 분들에게는 도움이 되리라 생각합니다. 특이한 구현 사례도 있고 많지는 않지만 오디오에 대한 지식도 조금 필요하기 때문에 필요한 부분만 읽으셔도 좋고 멀티미디어 컨텐츠 혹은 게임 개발자시라면 자세하게 읽어보시길 권해드립니다.

이번 번역은 +Hyunjin Shin님이 수고해주셨습니다. :)



TL;DR;


Racer Racer는 멀티플레이어 및 멀티디바이스로 동작하는 크롬 실험입니다. 여러개의 스크린에서 플레이하는 레트로 스타일의 슬롯 자동차 게임입니다. Android, iOS 폰 또는 태블릿에서 동작하며 누구나 참여할 수 있습니다. 앱이 아니며 다운로드도 없는 그저 모바일 웹일 뿐입니다.

이 게임은 다수의 사용자가 게임에 참가하고 참가한 사람들의 휴대폰을 일종의 다중 스피커로 활용합니다. 드럼과 베이스로 시작되어 기타와 신디사이저 등이 추가되는 음악 트랙이 만들어지는 형태입니다. 이 게임을 만들기 위해 필요한 내용을 다음과 같이 정리/제공합니다.

  1. 여러 개의 오디오 파일을 동기화하여 이용한 엔진 사운드의 구현 방법
  2. 버스트 요청을 샘플링하고 그것을 기준으로 낮은 레이턴시를 계산하여 네트워크를 통한 음원 재생 동기화
  3. 지연 누적으로 인해 긴 시간 동안 재생 후에 음악 레이어에서 전체적으로 동기화가 틀어지는 클럭 드리프트에 대한 해결
  4. 동적인 상태 변화를 위한 노래 스케줄링 및 오디오 재생 순서의 배치 전환 및 최적화
  5. 하나의 오디오 파일을 스프라이트처럼 응용한 오디오 스프라이트 사례

참고 글

[튜토리얼/한글화] 개발자도구에서 터미널 사용하기(Using Your Terminal From The DevTools)

+Addy Osmani의 '개발자도구에서 터미널 사용하기(Using Your Terminal From The DevTools)' 튜토리얼이 업데이트되었습니다.

웹 개발을 하다보면 터미널을 반복적으로 사용하게 되는 경우가 있으며 특히 Grunt나 별도의 빌드 및 배치 시스템을 가진 경우는 더 그렇습니다. 이번 튜토리얼은 크롬 개발자도구의 기능/실험실이 아닌 개발자도구에서 터미널을 사용할 수 있게 해주는 작지만 편리한 크롬 확장기능(Extension)입니다. 특히나 금번 튜토리얼은 소개에 가까우므로 커맨드라인 도구를 자주 쓰시는 분들은 한번 참조해보셔도 좋을 듯 합니다.

참고로 윈도우즈 사용하시는 분들은 별도의 문제점이 있는지 댓글 달아주실 수 있을까요? 며칠 전에 알려드린 한분이 자신은 윈도우라서 안되는 것인지 모르겠다고 하셨는데 조금 궁금하네요. :)



TL;DR;


크롬 개발자도구에서 터미널을 지원하는 것은 몇가지 이점이 있습니다. 브라우저와 편집기, 터미널을 오가며 바쁘게 컨텍스트를 변경하는 것보다는 같은 창 내에서 이를 진행하는 것이 효율적일 것입니다. 아래는 개발자도구와 터미널을 통합하여 사용하는 예입니다.

  1. 작업영역(Workspaces)
    1. 크롬 내의 웹앱을 편집하고 디버깅
    2. 서버 실행 시 로컬 프로젝트와 네트워크 파일들의 매핑
  2. 개발자도구 터미널
    1. git, yeoman과 같은 커맨드라인 기능 실행
    2. 앱을 미리보기 위한 새로운 서버를 실행
    3. 소스 컨트롤에 커밋
    4. 의존성 모듈들을 내려받기 위해 (npm, bower 같은) 패키지 관리자 사용
    5. (grunt, make 같은) 빌드 프로세스를 실행
제한점들
  • 다중 탭(Tab), 다중 윈도우, 뒤로가기(History playback)를 지원하지 않습니다.
    • 새로운 인스턴스를 여러개 띄우는 것으로 이를 대치할 수는 있습니다.
크롬을 통해 웹페이지 테스트를, 개발자 도구로 개발 및 디버깅을, 이 확장기능을 이용하여 터미널 빌드를 사용하는 것을 시도해보시기 바랍니다.

참고 글

2013년 12월 4일 수요일

[튜토리얼/한글화] 모바일을 위한 크롬 개발자도구: 스크린캐스트와 에뮬레이션(Chrome DevTools for Mobile: Screencast and Emulation)

+Paul Irish의 HTML5Rocks의 '모바일을 위한 크롬 개발자도구: 스크린캐스트와 에뮬레이션(Chrome DevTools for Mobile: Screencast and Emulation)' 튜토리얼이 업데이트되었습니다.

지난번 크롬 개발자 데이 이후부터 중간중간 크롬 개발자도구에서 직접적인 원격 디버깅과 화면 공유에 대해 이야기한 적이 있었는데 이번에는 그 모바일 디바이스에 대한 리모트 디버깅 시 유용하게 사용할 수 있는 '스크린캐스트(ScreenCast)'와 디바이스가 없거나 번거로울 때 사용할 수 있는 '에뮬레이션(Emulation)'에 대해 설명합니다. 모바일 개발자인데 모르고 계셨다면 꼭 읽으시길 추천해드립니다. :)



TL;DR;


모바일을 위해 개발하는 것은 데스크탑을 위해서 개발하는 것과 거의 비슷합니다. 이 글은 크롬 개발자도구에서 모바일 웹 개발 과정에서 디버깅을 크게 개선할 수 있는 새로운 기능인 리모트 디버깅(Remote Debugging)과 모바일 에뮬레이션(Emulation)에 대해 설명합니다.

  • 리모트 디버깅 - 디바이스에 대한 원격 디버깅
    1. 별다른 설정없이 간단한 과정으로 디바이스의 안드로이드 크롬에 직접 연결하여 디버깅을 지원합니다.
    2. 스크린캐스트(ScreenCast)를 이용하여 실제 디바이스 화면을 보지 않고 크롬 개발자도구에서 화면을 보고 인터랙션할 수 있습니다.
    3. (즉, 디바이스에서 직접 접근할 IP나 도메인이 없거나 불명확하게) 로컬호스트 등에서 실행되는 경우에도 포트 포워딩(Local Port Forwarding)로 이를 지원합니다.
  • 에뮬레이션 - 디바이스가 없을 경우의 에뮬레이션 및 디버깅
    1. 디바이스가 없을 경우에 화면 크기, devicePixelRatio, 메타 뷰포트 및 풀터치 이벤트에 대한 시뮬레이션을 지원합니다.
참고하시기 바랍니다.

참고 글

2013년 12월 2일 월요일

[튜토리얼/한글화] 크롬 개발자도구 11월 요약(Chrome DevTools November Digest)

HTML5Rocks의 '크롬 개발자도구 11월 요약(Chrome DevTools November Digest)' 튜토리얼이 업데이트되었습니다.

이제 크롬 개발자도구의 업데이트에 대한 요약이 주기적으로 이루어질 것 같네요. 매번 매뉴얼을 살펴보기 힘들거나 이미 개발자도구를 잘 사용하고 계시는 분이라면 이 다이제스트를 지속적으로 읽어보시는 것으로 신규 기능을 참조하시기 바랍니다.



TL;DR;


크롬 개발자도구는 빠르게 발전하고 있어 새로운 기능이나 개선점들에 대해 지속적인 안내가 필요합니다. 이글은 몇 가지 UI의 변경점들과 고해상도 자바스크립트 프로파일링, 새로운 작업공간(Workspace) 기능에 대해 설명합니다.


  1. 고해상도 프로파일링이 이제 .1ms 단위로 동작 가능합니다.
  2. 툴바가 개발자도구 상단에 위치하며, Overrides가 콘솔 드로어(Drawer)로 이동하였습니다.
  3. 파일을 추가/삭제/검색을 지원하는 몇가지 기능이 작업공간(Workspace)에 추가되었습니다.
이외에도 새로고침(refresh)를 좀 더 쉽게 호출할 수 있도록 context menu가 간소화되었네요. 참고하시기 바랍니다.

참고 글

[튜토리얼/한글화] 동기화된 크로스 디바이스 모바일 테스팅(Synchronized Cross-device Mobile Testing)

HTML5Rocks의 '동기화된 크로스 디바이스 모바일 테스팅(Synchronized Cross-device Mobile Testing)' 튜토리얼이 업데이트되었습니다.

다양한 모바일 디바이스에서 동시에 웹 페이지를 테스트할 때 사용 가능한 동기화 도구를 설명합니다. 개발자뿐만이 아니라 특히 웹 페이지의 수동 테스팅을 주업무로 하는 분들(QA 같은)이 읽어보시면 도움이 될 듯 합니다.



TL;DR;


모바일 디바이스는 이제 너무나도 많고 다양한 스펙 및 종류를 포함하고 있습니다. 특히 HTML5를 대상으로 하는 모바일 페이지의 경우 아직 정립되지 않은 개발 내용을 포함하는 경우도 있습니다. 이러한 디바이스에서 자주 수동 테스팅을 하는 경우 동일한 작업에 대한 시간적인 낭비가 심합니다. 이것을 어떻게 간소화할 수 있을까요?

이 글은 다양한 동기화 도구를 통해 동시에 다양한 디바이스에서의 수동 테스팅 방법을 설명합니다. 여러개의 도구를 설명하므로 상황에 맞추어 참고하시면 되겠습니다. 이 글에서 설명하는 도구는 다음과 같습니다.

  1. Ghostlab (Mac)
  2. Adobe Edge Inspect CC (Mac, Windows)
  3. Remote Preview (Mac, Windows, Linux)
  4. Grunt + Live-Reload (Mac, Windows, Linux)
  5. Emmet LiveStyle

참고 글

2013년 11월 28일 목요일

[튜토리얼/한글화] HTML Imports: 웹을 위한 #include(HTML Imports: #include for the web)

HTML5Rocks의 'HTML Imports: 웹을 위한 #include (HTML Imports: #include for the web)' 튜토리얼의 한국어 번역이 업데이트되었습니다.

HTML Imports 역시 이전의 Custom Element처럼 웹 컴포넌트를 지탱하는 4가지 규격 중의 하나입니다.


  1. Shadow DOM이 컴포넌트의 DOM, CSS, JS를 감추는 역할(encapsulation)을 하고
  2. HTML Template가 DOM의 복제 및 재 사용성을 제공하며
  3. Custom Element는 웹 문서에서 사용할 엘리먼트를 모듈에서 직접 등록할 수 있도록 하는 기능을 제공하여 컴포넌트의 명시적인 alias를 선언하는 역할을 한다면
  4. HTML Imports는 웹 문서 내에 외부 리소스를 포함(Import)하기 위한 기능을 제공합니다.

(사실 여기에 Decorator가 추가되는데 이 부분은 아직 정확하게 규격화가 되지 않아서 따로 진행되고 있는 바는 없습니다. 간략하게는 Web Component의 동적인 Enhancement에 대한 관리 방법을 제공하기 위한 규격으로 판단됩니다.)



TL;DR;


웹에서 각기 다른 형태의 리소스들은 개별적으로 로딩을 위한 메커니즘을 가지고 있고 이를 통해 개별적인 리소스에 대해서는 지속적으로 재사용 가능한 사례를 만들어 내고는 있습니다. 그렇다면 웹 컨텐츠(HTML, CSS, JS)는 어떤가요?

<iframe>의 경우 사용이 가능하며 실제적인 방법이지만 무겁고 세부적인 제어에 있어서는 굉장히 큰 노력을 필요로 하면서도 결국 불가능한 부분들이 있습니다. 그외에도 Ajax를 사용하거나 <script> 태그를 응용한 각종 핵(hack)이 존재합니다. 동작을 위한 정말 굉장한 노력을 필요로 하는 웹 컨텐츠(HTML/JS/CSS 등)에 대해 하나의 패키지처럼 관리하며 로딩할 수 있는 메커니즘이 있다면 어떨까요?

HTML Imports는 Web Components의 일부로 일컬어지는 HTML 문서를 다른 HTML 문서들에 가져오기 위한 방법입니다. 또한 Import는 CSS, JavaScript 혹은 '.html' 외의 어떠한 것도 가져올 수 있습니다. 다시 말해서 이러한 것이 Import를 HTML/CSS/JS의 로딩과 관련된 환상적인 도구로 자리잡아 줍니다.

이 글에서는 아래 내용에 대한 개념 설명과 예제를 설명하고 있습니다.

  1. 기본적인 HTML Imports의 개념 및 Bundling 등의 사용 방법
  2. 컨텐츠의 사용
  3. 웹 컴포넌트의 배포
  4. 성능에 관련된 고려 사항들

참고 글


2013년 11월 21일 목요일

[튜토리얼/한글화] '호빗' 체험 : 중간계를 실제로(The Hobbit Experience: Bringing Middle-Earth to Life with Mobile WebGL)

HTML5Rocks에 재미난 튜토리얼이 하나 올라왔네요. "'호빗' 체험 : 모바일 WebGL을 이용한 중간계를 실제로(The Hobbit Experience: Bringing Middle-Earth to Life with Mobile WebGL)"입니다.

개인적으로도 사랑해 마지 않는 J.R.R. 톨킨의 호빗: 스마우그의 폐허(The Hobbit: The Desolation of Smaug)에 대한 개발 및 접근 방법, 이슈에 대한 튜토리얼입니다. 구글 실험실(Experiment)에서도 손꼽힐만큼 잘만든 3D 비주얼 노블(Visual Novel)정도 될 것 같습니다. :)

모바일 같은 저사양(?) 디바이스에서 WebGL에 대한 적절한 접근 방법을 보여주고 어떻게 성능을 최적화하는지에 다루며 초기화나 (적은 수의 polygon, 저해상도 텍스쳐를 사용하는) 로우 폴리곤 모델이나 자바스크리브 최적화에 대해 간략하게 설명하고 있습니다. 컨텐츠 자체가 비주얼 노블이 주요 내용이라 WebGL이 지원되지 않는 디바이스에서도 대략적인 내용을 체험해볼 수 있는 이번 튜토리얼은 백문이 불여일견이네요. :)

"문득 당대의 신학 및 언어학자이자 판타지 문학의 시조로 불리는 톨킨이 살아 있다면 어떻게 볼까라는 생각도 듭니다. (굉장히 많은 언어를 습득했을 뿐만이 아니라 반지의 제왕 등의 본인 소설에서도 종족별 언어를 무려 '창조'해서 넣으신 분이죠.) '프로그래밍 언어도 굉장히 재미있군'이라고 얘기하지 않을까."

TL;DR;

WebGL을 이용한 3D 로우(Low) 폴리곤 모델, 자바스크립트 및 텍스쳐, 재질 등의 최적화나 최소한의 렌더링 동작을 위한 Frustum Culling 등 3D 최적화를 위한 요소들을 간략하게 설명하고 있습니다. (아주 예전에 3D 개발을 하셨거나 모바일에서 3D 개발하시는 분들에게는 친근한 내용이라 편하게 접근할 수 있을 것 같습니다.) 무엇보다 컨텐츠가 매우 볼만하네요.


참조 링크

2013년 11월 19일 화요일

[소식/Summit] Chrome Dev Summit 세션 소개 요약

귀국 후 첫포스팅이네요. 역시 인터넷은 한국이 빠릅니다. :+1:

내일부터 모레(20일부터 21일)까지 크롬 개발자 서밋(Chrome Dev. Summit)이 있습니다. 온라인으로 라이브도 진행한다고 합니다. Linus Upson, 크롬 엔지니어링 부사장의 Keynote 발표로 시작하여 성능 최적화(클라이언트와 네트워크 부분)부터 보안, 블링크, 폴리머까지 다양한 부분을 다루니 이에 대해서 요약해보는 것도 좋을 것 같습니다. 아래 링크 참조하시기 바랍니다.



주요 세션


#perfmatters: Optimizing network performance - +Ilya Grigorik

웹 사이트의 주요 병목 지점에 대한 네트워크 지연 사항에 대한 해결을 위해 어떠한 흐름으로 네트워크 성능을 수집하고 빠른 사이트로 변경할 수 있는지에 대해 설명합니다. (O'Reilly의 네트워크 성능 최적화 책도 있죠.)

Network connectivity: optional +Jake Archibald 

ApplicationCache를 이용하여 Offline 처리를 해왔는데 ServiceWorker API를 이용하여 Offline 어플리케이션 데이터를 어떻게 관리할 수 있는지 설명합니다. 당장은 넓게 적용할 수는 없는 규격이지만 ServiceWorker는 저도 이번에 TPAC2013 가서 처음 듣고 찾아보았는데 복잡하니 설명을 들어두는 것도 좋을 것 같습니다. Jake Archibald는 프리젠테이션 테크닉도 화려해서 기대하고 있습니다. :)

#perfmatters: 60fps layout and rendering +Tom Wiltzius+Nat Duca 

스크롤, 애니메이션, 터치 등의 최적화에 대한 몇가지 구축 방안과 크롬 개발자 도구를 이용한 성능 최적화의 방법에 대해서 설명합니다. 최근에 렌더링 성능 최적화 관련해서 몇가지 글에 대한 번역 소식을 전해 드린바 있는데 전반적인 정리가 필요하신 분들은 이 세션에서 한번에 들어보시는 것도 좋을 것 같습니다.

Dart for the modern web developer +Kasper Lund+Seth Ladd 

구글에서 이번에 Dart 1.0을 공식으로 릴리즈했습니다. 생소한 언어와 환경이니만큼 어떻게 이를 이용해서 웹 개발에 적용할 수 있는지와 자바스크립트와의 연동/변환 방법에 대해서 설명합니다.

Chrome DevTools for Mobile +Paul Irish 

크롬 개발자 도구를 이용하여 어떻게 모바일 웹을 개발할 수 있는지에 대해 전반적인 설명을 합니다. ScreenCast, Port Forwarding 등 개발자 도구의 크롬 모바일 지원 사항 관련해서는 지난번 Chrome Dev. Day 요약에서 살짝 설명드린바 있습니다.

Optimizing your workflow for a cross-device world +Matt Gaunt 

웹앱에서 멀티 디바이스/플랫폼 등에 대해 어떠한 방식으로 이들에 대한 검증을 할 수 있는지 테스팅 관련하여 설명을 한다고 하네요. 금번에 HTML5Rocks에서도 해당 튜토리얼이 올라올 예정이니 한번 보시고 튜토리얼을 읽어 보시는 것도 좋을 듯 하네요. :)

Polymer: declarative, encapsulated, and reusable components for the web +Eric Bidelman 

웹 컴포넌트에 대해서는 여러가지로 설명드린바 있고 이에 대한 튜토리얼들 역시 포스팅(Yeoman, Custom Element)한 바 있는데 웹 컴포넌트를 기존 모던 웹 브라우저에서 지원하기 위한 Polymer에 대해서 설명합니다. 최근에 핫한 오픈소스 프로젝트 중의 하나인데 미리 살펴보시길 바랍니다.

#perfmatters: Tooling techniques for the performance ninja +Colt McAnlis 

Colt McAnlis는 최근에 Image CompressionText Compression(참고로 텍스트 압축은 아직 번역 전입니다.)에 대한 글을 HTML5Rocks에 올린 적이 있는데 크롬 개발자 도구를 이용한 성능 최적화 방법에 대해 설명한다고 하네요. 개발 도구 관련해서 어떠한 부분을 설명할지는 모르겠지만 아마 리소스 송수신에 대한 부분이 아닐까 싶긴하네요. :)

Develop Chrome Apps on desktop/mobile, distribute and profit +Joe Marini 

크롬 앱을 이용한 개발 및 보안 관련한 내용에 대해서 설명하고 4개의 데스크탑 OS, 2개의 모바일 OS 상에서 시연한다고 합니다. (크롬 앱의 경우 모바일에서는 아직 지원이 되지 않지만 Cordova 플러그인을 통해 이를 개발할 수 있는 내용은 설명 드린 바 있습니다.)

Portable Native Client: How we Learned to Stop Compiling and Love the Translator +Molly Mackinlay+David Sehr 

얼마 전에 PNaCl도 릴리즈되었는데 크롬 기반에서 네이티브 기술을 이용하여 어떻게 플랫폼 독립적인 네이티브 연동 어플리케이션을 만들 수 있는지에 대해서 설명합니다. (개인적으로 보안 및 실행 모델에 대해서는 달리 얘기되기는 하지만 개발 환경에 대해서는 좀 궁금한 부분입니다.)

Got SSL? An overview of why you need it and how to do it right. +Parisa Tabriz 

간단하게 요약하면 웹 어플리케이션이 어떻게 SSL에서 보호되고 어떻게 구현되는지에 대해서 설명합니다.

Blink: Behind the scenes +Greg Simon+Eric Seidel 

크롬 28버전부터 렌더링 엔진이 Blink로 변경되었고 이제 크롬 안드로이드 역시 이를 사용합니다. 현재 어떻게 블링크가 진행되고 있는지 실제 웹 개발자들이 블링크로 인해 개발 시에 변경되는 부분(지원되는 부분)들은 어떤 것이 있는지 살펴본답니다. 앞으로의 계획에 대해서도 언급이 있을 듯 하니 살펴봐두는 것이 좋을 것 같습니다.

Build mobile apps with Chrome WebView +Matt Gaunt 

하이브리드 웹 앱을 개발하시는 분들이 좀 관심이 있으실 듯 한데 Chrome Webview가 킷캣부터는 꽤 많이 바뀌었죠. 크롬 웹뷰를 이용한 UI 개발, HTML5 기능 사용, Native UI 등에 대해 설명합니다.

Best UX patterns for mobile web apps +Paul Kinlan 

모바일 디바이스에서 다양한 형태의 스크린 및 해상도 그리고 터치 등으로 인해 많은 인터랙션 방식들이 제안되고 활용되고 있는데 +Paul Kinlan이 이에 대한 구축 이슈들과 활용 가능한 도구에 대해서 설명합니다.

Media APIs for the multi-platform web +Sam Dutton+Jan Linden 

비디오, 오디오, WebRTC, 웹 오디오 등을 활용하는 멀티 디바이스 웹 어플리케이션의 구축에 대해서 설명하고 어떻게 성능을 최적화할 수 있는지 모바일에 이를 구현하기 위한 방법등을 설명합니다. (Sam Dutton은 최근에 WebRTC에 대한 튜토리얼을 작성한 바 있습니다.)

#perfmatters: Instant mobile web apps +Bryan McQuade 

모바일 사용자들에게 쾌적한 환경을 제공하기 위한 렌더링 최적화를 위한 모바일 웹의 좋은 패턴과 안티 패턴들을 소개하고 성능에 치명적인 CSS와 HTML 문서 내에서 인라인 CSS의 장단점 등에 대해 소개합니다. (관심 가는 세션 중의 하나네요.)

Multi-device accessibility +Alice Boxhall

(장애인을 포함하여) 다양한 사용자에게 모던 웹사이트를 제공하기 위해 제공 및 사용할 수 있는 기술과 웹 기능, 크롬 기능을 설명하고 접근성과 디버깅에 관련된 몇가지 도구에 대해서 소개합니다. (해외에서의 웹 접근성에 대한 내용도 살펴보는 기회가 되겠네요.)



요약만 정리해도 양이 엄청 많네요. 동시 진행되는 세션은 없지만 이틀내내 지켜볼 수는 없으니 가능하면 나눠서 정리가 되면 좋을텐데 안되면 며칠을 나눠서 봐야겠네요. :(

2013년 11월 13일 수요일

[튜토리얼/한글화] V8의 자바스크립트 성능 관련 팁들(Performance Tips for JavaScript in V8)

+Chris Wilson의 'V8의 자바스크립트 성능 관련 팁들(Performance Tips for JavaScript in V8)'의 한글화 튜토리얼이 업데이트되었습니다. 번역해주신 김훈민님 감사합니다. 훈민님 사이트에 가시면 ECMA 스크립트와 자바스크립트 엔진에 대한 좋은 Overview들이 있으니 방문해보시기 바랍니다. :)

좋은 성능을 가진 코드의 작성을 하다보면 자연스럽게 실행의 Low Level에 도달하게 됩니다. (예를 들어 우리가 Native에서 어셈블리에 대해 대략적인 지식이 필요한 경우가 종종 존재하듯이 말이죠.) 실제로 자바스크립트의 규격뿐만이 아니라 엔진이 어떻게 자바스크립트 코드를 실행하고 최적화하는지에 대해 이해할 필요가 있으시다면 (특히 HTML5 3D나 대량의 연산을 위한 코드를 작성하고 계시다면) 읽어보시기 바랍니다.

"솔직하게 말씀드리면 V8 소스의 커밋 속도도 꽤 빠르게 진행됩니다. 최적화에 관련된 여러가지 요소가 지속적으로 추가되고 있지만 최소한 이 글에서 다루고 있는 내용은 아마 V8의 최적화에서 변하지 않을 내용들을 다루고 있으므로 숙지하시는 것도 좋을 듯 합니다. 다른 자바스크립트 엔진까지 자료를 취합할 수 있다면 더욱더 좋은 가이드가 만들어질 것 같습니다."


TL;DR;

이 글에서 다루는 V8의 자바스크립트 코드를 최적화 방식에 대해 이해하여 V8 엔진에서 최적화된 코드를 작성하는데 필요한 기본 지식과 간단한 예제, 지침을 담고 있습니다. :)


  • Hidden Classes
    • V8은 런타임 시에 객체에 사용하기 위해서 내부적으로 만든 hidden class을 통해 같은 hidden class를 가지고 있는 객체는 최적화된 생성 코드를 사용할 수 있습니다. 모든 객체 멤버를 생성자 함수 안에서 같은 순서로 객체 멤버를 초기화하는 형태의 코드를 통해 hidden class가 동적으로 변하지 않도록 유지하여 성능을 최적화할 수 있습니다.
  • Numbers
    • V8은 데이터 타입이 변할 때 효율적으로 값을 나타내는 태그를 사용하지만 동적인 태그를 변경하는 데에 비용이 들기 때문에 number 타입을 지속적으로 사용하는 것이 가장 좋습니다. 일반적으로 적합하다면 31비트 부호있는 정수를 사용하는 것이 최적입니다.
  • Arrays
    • 내부적으로 분리되어 처리되는 배열의 형태에 따라 최적화의 포인트는 달라질 수 있습니다. 가급적이면 연속적이고 단일한 타입을 가지며 동적으로 변환되지 않도록 배열을 유지하는 것이 중요합니다.
  • JavaScript Compilation
    • V8(크롬의 JavaScript 엔진)은 두가지의 다른 Just-In-Time(JIT) 컴파일러를 가지고 있습니다. Full Compilation과 Optimization Complation에 대해 간략한 이해를 통해 최적화된 성능을 위한 기본 지침을 제공합니다.


참조 링크

[튜토리얼/한글화] HTML에서 Custom Element를 통한 새로운 엘리먼트 정의하기(Custom Elements defining new elements in HTML)

HTML5Rocks의 'HTML에서 커스텀 엘리먼트를 이용한 새 엘리먼트를 정의하기(Custom Elements defining new elements in HTML)' 튜토리얼의 한국어 번역이 업데이트되었습니다.

Custom Element는 웹 컴포넌트를 지탱하는 4가지 규격 중의 하나입니다. Shadow DOM이 컴포넌트의 DOM, CSS, JS 등을 감추는 역할(encapsulation)을 하고, HTML Template가 DOM의 복제 및 재사용성을 제공하고, HTML Imports가 웹 문서 내에 외부 HTML 문서 리소스를 포함(Import)하기 위한 기능을 제공한다면 Custom Element는 웹 문서에서 사용할 엘리먼트를 모듈에서 직접 등록할 수 있도록 하는 기능을 제공하여 컴포넌트의 명시적인 alias를 선언하는 역할을 합니다.

이번 번역은 '신현진'님께서 진행하셨습니다. html5rocks.com 관련한 contribution 가이드도 번역을 해놓으셨네요. 관심있으신 분들은 방문해보시기 바랍니다. :)



TL;DR;


웹은 문서의 구조적인 형식을 가지고 있지만 HTML 엘리먼트가 미리 정의된 엘리먼트에 대해서만 사용 가능하다는 문제로 현재에도 웹앱을 구축하는데 있어서는 많은 이슈를 안고 있습니다. <div>가 끝도 없이 중첩되어 나타나는 <div> Soup가 대표적인 예입니다.

Custom Element는 HTML의 엘리먼트를 사용자가 문서에서 확장하여 사용할 수 있도록 기능을 제공하고 있으며 Web Components에서 가장 중요한 기본 API입니다. Web Components는 다음과 Custom Element에 의한 확장이 반드시 필요합니다.

이 글에서는 아래 내용에 대한 개념 설명과 구현 예제를 설명하고 있습니다.

  1. 새로운 HTML/DOM 엘리먼트 정의
  2. 다른 엘리먼트로부터 엘리먼트 확장
  3. 태그에 대한 사용자 기능의 확장
  4. 기존 DOM 엘리먼트 API 확장

참고 글


2013년 11월 8일 금요일

[튜토리얼/한글화] 고성능 애니메이션(High Performance Animations)

+Paul Lewis+Paul Irish 의 '고성능 애니메이션(High Performance Animations)' 튜토리얼이 등록되었습니다. 지난번 바캠프 요약에서 이에 대해 언급해드린 적이 있는데 브라우저의 GPU 가속과 연관된 HTML5 애니메이션의 성능 최적화에 관심있으신 분들은 반드시 읽어보시기를 권해드립니다.

"추가로 단지 애니메이션에만 해당하는 부분은 아닙니다. GPU와 관련된 웹 페이지의 렌더링 패스에 대한 이해는 프론트엔드에서 반응성 있는 웹페이지를 구현하는데 중요한 축입니다. +Paul Lewis 는 WebGL 기반의 3D 엔진인 three.js의 개발자로 렌더링 성능과 관련된 유용한 튜토리얼을 이미 올린바 있습니다. 이에 대한 부분은 참고 링크들에서 찾아보시기 바랍니다."

TL;DR;


CSS3 Animation과 Transition을 구현할 때 어떠한 속성이 하드웨어 가속이 가능한지 그리고 크롬 개발자 도구 '프레임(Frame)' 모드에서 볼수 있는 렌더링의 과정에 대해 각 엘리먼트가 어떻게 레이어로 변환되어 픽셀화(Rasterization) 과정이 이루어지는지에 대한 개괄적으로 설명합니다.

left, top을 이용한 위치 이동(좌)과 transform: translate()를 이용한 위치 이동(우)의 비교

본문에서 강조하는 고성능 애니메이션을 위한 CSS 속성 4가지는 다음과 같습니다.

  • 위치 이동
    • transform: translate()
  • 확대/축소
    • transform: scale()
  • 회전
    • transform: rotate()
  • 투명도
    • opacity: 0 ~ 1

참조 링크



p.s. 프로젝트로 번역이 많이 밀려있는데 차주에 예정된 3종에 대한 번역 커밋을 진행할 예정입니다. :)

2013년 11월 5일 화요일

[업데이트] 프론트엔드 개발 자동화(The Landscape Of Front-end Development Automation by Addy Osmani)

Addy Osmani가 FOWA에서 발표한 슬라이드를 블로그에 올렸네요. 결론을 얘기하자면 도구를 잘 선택해서 프론트엔드를 개발하자는 내용이고, 그 중에서도 Yeoman, Grunt, Bower에 대한 설명과 이들외의 다양한 개발 도구를 소개하고 그에 의한 효율성에 대해서 설명합니다. 아래에 블로그에 올라온 글만 번역해서 올립니다.

참조 링크


이전에 올라온 '[튜토리얼/한글화] 불필요한 페인팅 회피하기 : Animated GIF 에디션 외 3종'의 'Yeoman과 Polymer를 이용한 웹 앱 개발'에서도 이에 대한 내용이 나오니 참고하셔도 좋을 듯 합니다. :)




The Landscape Of Front-end Development Automation by Addy Osmani


요즘 모던 웹앱을 작성하는 것은 종종 지루한 프로세스처럼 느껴질 때가 있습니다. 프레임워크, 보일러플레이트, 추상화, 의존성 관리, 빌드 프로세스...프론트엔드 워크플로우의 요구 리스트는 매년 커져가는 것처럼 보인다. 그러나 이 많은 것을 자동화한다면 어떨까요?

FOWA(Future of Web Apps) 키노트 슬라이드에서 프론트엔드 생산성을 유지하는 도구들을 넓은 관점에서 다뤄봤습니다. 어떻게 도구를 통해 빠르고 실시간 피드백을 얻고 버그를 피할 수 있는지와 개발자 워크플로우에 기능적으로 포함할 수 있는지 알아봅시다.



몇가지 핵심 포인트


  • 워크플로우 자동화를 위한 데스크톱 도구는 단순한 프로젝트들의 시간을 절약합니다.
  • 커맨드라인 자동화 도구들은 보다 유연성이 필요한 복잡한 프로젝트들에서 더 좋습니다.
  • 생산성을 최대화하기 위해 개발 시 실시간 피드백을 주는 편집기를 사용하세요.
  • 크롬 Canary의 개발자도구의 새로운 저작 기능은 브라우저에서 쾌적한 편집 기능을 제공합니다.
  • Alfred 같은 생산성 도구를 통해 여러분의 시스템 워크플로우를 강화하세요.
  • 보다 나은 모바일 워크플로우를 위해 크로스 디바이스 테스트, 네트워크 병목 파악, 시각적 회귀 테스트를 사용하세요.

사용할 도구의 선택


프론트엔드 도구화는 지난 몇년간 먼 길을 걸어왔습니다. 즉, 더 이상의 복잡함을 고려하지 않아도 오늘 날의 웹 개발이 훌륭하다는 뜻입니다. 생산성을 유지하기 위한 핵심은 실제로 사용할 도구를 선택하는 것입니다. 개인의 워크플로우를 분석하는데 시간을 들이고 보다 효율적으로 여러분을 도와줄 수 있는 이러한 도구를 선택하세요.



[튜토리얼/한글화] WebRTC의 실제: STUN, TURN, 시그널링(WebRTC in the real world: STUN, TURN and signaling)

HTML5Rocks에 WebRTC의 전반적인 구조와 방식에 대해 설명하는 "WebRTC in the real world: STUN, TURN and signaling"가 업데이트되었습니다. WebRTC에 대해 공부를 시작하신 분들이나 개념을 잡으려 하시는 분들이 보시면 도움이 될 듯 합니다.


TL;DR;


WebRTC는 P2P 통신을 가능하게 하지만 구축에는 서버가 필요합니다. 클라이언트 간 데이터 교환을 위해 '시그널링(Signaling)'이라고 부르는 통신 설정의 수행 과정이 필요하며 이 과정을 통해 네트워크 주소 변환(NAT) 및 방화벽에 대응하게 됩니다.

이 글은 시그널링(Signaling) 서비스를 어떻게 구축하는지와 STUN 및 TURN 서버를 사용하여 실제 커넥션 상의 문제점을 처리하는지. 그리고 WebRTC 어플리케이션이 어떻게 다자간 통신을 처리하는지와 VoIP 및 PSTN(일반 전화망)과 같은 서비스와 상호 작용하지에 대해 설명합니다.

이 글에서 설명하는 내용들


  • 시그널링
    • 시그널링(Signaling)이란 무엇인가
    • 시그널링이 왜 WebRTC에서 정의되지 않았는가
    • 실제 연결을 위해 RTCPeerConnection을 사용하는 방법
    • 구현 및 Peer의 탐색 방법
  • 시그널링 서비스의 구축 방법
    • 서버에서 클라이언트로의 메세지 푸시
    • 시그널링 확장 방법
    • Node.js에서 Socket.io를 이용한 시그널링 서비스의 구축
    • 시그널링을 위한 RTCDataChannel의 사용
    • 기존 시그널링 서버들
    • 시그널링에서의 보안 
  • NAT와 방화벽을 대응하기 위한 STUN과 TURN 서버에 대한 설명
    • STUN - 외부에서 내부망에 대한 접근을 위한 방법을 제공
    • TURN - UDP를 우선으로 Peer 간의 직접적인 통신을 설정하고 이를 사용할 수 없을 경우 TCP/IP를 기반으로 종단 간의 데이터를 릴레이하는 방법을 제공
  • 기타 사항
    • 다자간 WebRTC
    • VoIP, 전화, 메시징의 활용 방법

참조 링크



2013년 11월 1일 금요일

[소식] Chrome Android WebView Update

Android 4.4 (킷캣)에서 Webview에 대한 추가 소식이 있네요. 웹뷰의 기반 버전은 크롬 30.0.0입니다. 대략적인 업데이트 사항은 아래를 참조하시기 바랍니다.



UserAgent 관련


Useragent에서 크롬 버전이 업데이트 되었습니다.

  • 기존 UA 
    • Mozilla/5.0 (Linux; U; Android 4.1.1; en-gb; Build/KLP) AppleWebKit/534.30 (KHTML, like Gecko) Version/4.0 Safari/534.30 
  • 신규 UA 
    • Mozilla/5.0 (Linux; Android 4.4; Nexus 5 Build/BuildID) AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 Chrome/30.0.0.0 Mobile Safari/537.36 

이와 관련하여 Chrome/30.0.0.0은 사용하지 마시고 Version/4.0과 같은 스트링을 사용하라는 가이드가 있네요.

XMLHttpRequest를 이용해서 자바스크립트에서 UA를 세팅할 수 없습니다. Useragent 세팅은 자바 코드에서 setUserAgent()를 이용해서 설정할 수 있습니다.



HTML5 신규 기능


HTML5 규격과 관련하여 다음 기능이 추가되었습니다.
  • WebGL 3D canvas 
  • WebRTC 
  • WebAudio 
  • Fullscreen API 
  • Form validation 

리모트 디버깅 지원


크롬 안드로이드뿐만이 아니라 웹뷰에 대해서도 크롬 개발자 도구를 통해 리모트 디버깅을 지원합니다.



기타


  • 크롬 앱은 아직 지원하지 않습니다. 
  • 하드웨어 가속은 기본 항목입니다.
    • 소프트웨어로만 구동할 경우 명시적으로 가속을 꺼야합니다. 

참고


2013년 10월 29일 화요일

[튜토리얼/한글화] 모바일에서 놀라운 풀스크린 환경 구축하기(Building Amazing fullscreen mobile experience)

지난 번 크롬 개발자 데이 관련 포스팅에서 크롬 안드로이드의 새로운 기능 중에 Fullscreen과 Add to Homescreen에 대한 언급이 있었는데 이와 관련하여 +Paul Kinlan 의 'Building Amazing fullscreen mobile experience(모바일에서 놀라운 풀스크린 환경 구축하기)' 튜토리얼이 올라왔습니다. 한국어 버전도 같이 올라왔으니 읽어보시기 바랍니다.


TL;DR;


기존의 풀스크린 동작은 트릭이나 핵(hack)을 이용하여 많이 접근되어 왔지만 최근 requestFullscreen() 과 같은 표준화된 규격을 기반으로 풀스크린을 구현할 수 있습니다. 이 글은 풀스크린의 구현 시 주의해야 할 점과 방법들에 대해 전반적으로 다룹니다.


관련 링크




p.s. HTML5Rocks에서 개선을 위한 이슈가 엄청나게 쏟아지고 있네요. 이번에 많이 바뀌나 봅니다. 그리고 이후 튜토리얼들은 가급적 동시에 한국어 업데이트를 진행할 예정입니다. :)

Summary: Chrome Barcamp Korea

10월 25일에 있었던 Chrome Barcamp에 참석했었습니다. 다양한 주제로 그룹을 나누어서 바캠프를 진행했는데 저는 Web Animation과 Google Web Designer, HTML5Rocks에 대해 몇 가지 개인적인 질의를 했습니다. 그와 별개로 Performance Optimization을 해보는 시간도 가졌습니다. (Thx to  +Alex Danilo+Paul Kinlan+Ryan Schoen & 긱한 개발자분. 그리고 보니 이름을 못들었다는...) 좋은 자리 마련해주신 +Soonson Kwon님께도 감사드립니다. 다른 분들의 후기도 기다려봅니다. :)


Web Animation


네이티브로 구현된 모듈은 시드니에서 개발 중이며 곧 블링크에 포함될 것이라고 합니다. 아마 내년 상반기에는 크롬에서 만나볼 수 있을 것 같습니다. 물론 현재도 Polyfill을 이용해서 사용해 볼 수 있습니다.

관련 링크



Google Web Designer


얼마 전에 웹 디자이너를 살며시 뜯어 봤을 때 도구를 포함한 내부 환경은 거의 HTML5로 구성이 되어 있었던 것으로 봤었는데 구현 상으로도 몇가지 얘기해볼 만한 사항들이 있었지만 이에 대한 것은 다음에 따로 정리해보도록 하겠습니다.

일단 구글 웹 디자이너 툴은 광고 컨텐츠에 대해 메인 포커싱을 하고 있다고 합니다. 내부적으로 WebGL에 대한 설정 부분이 예약되어 있는 것에 대한 부분은 프로젝트 팀이 달라서 답변을 듣지는 못했습니다. (예약이 되어 있는 만큼 어느 정도 3D 기반의 리치 미디어에 대한 접근도 고려하고 있는 것이 당연하겠죠.)


Performance Optimization


성능 최적화는 전날의 크롬 Developer Day에서도 많이 다루어졌듯이 레이어의 크기나 사이즈 부분이나 이동 시의 적합한 방식에 대하여 얘기했습니다. 그 중 몇가지를 간단하게 정리하기 전에 간략하게 브라우저의 렌더링 과정을 살펴보고 넘어가보도록 하겠습니다.
  • 브라우저 내 문서의 시각적인 각 엘리먼트는 대부분 하나 이상의 레이어라는 단위로 매핑되는 렌더링 트리를 구성하게 됩니다. 그리고 이 렌더링 트리를 브라우저가 렌더링을 하는데는 다음과 같은 몇가지 패스를 거치게 됩니다. 
    • 레이아웃(Layout)
    • 스타일(Style)의 계산
    • 페인팅(Painting)
    • 합성(Composition)
  • 반복되는 렌더링에서 한번의 패스는 반드시 모든 과정을 반복하지는 않으므로 패스 내에서의 동작을 최소화하는 방법이 성능 최적화의 주요 목표가 되겠습니다. 이와 관련된 자세한 내용은 아래의 참고 자료들을 읽어보시기 바랍니다.

실제적인 가이드라인 중 몇 가지를 살펴보면 다음과 같습니다.

  • 이동에 대한 애니메이션의 경우 top, left 대신 transform : translate() 사용
    • 레이어의 transform은 페인팅을 다시 요구하지 않으므로 translate()를 이용하여 동일한 시각적 효과를 얻을 수 있습니다.
    • 예시
      • -webkit-transform: translateX(-1px);
      • -webkit-transform: translateY(38px);
  • 레이어를 차지하는 엘리먼트는 가급적 사이즈와 갯수를 최소화
    • 간단하게 설명드리면 레이어가 크면 GPU 상의 메모리도 크게 차지하고 레이어의 갯수가 많으면 역시 메모리의 할당 숫자도 많아지므로 이를 회피하는 것이 중요합니다.
    • 비슷한 경우로 별로 중요하지 않은 레이어는 크기를 필요 크기보다 줄이고 (가급적 정수 배율로) scale()로 크기를 맞추는 것도 비슷한 효과를 얻을 수 있을 것으로 예상되네요. (게임에서 LOD를 사용하는 것과 마찬가지로 말이죠.)
  • 화면에서 보이지 않는 DOM의 경우 감추거나 제거
    • 위의 사항과 유사하기는 한데 일단 렌더링 트리가 줄어들어 탐색의 범위가 줄고 GPU 메모리 및 렌더링 패스에서 명시적으로 벗어나므로 성능 향상의 효과를 얻을 수 있을 것으로 보입니다. 렌더러에서도 메모리 관리 부담이 줄어드는 부수적인 효과가 있겠습니다.

이러한 렌더링 오버헤드는 개발자 도구에서 "Show Paint Rectangles"를 선택하거나 프로파일링을 통해 확인할 수 있습니다. 자세한 내용은 역시 아래 참고자료를 참조하세요.


참고자료



2013년 10월 25일 금요일

Summary: Chrome Developer Day Korea


10월 24일 선릉역 D.CAMP에서 크롬 개발자들이 다수 참석하여 개발자 데이 행사를 진행했습니다. 요약 대신해서 간략한 후기 남겨봅니다. 오밤 중에 대충 기억으로 적는 것이라 틀린 것도 많을 겁니다. 이해를...:)



What’s new in mobile HTML5


+Alex Danilo가 크롬 안드로이드와 관련된 신규 기능들에 대한 소개 발표였습니다. 안타깝게도  +Eiji Kitamura씨는 참석을 못했네요. :( 이 세션에서 나온 내용들은 간략하게 나열합니다. 참고로 아래 내용 중 현재 지원 가능한 부분과 아닌 부분들은 업데이트가 필요할 듯 합니다. 첫 세션이라 도저히 기억이 안나네요.
  • 크롬 안드로이드에서 chrome://flags 추가되었습니다.
  • viewports에 새롭게 vw, vh, vmin, vmax가 추가되었습니다. 단위는 전체 길이의 1%입니다.
  • position: sticky가 추가되었습니다. 상위 노드에 대해 fixed와 유사하게 동작합니다.
  • Fullsrceeen가 지원됩니다.
  • Semantic Input Type으로 효과적인 사용자 입력을 기대할 수 있습니다.
  • MS에서 제안 중인 Pointer event에 대한 얘기가 있었는데 아직 지원은 안됩니다. (IE11만 지원). Pointer 이벤트는 mouse와 touch의 통합형 이벤트입니다. 당연히도 필요하겠죠.  :)
  • 하드웨어 관련해서 Media Capture 지원됩니다. <input capture accepts=“image/*”> 처럼 기술하면 카메라로 사진 찍고 input으로 넘어갑니다.
  • WebAudio 됩니다. 입력은 지난번 포스팅에 나온 바와 같습니다.
  • Add Homescreen 기능이 추가되었습니다. 원래 애플이 apple- 접두어를 사용했었는데 일단 크롬에서도 apple- 접두어를 당분간 지원한다고 합니다. (이에 대해 정리해둔 글이 있었는데 어디에 올렸는지를 모르겠네요.)
  • 안드로이드 intents를 웹에서 바로 사용가능합니다. URL로 넘길 수 있습니다.
  • 성능 측정 관련해서 Navigation Timing API, Resource Timing API 추가되었습니다.



Polymer


'폴리머'는 현재 규격 작업이 진행 중인 Web Component를 모던 브라우저들에서 지원하기 위한 Polyfill 라이브러리입니다. Web Component가 표방하는 것이 하나의 완전한 웹 문서가 Encapsulation된 형태로 정의되고, 사용되고, 재사용되는 규격을 목표로 하는 만큼 빠르게 표준화가 되었으면 하고, 추가로 발표자인 +Eric Bidelman 이 궁극적으로 보일러플레이트를 소멸시키는 것이 목표라고 계속 얘기를 하더군요. 그랬으면 좋겠습니다. :)

웹 컴포넌트는 다음과 같이 4개의 규격으로 지탱됩니다.
  1. Shadow DOM - DOM 및 DOM, 자바스크립트에 대해 캡슐화를 지원합니다. 이 규격을 바탕으로 컴포넌트의 Content가 외부로부터 보호됩니다.
  2. HTML Template - 해석, 렌더링, 실행되지 않는 순수 템플릿 기능을 지원합니다. 이로부터 새로운 노드를 복제하거나 새로 생성하는 것이 가능하기 때문에 하나의 웹 컴포넌트로 다수의 인스턴스를 만들어 낼 수 있습니다.
  3. Custom Element - 기존의 DOM을 확장하거나 새로운 DOM을 생성합니다. 위에서 Shadow DOM과 HTML Template가 구조를 제공한다면 Custom Element는 타입의 확장과 정의 기능을 제공한다고 이해해도 되겠습니다.
  4. HTML Imports - HTML 문서를 특정한 위치로 적재하는 기능을 수행합니다. 일종의 로더라고 볼 수도 있겠습니다. 이 규격이 Web Component의 재사용성을 담보합니다.
요약하면 'Polymer'는 프레임워크 등에 대한 의존성 문제가 없기 때문에 생산성과 재사용성이 뛰어나고 특히 소프트웨어 공학면에서도 좋은 접근(Good Software Engineering)을 통한 일종의 OOP를 구현하는데 장점이 있습니다.

물론 현재는 폴리필 형태의 라이브러리이기 때문에  완벽한 encapsulation 등에 대한 부분이 실제로 완전히는 감춰지지 않는 이슈가 있을 수 있는 것도 문제이긴 하지만 이 정도로 잘 지원하는 것만 봐도 충분히 활용이 가능할 듯 합니다.

현재 폴리머에서 제공하고 있는 라이브러리도 쓸모가 많기 때문에 겸사겸사 공부해보는 것은 어떨까 싶습니다. 참고로 Yeoman을 사용하여 생산성을 유지하며 개발하는 것은 어떨까요?  Yeoman과 Polymer를 이용한 웹앱 개발를 읽어 보시길...1, 2년 정도면 Web Component 시대가 올 것 같다는 생각을 조심스럽게 해봅니다.



Workflow, DevTools mobile web


그 유명한 +Paul Irish의 발표였습니다. :) 일단 개발자 도구에 관련한 내용은 크롬 개발자도구 레볼루션 2013에서도 다루고 있기 때문에 크게 다른 부분은 없습니다. 정확하게 말하면 그 문서가 지속적으로 업데이트되고 있기 때문이기도 합니다. :)

어쨌던 가볍게 몇가지만 나열해보자면
  • 기존의 텍스트 에디터에서 수정하고 브라우저로 가서 확인하며 왔다갔다 하면서 개발하는 프로세스가 크롬 개발자도구로 완전히 통합되었습니다.
    • Workspace 설정 후 로컬 파일과 폴더 등을 매핑하면
      • 프로젝트 형태로 편집이 가능하고
      • 웹 문서뿐만이 아니라 서버사이드 스크립트 등의 수정이 가능하며
      • 스타일 창에서의 변경 역시 영구적으로 저장됩니다.
    • 즉, 인스펙터에서 수정하고 저장하면 실제 파일과 동기화됩니다.
  • Sass, Less 지원되고 디버깅도 됩니다.
  • 이 부분이 다들 좋아하는 부분 중에 하나인데 크롬에서 안드로이드 디바이스에 원격 디버깅이 지원됩니다. 
    • 간단하게 주소창에 about://inspect 치시면 디버깅이 연결됩니다.
    • 스크린캐스트를 통해 실제 디바이스의 화면을 보면서 PC 사이드에서 조작과 화면 확인, 디버깅이 가능합니다. (이거 무지무지 유용한 기능이죠.)
    • localhost 등으로 개발 중일 경우 역시 개발자 도구의 포트 포워딩을 통해서 l디버깅이 가능합니다.
  • 개발자도구를 이용하여 Layout, Style Recalculation, Paint, Composition의 프로파일을 디버깅하는 기능도 시연되었습니다.
    • continuous painting inspection을 이용하면 flowl 형태로 렌더링 오버헤드를 확인할 수 있다던가 프레임 렌더링 시간을 조사할 수 있고 이를 통해 스타일의 재계산 등을 막거나 개발자 도구의 프로파일링에서 추가적인 최적화 관련 정보 등을 확인할 수 있습니다.
    • 위 기능이 다 안되면 주소창에 about:tracing 를 써도 됩니다. 물론 좀 많이 불편합니다.



Creating HTML5 Games


+John McCutchan의 발표입니다. (Game과 Dart에 대해 두번 발표하더군요.)  HTML5 기반에서 게임을 개발하는데에 대한 일반적인 기능과 방식에 대해서 설명했습니다. 근데 이때 외부에서 전화가 와서 거의 다 놓쳤네요. :(

가능한 스택으로  Canvas, Web Audio, (P)NaCl 등을 예로 들었고 성능 상에 악영향 요소(Performance Traps)에서 '언제나 할당은 GC Pause로 한발 다가가는 것'이라고 얘기하더군요. GC는 언제쯤 어떻게 처리가 될런지 궁금합니다.

NaCl의 경우는 Security Model이 잘 지원되고 네이티브 기능을 확장하고자 할 때 사용할 수 있는 유용한 플러그인 개발 형태고 PPAPI를 통해 거의 모든 웹 요소들에 접근이 가능한 등의 장점을 얘기했습니다. 마지막에 HTML5 Games polymer에 대해서 얘기했는데 흥미로운 접근이었습니다. :)



Chrome Apps


+Pete LePage가 발표했습니다. 크롬 앱에 대해서 쭉 얘기를 해줬는데  오프라인, 하드웨어 제어, 기존 브라우저, 네이티브 기능 통합, 인프라 등의 이슈가 기존에 존재해왔으며 크롬 앱에서는 이러한 문제를 해결함과 동시에 크롬 웹 스토어에서 클라우드 서비스를 통해서  저장소 및 파일 등을 동기화하거나 푸시 메세지, 사용자 인증 및 정보, 앱 업데이트, 결제(1회성 결제 및 인앱 결제), 네이티브 기능 통합이 가능한 것에 대해 각각 설명했습니다.

재밌는 것은 크롬 앱을 통해서 USB나 블루투스 같은 외부 장치 연동이 가능하다는 점입니다. 몰랐는데 이게 되더군요. :)  네이티브 기능 통합의 예로 심장 박동 모니터를 연동해서 웹으로 박동수를 보여주는 데모와 LED 전등의 색상을 연동을 통해 제어하는 것을 보여줬습니다. 그리고 크롬만 되면 무슨 소용인가라는 의문에 대해 Cordova(Phonegap) 기반으로 만들어진 하이브리드 웹앱 패키징이 됩니다. 궁금하시면 http://github.com/MobileChromeApps/chrome-cordova로 방문!



Rendering without lumps


+Jake Archibald 의 아주 다이나믹한 세션이었습니다. :) Wii 컨트롤러로 프리젠테이션을 진행하는 것도 인상적이었지만 발표 노트와 마치 하나가 된듯한 물 흐르는 듯한 진행 기술을 가지고 있더군요. 그것보다 인상적인 것은 'W(hat)T(he)F(rame)P(er)S(econd)?' 였습니다. (진짜일까요? ㅋ)

간략하게 나누자면 웹 브라우저에서 DOM 트리는 CSS와 함께 덧붙여져서 Rendering 트리를 구성하게 됩니다. (이 과정에서 각 엘리먼트는 하나 이상의 레이어와 대응됩니다.) 이때 하나의 렌더링 노드를 그리는데는 크게 레이아웃, 스타일 계산, 페인팅, 결합(Composition)의 4단계를 하나의 패스로 거칠 수 있습니다. 물론 항상 모든 단계를 거치는 것은 아니고 간 단계가 실행되기 위한 선행 조건이 있습니다. 렌더링 성능 개선의 가장 기본이 바로 이 단계를 최대한 생략하기 위한 여러가지 방법들이 되겠습니다.

예를 들어 left 속성을 통해 X축 이동을 하는게 아니라 translate()를 이용하는 것은 같은 시각적 효과를 보여주지만 렌더링 패스는 전혀 다른 결과를 보여줍니다. 이외에도 z-index나 tranlateZ()를 이용해서 레이어를 별도로 관리하게 하는 등의 테크닉들도 시연이 있었습니다.

한가지 더 보자면 개발자 도구를 사용하여 렌더링, 레이어 결합 등이 어디서 발생하는지 확인하고 처리하는 방법도 함께 소개되었습니다. (렌더링 성능 관련해서는 여러 스피커가 언급을 했기 때문에 동일한 방법이 많이 나왔습니다. 불필요한 페인트 회피하기불필요한 페인트 회피하기 : Animated GIF 에디션를 함께 참고하세요.) 자세한 것은 http://speakerdeck.com/jaffathecake/rendering-without-lumps에서 한번 살펴보시길.



Build a fast mobile site with PageSpeed Mobile Insight


+Paul Kinlan 이 모바일 사이트에서 PageSpeed Mobile Insight를 이용한 모바일 웹 최적화에 대한 발표를 진행했습니다. 일단 PageSpeed Mobile Insight가 웹사이트에 대해 검사해주는 것은 다음과 같습니다.
  1. 리다이렉트의 횟수
  2. 비효율적인 압축 및 최소화(minification)
  3. CSS와 자바스크립트의 성능 상의 이슈 지점
  4. 캐시 이용률
CSS가 로딩되지 않거나 아직 해석되지 않은 시점에서 JavaScript가 Computed Style을 쿼리한다던가 하는 경우…즉, CSS, DOM에서 실행이 멈출 수 있다던지 해서 async나 defer를 이용해서 blocking을 막거나 압축을 통한 네트워크 대역폭 절약 등등 많은 내용이 있어 이것도 이후에 다시 정리합니다.

아, 초반에 "시작이 반이다"를 한글로 적어놓아 빵 터지고 '적합한 설계가 나쁜 효율성을 방지한다.'였던가로 적어놓은데서 눈물 한방울. :(



Introduction of DART


+John McCutchan의 2번째 세션, Dart도 흥미로웠습니다. 일단 Compile 형태의 개발 환경을 가지고 있지만 자바스크립트로의 변경도 가능하고 Dartrium이라는 DART VM + Chromium 형태의 브라우저에서의 JS 대비 성능 우위도 보여주더군요. 물론 VM은 Stand-alone으로 돌리거나 Dartrium에서 돌릴 수 밖에 없고 무엇보다 제가 이건 잘 모르므로 일단 넘어갑니다. :)

#

몇 가지 더 있었는데 정리가 어려워서 수정 및 다른 내용들은 차주로 미룹니다. :)