[별천지 세미나] HTML5 is Ready: Fastbook 기술적 분석

12,704 views

Published on

Sencha의 Fastbook에 대한 분석
- 20130504 별천지세미나 발표자료

Published in: Technology
8 Comments
37 Likes
Statistics
Notes
No Downloads
Views
Total views
12,704
On SlideShare
0
From Embeds
0
Number of Embeds
9,146
Actions
Shares
0
Downloads
0
Comments
8
Likes
37
Embeds 0
No embeds

No notes for slide

[별천지 세미나] HTML5 is Ready: Fastbook 기술적 분석

  1. 1. HTML5 is Ready :FastbookSKP 김준기13년 5월 13일 월요일
  2. 2. Who am I ?• JavaScript 프로그래머• Mobile Web App 개발• Jindo Component• 웹서비스 성능 개선• 번역• facebook 그룹 jslounge 운영자http://www.facebook.com/groups/jslounge13년 5월 13일 월요일
  3. 3. Fastbook에 대한 이야기13년 5월 13일 월요일
  4. 4. 2012년 9월 11일@ TechCrunch DISRUPT SF 201213년 5월 13일 월요일
  5. 5. 당시의 Facebook App• HTML5? 그냥 단순한 모바일 웹페이지• http://m.facebook.com• 현재의 모습과 크게 다르지 않았다.• 네이티브 변경 이후로 점차적으로UI에 재미있는 요소들 도입• 제스처, Swipe Image Viewer13년 5월 13일 월요일
  6. 6. 13년 5월 13일 월요일
  7. 7. HTML5 Adoption Survey• 2012/09/05 ~ 2012/09/26• over 4,000 worldwide software developer13년 5월 13일 월요일
  8. 8. 90% 이상이 HTML5를 사용하거나 할 계획HTML5를 사용하고 있거나사용할 계획인가요?13년 5월 13일 월요일
  9. 9. Facebook의 결정이당신에게 어떤 영향인가요?70% 이상 : 별상관없다.10% 이상 : 오히려 자신감을 얻었다.13년 5월 13일 월요일
  10. 10. 네이티브로 바뀌기 전에HTML5였다는 걸 알고 있었나요?무려 절반 이상이 몰랐다!13년 5월 13일 월요일
  11. 11. 페이스북이 네이티브로 변경한 사실을 알고 있다면,앞으로의 HTML5 개발에 어떤 영향을 주는가?사실을 알았다 - 좌절(17%) 혹은 희망(18%)몰랐다 - 별생각 없다 (좌절도 덜, 희망도 덜)13년 5월 13일 월요일
  12. 12. 그리고 12월Fastbook의 등장13년 5월 13일 월요일
  13. 13. http://fb.html5isready.com13년 5월 13일 월요일
  14. 14. http://vimeo.com/5548668413년 5월 13일 월요일
  15. 15. fastbook의 특징• 엄청 빠른 스크롤 속도• Swipe뷰, 더블탭 줌, 핀치 투 줌/패닝• 앱 네비게이션 스와이핑/탭핑• pull to refresh시 모두 리프레시하지 않고 필요한 내용만 업데이트• 댓글도 스크롤시 자동으로 더보기• 가로모드지원• iOS 5 or Android 4.1이상 권장13년 5월 13일 월요일
  16. 16. position:fixed• 그동안 웹을 앱처럼 사용하지 못했던 가장 큰 이유• Android ICS(4.0)+, iOS 5+• 헤더, 푸터 고정• 컨텐츠영역만 스크롤하려는 UI 구현 시도13년 5월 13일 월요일
  17. 17. 커스텀 스크롤러• position:fixed처럼 일부를 고정하고 지정된 영역만touch이벤트로 스크롤할 수 있도록 지원• iScroll과 같은 라이브러리를 사용• 또는 직접구현• 기존의 facebook 앱은???• 컨텐츠영역만 webview사용• webview의 디폴트 스크롤 사용13년 5월 13일 월요일
  18. 18. 계속해서 증가하는 목록의스크롤 구현하기?• 고정된 목록의 구현은 대부분 해결 가능• 계속해서 증가하는 목록의 스크롤을 구현하기는무척 까다로움13년 5월 13일 월요일
  19. 19. fastbook은 어떻게 했을까?13년 5월 13일 월요일
  20. 20. DOM 트리의크기증가를 최소화• 앱이 커지면 DOM tree가 증가.• DOM tree가 증가하면레이아웃계산에 걸리는 시간이 늘어난다.즉 성능이 떨어진다.• 보여질 레이어의 수가 증가할수록컴포지팅 성능이 급격히 떨어진다.13년 5월 13일 월요일
  21. 21. Sandbox 컨테이너• DOM 트리를 iframe으로 나눈다.• 개발자에게는 seamless• 이벤트, 위치지정, 스타일링, 자바스크립트 코드등은부모 창과 자식창(샌드박스)간에 위임13년 5월 13일 월요일
  22. 22. News Feed TimelineStoryView13년 5월 13일 월요일
  23. 23. News Feed TimelineStoryViewsandbox sandbox sandbox13년 5월 13일 월요일
  24. 24. 일반적인 스크롤러의 구현• Viewport를 고정 크기로 지정• Viewport의 overflow:hidden• 터치 이벤트로, 적절한 스크롤위치를 계산• 리스트 컨테이너의top:스크롤위치px 지정 (position:absolute)• 또는 transform:translate3d(0, 스크롤위치px, 0)13년 5월 13일 월요일
  25. 25. 13년 5월 13일 월요일
  26. 26. ViewportList Container13년 5월 13일 월요일
  27. 27. transform:translate3d(0, 0px, 0)13년 5월 13일 월요일
  28. 28. transform:translate3d(0, 0px, 0)13년 5월 13일 월요일
  29. 29. transform:translate3d(0, -120px, 0)13년 5월 13일 월요일
  30. 30. transform:translate3d(0, -250px, 0)13년 5월 13일 월요일
  31. 31. 리스트 아이템이계속 늘어나면• layout해야할 DOM tree의 크기가 증가• GPU acceleration할 texture의 크기가 증가• layout에 걸리는 시간도 점점 증가13년 5월 13일 월요일
  32. 32. 스크롤러의 성능문제• KTH - 하이브리드 앱의 스크롤 성능 개선하기http://dev.kthcorp.com/2012/06/18/hybrid-app-scroll-performance-enhancement/• 각 아이템의 position을 absolute로 변경• viewport에 보이지 않으면 display:none으로layout, paint하지 않도록 함13년 5월 13일 월요일
  33. 33. 아이템이 계속해서 증가하는스크롤러의 성능문제• DOM이 계속해서 증가• 처리해야할 노드수가 계속해서 증가• 아이템이 계속 증가한다면DOM Tree가 커지는 근본적인 문제에는 해답이 없음13년 5월 13일 월요일
  34. 34. fastbook 스크롤러 DOM구조• 16개의 아이템만 유지• 각 아이템의 위치는 모두 position:absolute• 스크롤되면 이 아이템들의 위치가 바뀜• 모든 아이템들이 id값을 유지13년 5월 13일 월요일
  35. 35. 13년 5월 13일 월요일
  36. 36. 13년 5월 13일 월요일
  37. 37. 13년 5월 13일 월요일
  38. 38. 13년 5월 13일 월요일
  39. 39. 13년 5월 13일 월요일
  40. 40. 13년 5월 13일 월요일
  41. 41. 위... 윗장 빼기?13년 5월 13일 월요일
  42. 42. 추측• 16개 정도의 아이템만 유지하는 이유• DOM 구조 변경을 최소화하기 위해서• 아이템의 뼈대만 유지• 스크롤 위치에 근거해, 아이템 내부의 내용을 교체• 이 후 사이즈를 재고 적당한 위치에 배치13년 5월 13일 월요일
  43. 43. 60 fps• 프레임당 16.6666...ms 안에페인팅이 반복되어야함.• 프레임 사이에 시도하는 작업이 16ms 미만이면스크롤 성능에 영향을 최소화할 수 있다.13년 5월 13일 월요일
  44. 44. 13년 5월 13일 월요일
  45. 45. 예상 가능한 reflow 요인• 아이템 내부의 내용 교체• 아이템의 사이즈 측정• 아이템의 위치 변경13년 5월 13일 월요일
  46. 46. 아이템 내부의 내용 교체• 아이템 내용의 템플릿을 가지고매번 DOM을 생성하여 교체할 것이라고 추측13년 5월 13일 월요일
  47. 47. 13년 5월 13일 월요일
  48. 48. 변경을 예상한 부분13년 5월 13일 월요일
  49. 49. 실제 아이템 내용 교체• fastbook은 리스트의 모든 아이템이동일한 템플릿으로 표현가능하다는 점에 착안• DOM을 절대 새로 생성하거나 제거하지 않음• 아이템의 내용 중text, 이미지 url, display 여부만 변경13년 5월 13일 월요일
  50. 50. 13년 5월 13일 월요일
  51. 51. DOM tree의 크기에는 전혀 변화가 없다!13년 5월 13일 월요일
  52. 52. text 교체 성능• innerHTML• vs innerText• vs nodeValue• vs textContent13년 5월 13일 월요일
  53. 53. text 교체 성능• innerHTML• vs innerText• vs nodeValue• vs textContenthttp://jsperf.com/innerhtml-vs-innertext/12nodeValue Wins!tested on Galaxy s3 Android 4.0.4 & iOS 6.1.213년 5월 13일 월요일
  54. 54. 아이템의 사이즈 측정• getBoundingClientRect• vs offsetWidth / offsetHeight13년 5월 13일 월요일
  55. 55. 아이템의 사이즈 측정• getBoundingClientRect• vs offsetWidth / offsetHeighthttp://jsperf.com/getboundingclientrect-offsetwidth-offsetheightoffsetHeight Wins!13년 5월 13일 월요일
  56. 56. 아이템의 위치 변경• 항상 GPU 가속을 이용하는게 최선• css3 transform : translate3d(x, y, z)13년 5월 13일 월요일
  57. 57. 3초뒤 이해되는 사진13년 5월 13일 월요일
  58. 58. 13년 5월 13일 월요일
  59. 59. ???13년 5월 13일 월요일
  60. 60. ???개별 아이템의 높이가 유동적이기 때문에그려보기 전까지 전체 컨테이너의 높이를 알 수 없다.13년 5월 13일 월요일
  61. 61. TaskQueue• DOM read와 write가 이벤트 큐를 오랜시간동안블로킹 하지 않고 실행하도록 작업을 분리• timer로 쪼개서 별도의 이벤트 루프 턴에서 실행• READ 큐와 WRITE 큐로 분리• Ext.TaskQueue.requestWrite()• Ext.TaskQueue.requestRead()13년 5월 13일 월요일
  62. 62. requestRead() : read queue만 비움requestWrite() : write를 비우고 read queue를 이어서 비움READ TASK #1 WRITE TASK #1READ TASK #2READ TASK #3READ TASK #4WRITE TASK #2WRITE TASK #3WRITE TASK #4setTimeout(this.run, 1);requestAnimationFrame(this.run);READ 큐 WRITE 큐13년 5월 13일 월요일
  63. 63. AnimationQueue• 앱이 애니메이션을 실행중일 때,우선순위가 낮은 함수를 나중에 실행시키게 함.• 앱이 idle상태일 때 지연된 task들을 실행• 뉴스 피드를 스크롤하는 중에는 이미지 로딩/렌더링을 하지 않음.• 애니메이션 실행중에도 함께 실행되어야하는 작업들도 짧은 타이머 단위로 점진적으로 실행시키는 논블로킹 방식으로 수행• 터치 이벤트가 항상 최우선권스크롤이 잘 애니메이션 되도록 함.13년 5월 13일 월요일
  64. 64. TextExt.AnimationQueue.onIdle("doSetSrc", this, e);13년 5월 13일 월요일
  65. 65. 스크롤 애니메이션중이 아닐 때(idle) 이미지 로딩13년 5월 13일 월요일
  66. 66. 관성 스크롤시감속 지속시간 튜닝• 네이티브 앱에서는 3초 간 지속,• 가속은 높이고 감속되는 시간을 1.4초로 줄임.• 컨텐츠 노출속도를 높일 뿐 아니라,idle time을 늘리는 효과가 있으므로,현재 컨텐츠를 읽을 동안 더 많은 백그라운드 작업이가능해짐.13년 5월 13일 월요일
  67. 67. Web Worker• XHR/RPC 통신을 UI 쓰레드에서 분리해Worker 쓰레드에서 처리13년 5월 13일 월요일
  68. 68. 13년 5월 13일 월요일
  69. 69. News Feed데이터 최적화• proxy를 통해 API 호출을 최적화• HTML -> JSON• 기존 10개의 아이템당 15~20KB(gzip)• 10%의 크기로 줄임13년 5월 13일 월요일
  70. 70. Wrap-up• Sandbox• DOM 트리의 크기 변화가 전혀 없는 아이템 업데이트• TaskQueue / AnimationQueue• Web Worker• 관성 스크롤 감속시간 튜닝• 데이터 최적화 (JSON)13년 5월 13일 월요일
  71. 71. References• http://techcrunch.com/2012/09/11/mark-zuckerberg-our-biggest-mistake-with-mobile-was-betting-too-much-on-html5/• http://www.sencha.com/blog/the-making-of-fastbook-an-html5-love-story• http://www.html5rocks.com/en/tutorials/speed/scrolling/• http://cubiq.org/iscroll-413년 5월 13일 월요일
  72. 72. Q & A13년 5월 13일 월요일
  73. 73. 고맙습니다 :)13년 5월 13일 월요일

×