1. HTML5 관점에서 본
2014 모바일 웹 앱 개발 동향과
사례 및 발전 방향 전망
임상석 팀장
Web 기술 개발팀
Chief Technology Office, SK 플래닛
2. Agenda
● 시장 및 기술 현황 분석
○ HTML5 시장 현황
● 개발 동향 및 사례
○ HTML5 App UI
○ HTML5 Game
○ Hybrid App
● 발전 방향 전망
○ 큰 흐름
○ 기술 Keyword
3. 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의 고급 기술 지원
4. HTML5 Hype Cycle: Hype, Hope, Hopeless?
2년 동안 이동
Hybrid Web App
Mobile Web
6. Facebook/Linkedin 철수 (2013)
2011년 Linkedin 자료
사용자 체류 시간이 긴 App의 경우 엔진
의 메모리 누수로 불안정하고 이를
profiling할 개발 환경 또한 부재합니다.
7. Native SW 플랫폼 대체 전략 실패
● 개발 언어가 바뀐 “또 다른 플랫폼"
○ Cross platform 하지 않음: Android, iOS, + HTML5
○ 제대로 된 HTML5/JavaScript 개발자 공급 부족
● Ecosystem 구축 책임/중심체 부재
○ Multi-sided platform 활성화는 누군가 비용/책임지고 투자/Subsidy 필수
● Web OS 상용화/활성화 지연
○ Tizen, Firefox OS, WebOSTM
8. 개발 비용 증가: 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 게임 개발 업체 위기 봉착
9. HTML5 활용 전략 (SK planet 사례)
● HTML5를 SW Platform의 대체제로의 접근
전략
○ 정부 주도로 RunTime의 확보 시도했으나 상업적으로 현재까지는 실패
함
● 같은 전략을 고집하거나 되풀이 하는 것은 미
련함
○ 서비스회사 관점에서 필요 및 현실에 근거한 활용 전략 수립
● Hybrid App을 통한 상리 공생 전략으로 선회
○ 서비스 회사 관점에서 순수 native app의 단점을 극대화
10. Web-centric vs App-centric (SK planet 사례)
● 11번가
● 쇼킹딜십일시
● Syrup 기프티콘
● T store
● Syrup
● OK 캐쉬백
Web-centric
- PC Web 기반 legacy를 App으로 확장
- 속도/UX 개선을 위해 native로 기능 확
장
App-centric
- Native app으로 기획/개발
- 효율적인 서비스 운영을 위해 Web 추가
Web-Native Hybrid Application - 속도, UX, 운영 효율 3가지를 모두
추구
11. Hybrid App - Type 1
● PhoneGap (by Adobe) 방식
○ 전체 UI를 Webview 한장에 Single Page Web 형태 개발
○ Device API를 통한 Device 기능 접근
● Native 대비 낮은 성능 및 심미적 완성도
○ 고품질 상용 consumer 용 App 개발시 널리 사용되지 않음
○ 기업 고객용
HTML/CSS/JS
WebView
Device API WebKit
12. Hybrid App - Type 2
● Native App plugged Webview
○ App의 기본 UI 및 기능은 Native로 구현
○ 일부 View를 Webview를 통해서 URL loading
○ Native-Webview binding: URL scheme
● 서비스 업체에서 널리 사용
HTML/CSS/JS
WebView(n개)
WebKit
○ 기존 legacy Web 정보 연동 용이
○ 운영상 view의 layout을 포함한 update가 잦은 GUI 구현
○ App-store를 통하지 않은 배포로 빠른 서비스 update 가능
○ QA 비용 절감
Native
Widget
13. 서비스 관점 HTML5 활용 장점
● 서비스 관점에서 진정한 cross-platform
○ 모든 browser, Webview에서 동작
○ fragmentation handling을 필수
● 빠른 서비스 개발 및 Update
○ 기획 -> UX/디자인 -> publishing -> 개발 -> QA -> 배포
○ App store는 통제 불가능
17. 상용화 개발 사례: HTML5는 내 운명
● 고성능 HTML5 Web UI 개발
● Canvas 기반 게임 개발
18. 상용화 대상 단말 분석: 고객 OS 분포
OK Cashbag App (June, 2014)
the critical
defect by
Google
19. 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 투자중
20. 고성능 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 개발
21. 고성능 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 분석
22. Browser Engine Overview(1/2)
● Browser 엔진
○ WebKit by Apple
○ Blink by Google
http://www.paulirish.com/2013/webkit-for-developers/
26. DOM Rendering: CSS2D/3D by HW acceleration
● 2D/3D transform of DOM nodes by GPU
Penguin
(Texture)
Penguin
Penguin
Penguin
Penguin
(DOM Text Node)
Texture generation by CPU Texture based animation by GPU
27. 강력해진 개발 Tool 이해 및 활용 필수
● 지원 기능
○ 엔진 내부 profiling
○ GPU layer visualization
● DOM inspector 활용은 선택이 아닌 필수
○ 고성능 Web UI 개발의 기본
31. 핵심 메세지
● CPU에서 동작하는지 GPU에서 동작하는지
이해할 수 있는 팀/개발자 역량 및 도구 활용
필수
● Reference
○ http://skpla.net/ScCT
○ http://skpla.net/eTYB
○ http://skpla.net/f58t
32. App-embedded Branded Casual Game
● 사업팀 요구사항
○ In-app play를 통한 사용자 retention
○ App store 통한 update 회피
○ iOS/Android 동시 지원
33. <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 기반 게임 엔진 필
요
34. Mobile용 게임 엔진 자체 개발
● 기존 오픈소스 게임 엔진의 한계
○ PC 향 게임에 적합한 기능 및 크기
○ mobile 특화 기능 미진으로 Android 2.3을 포함한 상용화 수준 달성 힘
듬
● Mobile 특화 기능
○ rendering 성능 최적화: 최소 20 fps (android 2.3 이상, iOS 6.0)
○ garbage collection 최소화
35. Canvas 게임 핵심 로직
● 책장 넘기기 효과
function drawObject(){
ctx.drawImage(obj, 0, 0);
}
function loop() {
clearCanvas();
moveObject();
drawObject()
requestAnimationFrame(loop);
}
36. 게임 Rendering Back-end 구성
● <canvas> 2D: Game object rendering
○ OS별 GPU HW acceleration 여부 상이
● DOM: Game UI
○ OS별 GPU HW acceleration 여부 상이
37. 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년 충
격으로 남을 듯
38. Kitkat Webview 성능 분석
● 성능 제약 요인들
○ painting 영역 크기
○ canvas draw call 수
○ DOM tree 복잡도(node 수 및 CSS 복잡도)
● System under test
○ Optimus G Pro (4.4.2)
○ Nexus 5 (4.4)
39. Performan Analysis 1
● Painting 영역 크기가 커지면 나빠짐
painting area size
fps
painting primitive 요청 수
41. 성능 개선 기술 요약
● 5가지 실용 테크닉
○ DOM/<canvas> hybrid rendering
○ Static object pool: GC supression
○ invalidate 영역 추적을 통한 Smart repaint 기법
○ Image resource offline 최적화
○ DOM tree complexity 최소화를 위한 페이지 분리
● 모든 기술 동시 적용은 어려움
○ 게임 시나리오, 성능 요구사항, 화면 구성등에 따라서
선택적으로 적용
42. DOM/<canvas> Hybrid Rendering
painting size 최소화
● <canvas> 영역의 게임 object 일부를 선택적으로 DOM
으로 rendering하여 GPU로 가속
canvas only canvas/DOM Hybrid
47. <canvas> Isolation
● <canvas>를 내포한 DOM노드가 복잡할시
fps가 30%까지 swing
○ 사용자 게임 play가 매우 불편
● <canvas> 를 DOM 기반 game UI에서 분리
○ display:none, DOM remove, 별도 iframe로 일부 완화
가능하나 궁극적으로는 별도의 HTML로 분리가 최선
49. 2048
● DOM/GPU only
● Keeping GPU textures as long as possible
50. 교훈
● Mobile에서 상품화 수준으로 성능 문제를 해
결해주는 공짜 오픈 소스는 아직까지는 없다
● RunTime 동작 특성을 완벽히 분석하고 그에
맞는 게임을 개발할수 있는 역량 필수
● 자체 개발 게임 엔진 open source 공개
○ http://skpla.net/bPqc
● Canvas 기반 게임 성능 상세 자료
○ http://www.slideshare.net/infect2/korea-linuxforum2014-html5gamesangseoklim
51. 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등을 통해서 수행
52. Hybrid App 개발 Practice(2/2)
● 3단계 결합 예
○ 서버 기반 session 공유
Native Web
App용 API
서버
Web용 API
서버
memcashed memcashed
53. 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
55. HTML5 기반 Business Model 구축
개발자
Service
Provider
사용자
통신사업자
제조사
Business Model Generation Canvas
cross platform
개발
제품 탑재 No Update /
중립적인 SW
Platform
Ecosystem
개발자 커뮤니
티
Commericial
오픈 소스 SW
SDK 배포
License Fee
개발비 절감
Consulting Fee
통신사업자
제조사
표준화 단체
호환성 확보
HTML5
개발자
SW 개발 및 유지보수 비용
App store free
배포
56. Fragmentation 심화
● WebKit/Blink가 각자의 길
○ Blink는 SW Platform 형태로 진화
○ WebKit은 Web의 심미적 완성도를 높이는 방향으로 진화
● Chrome-powered WebView 재앙
○ Canvas HW 가속 미 지원및 Accelerated Compositing 오류
○ OEM버전 안드로이드 적용에 6개월 - 12개월 정도 소요 예상
● Fragmentation 처리가 HTML5 적용시 필수
역량
○ 상품화 수준 fragmentation handling을 지원하는 HTML5 App
57. 자체 Web RunTime 도입 증가
● 도입시 Fragmentation의 Risk hedging 가능
● Chromium, Firefox 오픈 소스를 활용하여 저
렴하게 RunTime 확보 가능
○ 예전 Web RunTime은 Android에서 미지원하던 HW GPU 가속 기능 및
HTML5 기능 구현으로 개발 비용 및 유지보수 비용이 발생
○ 오픈소스 빌드 후 binary 레벨에서 사이즈 최적화/배포 방식에 한하여
투자
● HTML5 eBook, 만화, Media 서비스등을 사업
Web RunTime
58. Web UI Framework 기술 혁신
● 3D 가미를 통한 심미적 개선
○ WebGL 단말에서 지원 → 상용화 적용은 2-3년 소요 예상
○ CSS 2D/3D 지원 수준 및 성능 상향 평준화
○ CSS perspective property 지원 보편화
● WebWorker를 통한 multi-core 활용도 증가
○ Box2D와 같은 computation-heavy library와의 결합을 통한 차별화 시도
가속
59. Hybrid 앱 보편화 및 앱내 경쟁 촉발
● Hybrid App 형태 개발 보편화
○ SW Platform 보다는 서비스를 구현하는 특정 기능으로서 사용 확대
○ 서비스 핵심 가치를 보고 개발, 유지보수, 운영 관점에서 natvie/Web 영
역을 정할 것임
○ Web 관련 부분 보안 강화 Solution 개발 및 적용
● 단일 App 내에서 Native/Web 경쟁
○ Web 엔진의 근본적인 구조 변화가 수반 되지 않는 이상 PC에서와 같이
Web기반으로의 급격한 변화는 없을 듯
○ WebGL이 보편화되어 기존 DOM기반 architecture를 bypass 가능시
60. 디바이스 다변화
● TV, Wearable, Camera, 자동차를 통한 신규
디바이스를 통한 SW Platform으로서 진입
○ 스마트폰으로의 진입은 Android/iOS 대항 가능한 수준의 ecosystem의
부재와 ecosystem 구축 비용을 투자할 만한 회사가 없는 상태
○ 서로 다른 디바이스간 cross-platform 적용은 쉽지 않을 것
○ Firefox는 저가폰/개발 도상국 위주로 진입/확산
○ 전문 HTML5/JavaScript 개발자 수요 증가
61. JavaScript 언어 영향력 증대
● JavaScript 언어의 시장 영향력 점진적 확대
○ HTML5 서비스별 적용 확대
○ node.js 도입을 통한 서버 영역 진출 확대
○ node-webkit을 통한 desktop App 진출 가속
○ Asm.js등 상용수준 발전에 따른 Browser 기반 게임 확대
PC App/
Node-webkit Mobile Web
JavaScript
Hybrid App 서버 Web
App/ Node.js
62. 개발/기획자라면 관심 갖어야 할 기술
(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에게는 위협 요
인
63. 개발/기획자라면 관심 갖어야 할 기술
(2)
● Web components
○ 개발 효율화/생산성 혁신 시작
○ IE 호환성 문제로 장벽이 존재 하지만 사내 서비스나 Mobile 단말부터
도입 예상
● Installable Web App
○ Android Chrome 38 버전부터 지원
○ URL 입력 불편함 혁신
○ App store를 통한 App의 설치라는 사용자 인식의 전환도 동반이 되어
야 함
● Web of thing
○ Google의 “The Physical Web” project → 장기 과제이지만 관심을 둘만
64. 제언
HTML5 상용화 적용에는 난관이 많지만,
Browser-엔진의 이해를 바탕으로 상품화시,
기술 차별적인 서비스 개발이 가능하므로,
상업적인 활용 가치가 이미 충분하다
