[튜토리얼/한글화] 크롬 개발자도구로 비동기 자바스크립트 디버깅하기(Debugging Asynchronous JavaScript with Chrome DevTools)

HTML5Rocks에 +Pearl Chen의 '크롬 개발자도구로 비동기 자바스크립트 디버깅하기(Debugging Asynchronous JavaScript with Chrome DevTools)' 한글 튜토리얼이 업데이트되었습니다. 이번 번역은 한순보님께서 수고해주셨습니다. :)

"콜백에 의한 비동기 처리는 우리에게 성능이라는 한가지 장점과 사소해보이는 몇가지 단점을 같이 선물하였습니다. UI가 동작 중인 메인스레드에서 실행되는 자바스크립트에서 콜백에 의한 비동기 처리는 발생할 수 있는 성능 상의 문제를 해결하기 위한 최선의 방법이었습니다만 성능의 이점 대신 코드 작성은 좀 더 어려워졌고 선형적으로 디버깅할 수 있는 방법은 크게 복잡해졌습니다.  

코드에서 무엇을 어떻게 처리할 것인지는 여러분의 몫입니다만 불행하게도 디버깅 역시 그러하며 특히나 비동기 처리라면 개발 환경을 넘어선 코드에 대한 깊은 이해를 요구하는 경우가 많으며 최근과 같이 외부에서 작성된 자바스크립트 라이브러리들을 사용하는 환경에는 더욱 더 그렇습니다. 

크롬에서 추가된 비동기 자바스크립트에 대한 호출 스택과 왓치(Watch) 기능은 이러한 영역에서의 괴로움을 크게 줄여줄 것입니다."

TL;DR;

콜백 함수를 통해 비동기로 동작할 수 있는 능력은 자바스크립트를 특별하게 만드는 강력한 기능이지만 자바스크립트는 순차적으로만 실행되지 않으므로 디버깅 과정에서는 우리를 괴롭게 만듭니다.

다행스럽게도 이제 크롬 카나리 개발자 도구(DevTools)에서 비동기 자바스크립트 콜백이 포함된 호출 스택의 모두를 확인할 수 있습니다. 개발자 도구에서 비동기 콜 스택 기능을 활성화하면 다양한 지점에서 각 지점에서의 상태를 자세히 볼 수 있으며 스택을 추적해 가면서 런타임 실행에서 특정 지점의 어떤 변수 값을 분석할 수도 있습니다.

[그림] 크롬 개발자도구의 비동기 호출 스택 추적

현재 개발자 도구에서 호출 스택을 확인할 수 있는 비동기 콜백의 종류는 다음과 같습니다.

• 타이머: setTimeout()이나 setInterval()의 초기화 지점으로 이동합니다.
• XHR: xhr.send() 호출 지점으로 이동합니다.
• 애니메이션 프레임: requestAnimationFrame의 호출 지점으로 이동합니다.
• 이벤트 리스너: 이벤트와 addEventListner()의 최초 바인딩 지점으로 이동합니다.
• addEventListner()는 성능 문제로 인해 개발자도구의 추적대상에서 제거되었습니다.
• MutationObserver: Mutation Observer 이벤트의 지점으로 이동합니다.

아래의 자바스크립트 API는 곧 이 기능을 지원할 예정입니다.

• Promise: Promise가 해결된(resolved) 위치로 이동합니다.
• Object.observe: 옵저버(Observer) 콜백을 처음에 바인딩한 지점으로 이동합니다.

자세한 내용은 튜토리얼을 참조하시기 바랍니다.

번역 링크

• 크롬 개발자도구로 비동기 자바스크립트 디버깅하기
• 원문 - Debugging Asynchronous JavaScript with Chrome DevTools
• 번역 - 크롬 개발자도구로 비동기 자바스크립트 디버깅하기

[튜토리얼/한글화] Build with Chrome: LEGO® 벽돌을 멀티디바이스 웹으로 옮기기(Build with Chrome: Bringing LEGO® bricks to the Multi-Device Web)

HTML5Rocks에 +Hans Eklund의 'Build with Chrome: LEGO® 벽돌을 멀티디바이스 웹으로 가져오기(Build with Chrome: Bringing LEGO® bricks to the Multi-Device Web)' 한글 튜토리얼이 업데이트되었습니다.

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()는 브라우저가 스크롤이나 전체 페이지의 스케일을 조정하는 것과 같은 예상치 못한 동작을 발생할 수 있는 터치 이벤트의 지속적인 처리를 막을 수 있습니다.

자세한 내용은 튜토리얼을 참조하시기 바랍니다.

번역 링크

• Build with Chrome: LEGO® 벽돌을 멀티디바이스 웹으로 옮기기
• 원문 - Build with Chrome: Bringing LEGO® bricks to the Multi-Device Web
• 번역 - Build with Chrome: LEGO® 벽돌을 멀티디바이스 웹으로 옮기기