왜 iOS용 Facebook앱은 성능이 떨어지는가?(UIWebViews, no Nitro)

 이번 주엔 Facebook의 IPO가 있습니다. Facebook 로드쇼에서는 Facebook의 모바일 전략에 관한 이야기가 많이 나왔습니다. 9억 이상의 액티브 유저 중에서 5억명은 Facebook을 모바일로 사용하고 있습니다. 모바일은 주목받고 있으며, 향후 몇년 간은 이러한 추세가 유지될 것이고, 더 많은 주목을 받게 될 것 입니다. 

 iPad가 나오기 이전 2008~9년의 iPhone으로 나온 Facebook의 첫버전은 iPhone 앱을 어떻게 빌드해야 하는 지 보여주는 좋은 예가 되었었습니다. 앱은 Joe Hewitt, 한 명에 의해 개발되었습니다. 그리고 앱의 일부는 Three20 project 같은 오픈 소스였습니다. 그가 Facebook을 떠나면서 iOS 앱 작업이 중단되자, 새로운 팀은 코드를 완전히 다시 작성하여 iPad를 동시에 지원할 수 있는 유니버셜 앱으로 이를 대체했습니다(2011년 11월). 유저수는 증가하고 있지만, 실제로 유저들은 현재의 iOS 앱을 좋아하지 않습니다. 미국 iTunes 스토어에서 21,803명은 평점을 별 2개로 매겼습니다. 11,838명은 평점을 별 1개로 매겼습니다. 별 1개는 절망적이라는 뜻입니다. 코멘트들에서도 절망적임이 느껴집니다. 별 2개를 받은 대부분의 앱들은 사라졌지만, 우리는 모두 FB 유저이기 때문에, iPhone 또는 iPad를 가지고 있다면 iOS 앱을 사용할 수 밖에 없습니다. 

 

iOS앱은 무엇이 문제인가

 

 1. 앱이 느리다. 

 2. 일관성 없는 정보 알림 아이콘은 새로운 메시지나 반응이 있다고 말하지만, 실제 창에는 새로운 것이 보이지 않는다.

3. 앱이 모바일 웹 사이트보다 느림 모두가 앱이 빠르다고 생각하지만, Facebook 모바일 웹 사이트는 iOS 앱보다 빠르다. 그러면서 거의 같은 기능을 제공한다.

4. 엄청나게 많은 버그 깨진 화면, 사진 업로드, 텍스트 박스 숨김, 쉐어링이 안됨 

이런 이슈들의 원인은 무엇인가

 1. Nitro Javascript 엔진이 없는 HTML과 UIWebViews

  저는 네트워크를 스니핑(sniff)하는 것을 좋아합니다. 이를 통해 알아낸 사실은 facebok.com에서 iOS앱이 다운로드 받는 데이터는 REST의 혼합물이라는 것을 알 수 있었습니다.(JSON이 아닌 XML 형식) HTML은 당신의 타임라인과 포로필, 그룹 타임라인에 쓰입니다. 직접 확인해보십시오. http://m.facebook.com/home.php 로 이동하면 이것이 iOS앱의 첫번째 화면이라는 것을 알 수 있습니다. 스크린 샷을 보면 html과 images/stylesheets/JavaScript 를 다운로드 받는 과정에서 뭔가 잘못됐다는 걸 알 수 있을 것입니다. 앱에서 HTML을 보여주기 위해서, 개발자는 UIWebView라 불리는 Safari 콤포넌트를 사용합니다. 이는 매우 편리하지만 위험하기도 합니다. 다운되는 HTML의 크기는 꽤 크며(15kb), 이미지, 스타일시트, 자바스크립트 링크를 포함하고 있습니다. 시작하게 되면 변화하지 않는 부분에 대한 캐싱을 개발자가 통제할 수가 없습니다. FB 앱은 전체 타임라인의 HTML을 매번 다운로드하며, 이것은 UIWebView가 이미지와 스타일시트를 다운로드할 지 결정할 때 까지 계속됩니다. 두번째로 UIWebVIew의 성능은 모바일 Safari보다 떨어집니다. 이것은 UIWebView의 Nitro Javascript 엔진으로 할 일이 많다는 것을 뜻합니다. 보안상의 이유 때문에도 그렇습니다. 제 iOS 5.1.1 버전의 iPhone4로 테스트를 해봤을 때, JavaScript benchmark Sunspider는 모바일 Safari가 UIWebView를 사용한 네이티브 앱의 경우보다 3배나 빠른 결과를 보여줬습니다. 또한 UIWebView에서 네이티브 앱 간에 정보를 주고 받을 때에도 JavaScript 브릿지가 필요합니다. 이것은 일종의 트릭이며, 느리고 실제로는 스레드도 안전하지 못합니다. 

2. 동기화되지 않은 정보들의 서로다른 요청 

 알림, 메시지, 친구요청을 위해 REST 요청이 실행되면, XML 데이터가 넘어옵니다. 새로운 알림의 숫자가 몇 갠지 알기 위하여 (https://api.facebook.com/restserver.php) 첫번째 체크 작업이 일어납니다. 그 다음으로 실제 콘텐트는 분할된 요청 (https://api-read.facebook.com/restserver.php) 으로 반환됩니다. Facebook 서비스 요청이 매번 바뀌는 정보를 반환한다는 것 정도는 알 수 있게됩니다. 당신이 빠르게 당신 앞으로 온 새로운 알림을 확인하려고 한다면, 당신은 새로운 정보를 볼 수가 없습니다. 

왜 Facebook은 네이티브 iOS앱에 HTML 기술을 사용했는가?

1. HTML은 유동적인 콘텐트를 보여주기 쉽다. Objective-C는 유동적인 화면을 보여줄 때는 정말 구립니다. 텍스트가 있는 이미지, 다양한 텍스트 라벨이 붙은 버튼을 직접 만드는 것은 Objective-C에서는  모든 엘리먼트의 크기와 위치를 직접 계산해야하기 떄문에 매우 힘듭니다. 특히 타임라인은 HTML로 만드는 것이 훯씬 쉽습니다.

2. 다른 플랫폼 사이에서 공유할 수 있는 코드를 만들기 때문에 iOS, Android, BlackBerry, Windows 폰은 모두 다른 기술이며, 이것은 개발자들에겐 악몽과도 같습니다. 콘텐츠와 기능을 HTML 형태로 공유하는 것도 이해가 갑니다. 

3. HTML은  Facebook 반복되는 배포 과정에 더 많이 포함됩니다. FB 개발자들은 스스로 QA를 할 책임이 있습니다. 그 중 하나는 코드를 제한된 서버들에 넣은 다음, 결과를 지켜본 후 더 많은 코드를 집어넣는 것으로 매일 행해집니다. Apple이 적어도 한주에 한 번 리뷰를 하면서, 바뀐 코드를 롤백하는 것은 악몽과도 같습니다. 

4. 우리는 페이스북을 빠져나올 수 없습니다. 그렇습니다. Facebook은 은행이 아닙니다. 다른 iOS Facebook 앱은 없으며, 우리는 9억 유저를 가지고 있는 소셜네트워크의 가상의 독점으로 인해 이 서비스를 계속 사용할 것 입니다. 불만이 잇더라도 사용할 수 밖에 없습니다.

5. 피쳐폰이 성장하는 곳으로 인해. 이미 높은 비율로 iPhone과 Android 사용자들은 페이스북 앱을 사용하고 있습니다. 다음 개척지는 피쳐폰이며, 특히 비서구권을 대상으로 합니다. 새로운 유저가 최초로 Facebook을 사용하는 모바일 기기는 멋진 iPhone이 아닐 것입니다. 

나는 Facebook 앱이 Path처럼 멋지게 나오기를 바랍니다. 그렇지만 그 날이 금방 오지는 않을 것 같습니다. 당신은 어떻게 생각하십니까?

(원문 : http://blog.mobtest.com/2012/05/heres-why-the-facebook-ios-app-is-so-bad-uiwebviews-and-no-nitro/ )