64
HTML5 관점에서 2014 모바일 개발 동향과 사례 발전 방향 전망 임상석 팀장 Web 기술 개발팀 Chief Technology Office, SK 플래닛

HTML5 관점에서 본 2014 모바일 웹 앱 개발 동향과 사례 및 발전 방향 전망

Embed Size (px)

DESCRIPTION

 

Citation preview

HTML5 관점에서 본2014 모바일 웹 앱 개발 동향과사례 및 발전 방향 전망

임상석 팀장Web 기술 개발팀Chief Technology Office, SK 플래닛

Agenda

● 시장 및 기술 현황 분석○ HTML5 시장 현황

● 개발 동향 및 사례○ HTML5 App UI○ HTML5 Game○ Hybrid App

● 발전 방향 전망○ 큰 흐름○ 기술 Keyword

HTML5 기회, 위기, 전망

● Click의 Web시대에서 Touch의 App시대 변천○ PC Web의 경험의 Mobile Web으로 이관의 실패

● Deep Link에서 App Link의 시대로 전환중○ Web간의 연결성에서 App Page의 단위의 연결성을 급속히 모색

● Hybrid App의 확산 및 이해도 증가○ App update 피로도 및 app store 통제 회피, 디자인/기획 친화적 생산성

● Android L/iOS8의 HTML5 호환성/성능 개선○ WebRTC, WebGL의 고급 기술 지원

HTML5 Hype Cycle: Hype, Hope, Hopeless?

2년 동안 이동

Hybrid Web App

Mobile Web

Thoughts on Flash (Steve Jobs)

● 6번째 가장 중요한 거부 이유

Facebook/Linkedin 철수 (2013)

2011년 Linkedin 자료

사용자 체류 시간이 긴 App의 경우 엔진의 메모리 누수로 불안정하고 이를 profiling할 개발 환경 또한 부재합니다.

Native SW 플랫폼 대체 전략 실패

● 개발 언어가 바뀐 “또 다른 플랫폼"○ Cross platform 하지 않음: Android, iOS, + HTML5○ 제대로 된 HTML5/JavaScript 개발자 공급 부족

● Ecosystem 구축 책임/중심체 부재○ Multi-sided platform 활성화는 누군가 비용/책임지고 투자/Subsidy 필수

● Web OS 상용화/활성화 지연○ Tizen, Firefox OS, WebOSTM

개발 비용 증가: Fragmentation 심화

● OS버전/OS종류에 따른 fragementation 발생○ iOS, Android 2.x - 4.x간의 fragmentation 처리 비용 높음○ Google Blink의 WebKit에서 분리로 1-2년내 추가 심화

● Kikat의 Chrome-powered WebView의 재앙○ Chrome-powered WebView의 HTML5 호환성이 Chorme Browser 대비 매우 낮음 -> Anroid L에서 개선

○ Canvas HW 가속 미지원으로 Canvas 게임 개발 업체 위기 봉착

HTML5 활용 전략 (SK planet 사례)

● HTML5를 SW Platform의 대체제로의 접근 전략○ 정부 주도로 RunTime의 확보 시도했으나 상업적으로 현재까지는 실패함

● 같은 전략을 고집하거나 되풀이 하는 것은 미련함○ 서비스회사 관점에서 필요 및 현실에 근거한 활용 전략 수립

● Hybrid App을 통한 상리 공생 전략으로 선회○ 서비스 회사 관점에서 순수 native app의 단점을 보완 할수 있는 장점을 극대화

■ no app update■ cross-platform (Android 및 iOS 동시 지원)

● 국내 현실에서 iOS 개발자 확보 및 개발 비용 증가■ designer-friendly■ 기획/디자인/개발 속도

● 11번가● 쇼킹딜십일시● Syrup 기프티콘

Web-centric vs App-centric (SK planet 사례)

● T store● Syrup● OK 캐쉬백

Web-centric- PC Web 기반 legacy를 App으로 확장- 속도/UX 개선을 위해 native로 기능 확장

App-centric- Native app으로 기획/개발- 효율적인 서비스 운영을 위해 Web 추가

Web-Native Hybrid Application - 속도, UX, 운영 효율 3가지를 모두 추구

Hybrid App - Type 1

● PhoneGap (by Adobe) 방식○ 전체 UI를 Webview 한장에 Single Page Web 형태 개발

○ Device API를 통한 Device 기능 접근

● Native 대비 낮은 성능 및 심미적 완성도○ 고품질 상용 consumer 용 App 개발시 널리 사용되지 않음○ 기업 고객용

WebView

Device API WebKit

HTML/CSS/JS

Hybrid App - Type 2

● Native App plugged Webview○ App의 기본 UI 및 기능은 Native로 구현○ 일부 View를 Webview를 통해서 URL loading○ Native-Webview binding: URL scheme

● 서비스 업체에서 널리 사용○ 기존 legacy Web 정보 연동 용이○ 운영상 view의 layout을 포함한 update가 잦은 GUI 구현○ App-store를 통하지 않은 배포로 빠른 서비스 update 가능○ QA 비용 절감

WebView(n개)

WebKit

HTML/CSS/JS

Native Widget

서비스 관점 HTML5 활용 장점

● 서비스 관점에서 진정한 cross-platform○ 모든 browser, Webview에서 동작○ fragmentation handling을 필수

● 빠른 서비스 개발 및 Update○ 기획 -> UX/디자인 -> publishing -> 개발 -> QA -> 배포○ App store는 통제 불가능

App update 강한 저항

교훈

● 100% native, 100% HTML5는 개발자 고집● 서비스 기획/개발/운영 관점에서 Hybrid App 개발이 현실적인 선택

● 사람/기술을 통한 Risk-hedging 필수

HTML5 개발 현실

성능 및 기능 Fragmentation

상용화 개발 사례: HTML5는 내 운명

● 고성능 HTML5 Web UI 개발● Canvas 기반 게임 개발

상용화 대상 단말 분석: 고객 OS 분포

OK Cashbag App (June, 2014)

the critical defect by Google

famo.us (open source)

● CSS3D + 물리 엔진 통합된 Web UI FW 공개 ○ DOM layout 비용 최소화, GPU 사용 극대화○ Android는 젤리빈 이상 지원○ 3D 및 물리 엔진으로 심미적 차별화: http://codepen.io/befamous/pen/eAlwd

● 고품질 UI의 개발 속도/생산성 최대 장점● Facebook HTML5 개발 책임자 합류

○ Dave Fetterman

● Samsung Ventures 투자중

고성능 HTML5 Web UI 개발(1/2)

● 데모가 아닌 상용화 개발○ Android 2.3 이상 (Galaxy S, Galaxy Note 지원 필수)○ Android 4.0.3 ,4.0.4 Webkit에 GPU Texture Upload 속도 문제

● 오픈 소스 FW으로는 상용화 수준 개발은 어려움○ jQuery Mobile, Sencha Touch○ 성능 튜닝은 필수

● Publishing 영역이 아닌 전통적인 개발 영역○ Browser 엔진 성능 특성을 이해한 HTML/CSS/JS 개발

고성능 HTML5 Web UI 개발(2/2)

● Browser 엔진 성능 특성 이해한 개발 필수● 성능 관련 Practice 요약

○ DOM 및 Render Tree의 복잡도 관리■ DOM, Render Tree의 생성 및 삭제 원리 이해

○ CSS 2D/3D 기반 GPU 가속 Rendering 효율적 활용■ Animation 단위 === RenderLayer/Graphics Layer 단위

○ 우선 순위가 높은 연산이 먼저 처리되도록 통제■ UI animation을 부드럽게 하기 위해 painting/network loading 미루기

○ DOM inspector를 활용한 profiling■ timeline, CPU, heap memory 분석

Browser Engine Overview(1/2)

● Browser 엔진○ WebKit by Apple○ Blink by Google

http://www.paulirish.com/2013/webkit-for-developers/

Browser Engine Overview(2/2)

● Platform porting layer○ fragmentation 원인

http://www.paulirish.com/2013/webkit-for-developers/

엔진 내부

● Parsing 하면서 내부 Tree 생성○ DOM, Render, RenderLayer, GraphicsLayer(GPU)

DOM Rendering: CSS2D/3D

● 2D/3D transform matrix by GPUrotate

scale translate

skew

DOM Rendering: CSS2D/3D by HW acceleration

● 2D/3D transform of DOM nodes by GPU

Penguin(Texture) Penguin

Penguin

Texture generation by CPU Texture based animation by GPU

Penguin(DOM Text Node)

Penguin

강력해진 개발 Tool 이해 및 활용 필수

● 지원 기능○ 엔진 내부 profiling○ GPU layer visualization

● DOM inspector 활용은 선택이 아닌 필수○ 고성능 Web UI 개발의 기본

Profiling: Timeline

async image loadinglayout 변경style 변경

Texture Visualization by Inspector(1)

Texture Visualization by Inspector(2)

핵심 메세지

● CPU에서 동작하는지 GPU에서 동작하는지 이해할 수 있는 팀/개발자 역량 및 도구 활용 필수

● Reference○ http://skpla.net/ScCT○ http://skpla.net/eTYB○ http://skpla.net/f58t

App-embedded Branded Casual Game

● 사업팀 요구사항○ In-app play를 통한 사용자 retention○ App store 통한 update 회피○ iOS/Android 동시 지원

<canvas> 기반 게임 개발

● 게임 Platform으로서 browser engine○ Rendering → Canvas

■ painting 속도 극복 필수

○ Audio → WebAudio/<audio>■ <audio> sound mixing 불가■ WebAudio 대부분 미지원

○ Resource Loader → <img>/XHR○ Animation → sprite image 관리○ Input → Touch○ 물리 엔진○ DPI 별 resource 관리

Cavas 기반 게임 엔진 필요

Mobile용 게임 엔진 자체 개발

● 기존 오픈소스 게임 엔진의 한계○ PC 향 게임에 적합한 기능 및 크기

○ mobile 특화 기능 미진으로 Android 2.3을 포함한 상용화 수준 달성 힘듬

● Mobile 특화 기능○ rendering 성능 최적화: 최소 20 fps (android 2.3 이상, iOS 6.0)○ garbage collection 최소화

Canvas 게임 핵심 로직

● 책장 넘기기 효과function drawObject(){ ctx.drawImage(obj, 0, 0);}

function loop() { clearCanvas(); moveObject(); drawObject() requestAnimationFrame(loop);}

게임 Rendering Back-end 구성

● <canvas> 2D: Game object rendering○ OS별 GPU HW acceleration 여부 상이

● DOM: Game UI○ OS별 GPU HW acceleration 여부 상이

WebView 내 <canvas>성능 분석

● “PAINTING” 성능이 치명적인 critical path○ <canvas> HW 가속 미지원

■ android 2.3이하, iOS 4.0 이하○ Kitkat chrome Webview의 치명적인 오류

■ 4.4, 4.4.2 Chrome Webview HW 가속 미지원■ 4.4.3에서 수정 배포, 그러나 이미 4.4.2의 국내 시장 점유율 70% 육박

■ 단통법으로 단말교체 주기 증가에 따라 4-5년 충격으로 남을 듯

Kitkat Webview 성능 분석

● 성능 제약 요인들○ painting 영역 크기○ canvas draw call 수○ DOM tree 복잡도(node 수 및 CSS 복잡도)

● System under test○ Optimus G Pro (4.4.2)○ Nexus 5 (4.4)

Performan Analysis 1

● Painting 영역 크기가 커지면 나빠짐

painting area size

fps

painting primitive 요청 수

Performance Analysis 2

● DOM 복잡도 증가시 fps 감소 및 fluctuation 발생

성능 개선 기술 요약

● 5가지 실용 테크닉○ DOM/<canvas> hybrid rendering○ Static object pool: GC supression○ invalidate 영역 추적을 통한 Smart repaint 기법○ Image resource offline 최적화○ DOM tree complexity 최소화를 위한 페이지 분리

● 모든 기술 동시 적용은 어려움○ 게임 시나리오, 성능 요구사항, 화면 구성등에 따라서 선택적으로 적용

DOM/<canvas> Hybrid Rendering painting size 최소화

● <canvas> 영역의 게임 object 일부를 선택적으로 DOM으로 rendering하여 GPU로 가속

canvas only canvas/DOM Hybrid

DOM/<canvas> Hybrid Rendering구현 상세: DOM node pool

● 게임 object를 출력을 위한 DOM node를 pool로 관리하여 재활용

Smart RepaintRepaint Region Trace

● 이전 frame buffer를 재활용● 현재 frame의 invalidate 영역을 추적하여 해당 부분만 repaint

Image 자원 최적화● 네트워크 요청을 줄여주는 sprite image가 일반적● 성능 이상 현상

○ crop을 하는 source 이미지가 커지면 커질수록 destinatoin 이미지와 상관 없이 성능 저하 발생: 최대 10% 저하

분리

Garbage Collector Stops The World

● 게임내 모든 object는 object pool을 통해서 할당/반납하여 재활용

<canvas> Isolation

● <canvas>를 내포한 DOM노드가 복잡할시 fps가 30%까지 swing○ 사용자 게임 play가 매우 불편

● <canvas> 를 DOM 기반 game UI에서 분리○ display:none, DOM remove, 별도 iframe로 일부 완화 가능하나 궁극적으로는 별도의 HTML로 분리가 최선

Case Study: Flappy Ball

● DOM/<canvas> hybrid● Smart repaint, sprite image separation

2048

● DOM/GPU only● Keeping GPU textures as long as possible

교훈

● Mobile에서 상품화 수준으로 성능 문제를 해결해주는 공짜 오픈 소스는 아직까지는 없다

● RunTime 동작 특성을 완벽히 분석하고 그에 맞는 게임을 개발할수 있는 역량 필수

● 자체 개발 게임 엔진 open source 공개○ http://skpla.net/bPqc

● Canvas 기반 게임 성능 상세 자료○ http://www.slideshare.net/infect2/korea-linuxforum2014-html5gamesangseoklim

Hybrid App 개발 Practice(1/2)

● WebView내 page와 native의 결합도○ 1단계

■ Webview를 통한 외부 URL 단순 loading■ native와 Web간에 통신이 전무

○ 2단계■ native와 communication channel(scheme callback)을 통한 data communication■ native 단과 WebView내 페이지 이중 login 등의 문제가 있음

○ 3단계■ native 부분과 WebView내 session 공유를 서버단에서 memcached등을 통해서 수행

Hybrid App 개발 Practice(2/2)

● 3단계 결합 예○ 서버 기반 session 공유

Native WebApp용 API 서버

Web용 API 서버

memcashed memcashed

Hybrid App 보안 이슈

● 2/3단계 밀겹합시 각종 해킹에 대한 보안 이슈 발생 대비 필요○ code 노출이 natvie 대비 쉽고, 변조 용이○ app과의 communication channel 및 data validation 필수

○ proxy등을 통한 변조된 Web page가 native 앱 내에서 동작시키는 경우에 대한 대비 필요

Native App Proxy

변조된Web Page(native app

call)

원래 Web Page

발전 방향 예측

경쟁 상호 보완

HTML5 기반 Business Model 구축

Business Model Generation Canvas

개발자

Service Provider

사용자

통신사업자

제조사

중립적인 SW Platform

cross platform 개발

Commericial오픈 소스 SWSDK 배포

Ecosystem개발자 커뮤니티

License Fee개발비 절감Consulting Fee

통신사업자

제조사

표준화 단체HTML5개발자

SW 개발 및 유지보수 비용

호환성 확보

제품 탑재 No Update / App store free 배포

Fragmentation 심화

● WebKit/Blink가 각자의 길○ Blink는 SW Platform 형태로 진화○ WebKit은 Web의 심미적 완성도를 높이는 방향으로 진화

● Chrome-powered WebView 재앙○ Canvas HW 가속 미 지원및 Accelerated Compositing 오류○ OEM버전 안드로이드 적용에 6개월 - 12개월 정도 소요 예상

● Fragmentation 처리가 HTML5 적용시 필수 역량

○ 상품화 수준 fragmentation handling을 지원하는 HTML5 App Framework이라면 solution으로 판매 가능한 시장 창출 될 것

자체 Web RunTime 도입 증가

● 도입시 Fragmentation의 Risk hedging 가능● Chromium, Firefox 오픈 소스를 활용하여 저렴하게 RunTime 확보 가능○ 예전 Web RunTime은 Android에서 미지원하던 HW GPU 가속 기능 및

HTML5 기능 구현으로 개발 비용 및 유지보수 비용이 발생

○ 오픈소스 빌드 후 binary 레벨에서 사이즈 최적화/배포 방식에 한하여 투자

● HTML5 eBook, 만화, Media 서비스등을 사업화 하고자 할 경우 Web RunTime 도입을 선택 가능

Web UI Framework 기술 혁신

● 3D 가미를 통한 심미적 개선○ WebGL 단말에서 지원 → 상용화 적용은 2-3년 소요 예상○ CSS 2D/3D 지원 수준 및 성능 상향 평준화○ CSS perspective property 지원 보편화

● WebWorker를 통한 multi-core 활용도 증가○ Box2D와 같은 computation-heavy library와의 결합을 통한 차별화 시도 가속

Hybrid 앱 보편화 및 앱내 경쟁 촉발

● Hybrid App 형태 개발 보편화○ SW Platform 보다는 서비스를 구현하는 특정 기능으로서 사용 확대

○ 서비스 핵심 가치를 보고 개발, 유지보수, 운영 관점에서 natvie/Web 영역을 정할 것임

○ Web 관련 부분 보안 강화 Solution 개발 및 적용

● 단일 App 내에서 Native/Web 경쟁○ Web 엔진의 근본적인 구조 변화가 수반 되지 않는 이상 PC에서와 같이

Web기반으로의 급격한 변화는 없을 듯

○ WebGL이 보편화되어 기존 DOM기반 architecture를 bypass 가능시 native 수준 달성 가능

디바이스 다변화

● TV, Wearable, Camera, 자동차를 통한 신규 디바이스를 통한 SW Platform으로서 진입○ 스마트폰으로의 진입은 Android/iOS 대항 가능한 수준의 ecosystem의 부재와 ecosystem 구축 비용을 투자할 만한 회사가 없는 상태

○ 서로 다른 디바이스간 cross-platform 적용은 쉽지 않을 것○ Firefox는 저가폰/개발 도상국 위주로 진입/확산○ 전문 HTML5/JavaScript 개발자 수요 증가

JavaScript 언어 영향력 증대

● JavaScript 언어의 시장 영향력 점진적 확대○ HTML5 서비스별 적용 확대○ node.js 도입을 통한 서버 영역 진출 확대○ node-webkit을 통한 desktop App 진출 가속○ Asm.js등 상용수준 발전에 따른 Browser 기반 게임 확대

JavaScript

PC App/ Node-webkit Mobile Web

Hybrid App서버 Web App/ Node.js

개발/기획자라면 관심 갖어야 할 기술 (1)

● Android/Chrome OS 통합○ 단순 SW 통합을 넘어서 Ecosystem 통합을 위한 전략으로 이해

● 단말 OS의 HTML5 기술 진보○ iOS 8

■ WebGL 지원, Webview에서 Jit 지원■ 개별 packaging된 Web app의 경우 바로 상품화 가능

○ Android L■ WebGL/Web RTC등을 지원 → UX 수준에서 fallback 처리 불가■ 디바이스 파편화로 iOS 대비 상용화 적용은 2-3년 소요 예상

● App deep link○ App linking 혁신으로 Web 수준의 연결성 제공 → Web에게는 위협 요인

개발/기획자라면 관심 갖어야 할 기술 (2)● Web components

○ 개발 효율화/생산성 혁신 시작

○ IE 호환성 문제로 장벽이 존재 하지만 사내 서비스나 Mobile 단말부터 도입 예상

● Installable Web App○ Android Chrome 38 버전부터 지원○ URL 입력 불편함 혁신

○ App store를 통한 App의 설치라는 사용자 인식의 전환도 동반이 되어야 함

● Web of thing○ Google의 “The Physical Web” project → 장기 과제이지만 관심을 둘만함

○ 모든 물리적인 사물에 URL을 부여 → 앱에서 Web 기반으로 회귀

제언

HTML5 상용화 적용에는 난관이 많지만,Browser-엔진의 이해를 바탕으로 상품화시,기술 차별적인 서비스 개발이 가능하므로,상업적인 활용 가치가 이미 충분하다