오늘도 웃으세요

현재 HTML5  에서는 Webapp 개발시 성능 문제를 해결 하고자 로컬에 파일을 미리 저장해놓는  여러가지 기술을 사용 하고 있음 

그중 localStorage /applicationCache 와 같은 기능 들도 존재 한다. 이런 기능들은 Web App 을 Offline 에서도 잘 활용 하수 있게 지원 해주는 HTML5 의 Offline application 관련 기능들이다.  

(여기서 localStorage는 객체형태의 공간에 해당 DB를 저장해놓고 사용 하는 방법이며 

ApplicationCache 의 경우는 미리 지정해놓은 파일들은 처음 다운 받은 후에 재접속 후에 해당 파일을 네트워크에서 다시 전송 받지 않고 활용 하는 기법 . )

해당 기술은 Google의 경우 Gmail 에서 이미 많이 사용 중이며 application  형태로 제작된 web contents들은 모두 이런 기술을 사용 하고 있다. . 

2. 그렇다면 Facebook 은  그런 성능 문제를 개선 하기 위해  web  기술을 사용 하였는지??

daum의 윤석찬 팀장의 블로그에서  http://blog.creation.net/531  밝혔듯이  Facebook의 경우는 web app에 이런 기술을 사용 하고 있지 않는다고 나와있다.

해당 분석 소스는 hybrid app을 직접  살펴본것이 아니라 hybrid app의 모태가 되는 m.facebook.com 의 소스를 살펴 본것으로 확인 되며 해당 소스를 분석 해본결과 

위에 말한  application 형태로 제작될때 활용될 기술들이 하나도 사용 되어있지 않았다고 한다.( 정말??/)  즉 Facebook의 HTML5 는 HTML5 를 사용 하지 않았다고 표현 하고 있다. 

3. 그렇다면 왜 Native App 으로 변경을 하였는지? 

위 블로그에서 확인해보면 이유가 나와있지만 본인의 생각은 다르다. 현재 facebook의 공식 입장은 단 2가지 입니다. Speed 와 efficiency  라고 한다. 

현재 native app 으로 업데이트 하면서 속도는 확실히 좋아졌고 native  app이 가지고 있는 부드러운  UI/UX로 조금더 좋은 평가를 받고 있는데  facebook이  native app으로 전환하면서 얻었다고 하는 공식적인  Speed 의 장점 3가지가 다음과 같다.  

Speed의 장점

1. 랙이 없어짐

2. 스크롤링이 더 부드러워짐 

3. 사진이 즉시 업로드 된다. 

Speed가 Web service 특성상 얼마나 중요한지에 대한 자료는 얼마전 NHN 에서 열렸던  Deview 에서 잘 언급 되고있는데  해당 컨퍼런스에서 웹서비스 빠를수록 좋다 : NHN 김일환

섹션에서 발표된 내용을 살펴 보자면 웹 서비스가 1초 느려지면 매출이 3% 떨어진다는 MicroSoft의 통계도 있으며 웹서비스는 0.1초라도 빠를수록 좋다고 나와있다. 

(네이버 기준으로 로딩시간 2,3 초 를 기준으로 1인당 PV 가 낮아지기 시작 해 5초 이상 걸리면 PV가 절반 이하로 떨어진다고 하는데 얼마나 웹에서 속도가 중요한지 알 수 있다. )  

Efficiency 의 장점 

효율성에 있어서는  현재 iOS 에서 Native 개발시에 Xcode   라는  개발툴을 사용 합니다. 이 개발툴의 경우 개발도구가 상당히 잘되어있어 개발 할경우 HTML5 개발 보다 훨씬 용이하게 

개발을 할 수 있었다고 한다.  예를들어 Scrolling 을 smooth  하게 표현 하기 위해서는 HTML5 에서는 숙련된 개발자가 필요 하지만  iOS 에서 Native  로 개발 할 경우 이런 고민을 할 필요가 없다고 한다. 

그렇다면 HTML5 로도 위의 개발 과정을 충분히 가능 한데 왜 Native로 굳이  Rebuild하였는지 ? 

현재 HTML5 개발의 경우  safari 도 여러가지 개발자 도구를 지원 하고 있고 ( 원격 디버깅,)( UA Code 변경) 구글의  Chrome도 여러가지 개발도구를 지원 하고있다. 

또한 속도 문제 또한 HTML5 의 모든 스펙을 충분히 동원 하면 Native 대비 어느정도 성능은 얻을 수 있을것이라고 한다. 

그렇다면 과연 무슨 이유 일까? 나는 facebook과 apple 간에 모종의 거래가 있지 않을까 예상해본다. 

관련 징후는 다음과 같다. 

1. iOS6.0으로 업데이트 되면서 facebook이 default 가 되었음 
2. facebook이 작년 부터 활발히 진행하던  spartan project  가 아무런 언급이없음..(사라진 프로젝트..) 
3. 또한 spartan project 시에 활발히 개발 되었던 web app 들이 현재 Facebook appcenter 에서 검색이 불가능 
4. facebook에서 검색 한 app의 경우 모두 애플 의 Appstore로 이동 하였고 이전에는  꽤 완성도 있는 web app도 올라왔었는데 이  app 또한  native app으로 대체 

해당 주장을 좀더 뒷받침 해줄 기사가 있어 링크 한다. 

http://www.readwriteweb.com/mobile/2012/08/how-facebook-ditched-the-mobile-web-went-native-with-its-new-ios-app.php

아래는 facebook의 개발자가 밝힌 HTML5 개발 의 문제점 이다. facebook 의 메일링 리스트를 번역 하였다. 

1.  Tooling / Developer APIs 

모바일 브라우저에서  개발에 적합한 툴이 없다.  단말에서 issue 발생시  dig down 하는것이  매우 어렵다 . 

그중 가장 큰 문제는 memory  에 관련 된 것들이였음 ,  드물게  컨텐츠 사이즈가 하드웨어의 허용 범위를 초과하였을 경우 

오류가 발생할경우  해당 문제의 원인을 정확히 파악 하기 힘들었음 : GPU  버퍼가 초과 되었는지  

• 그렇다면 무엇이 없었는지 ? 
• 개발툴은 원격으로 쉽게 접근 가능해야 함 
• Down memory lane : 
• heap size
• object count 
• GC cycles 
• GPU buffer size 
• resource limits 
• 링크드인의 경우  개발 할때 UA String 을 바꾸는 방법으로 개발 하는방법을 사용중
• http://engineering.linkedin.com/linkedin-ipad-5-techniques-smooth-infinite-scrolling-html5
• FPS
• Testing 하는데  FPS를 측정 하는 것은 필수임
• 페이지 안에 스크롤링을 얼만큼 포함 할것인지 아니면 infinite scrolling 을 적용 할것인지 여부는 H/W 레벨에 따라 결정 되어야 함   

2. Scrolling Performance

• 스크롤링 성능은 가장 중요한 이슈중에 하나로 현재 W3C Web Performace WG 에서 공유 되고 있는 문제임 
  전형적으로 뉴스피드 / 타임라인 등에서는 Infinite Scrolling 을 사용 하고 있는데 많은 양의  컨텐츠가  로딩 될 수 밖에 없음 
  현실적으로 자바스크립트를 사용 해서 스크롤링의 모 든것을 해결 하였는데 충분히 빨라지지 않았음 
• QOI 이슈들 
• 일치하지 않는 프레임 레이트 들 / UI 쓰레드 부족 
• 이미지와 컨텐츠 크기로 인한 GPU 버퍼 소진 
• Native에서 사용 하는  스크롤링 ( 가속 스크롤링을 말하는듯 ) 은 각 OS에 최적화 되어있어 서로 다른 느낌을 준다. 하지만  스크롤링을 JS  로 개발하면 한개의 느낌만 줌 
• 안드로이드 기기에서 터치 이벤트  성능 문제 존재  ( 지연, 충분하지 못한 이벤트 ) ( JS  로는 너무 힘들다 ) 
• Requirements 
• 스크롤링은 반드시 빠르고 부드러워야 함
• 여러개의 이벤트들이  트리거 되어야 함 , 복잡하고 중첩된 유저 스크롤이  컨텐츠에 반영되어야 함 
• 무조건 백그라운드에서 계산 및 I/O 가 허용 되어야함 
• 스크롤링 동안에 메인 컨텐츠에 새로운 컨텐츠가 추가 되는것이 허용 되어야함 
• 많은 양의 컨텐츠 및 이미지가 있어도 안정적으로 스크롤링이 동작 해야 함 
• 스크롤링 동안에 Touch 이벤트를 캐취 할수 있어야 함
• New API Suggetstions 
• Browser 에서 스크롤링 할때 표준 방법 확립 
• onScroll 이벤트가 스크롤링 할때도  trigger 되어야함
• Structured cloning of rootless document fragments : (shadow dom이랑 비슷한 놈)
• Pull to refresh 를 구현하기 쉬운 방법  

3. GPU

• 현재 GPU  는 black box 인 상태 : 하드웨어 가속을 사용 하는데  디바이스가 소모하는 컨텐츠의 양 및, GPU 버퍼 사이즈  등 을 알수가 없음 

4. Other 

• 더 나은 터치 트래킹 지원, ( 특히 안드로이드에서 ) 
• 부드러운 Animation  이 항상 보장되어야 함 
• 더 좋은 caching 
• appCache는 사용하기 너무 어려움