Re: 웹 베이스 어플리케이션 퍼포먼스 관련 (원제목: Perf Feedback - What's slowing down Mobile Facebook)

안녕하세요. 전용입니다.

좋은 글 감사합니다.
역시 모바일웹하면서 겪는 문제는 비슷하구나라는 생각이 들면서 한편으론 안심이 되네요. ㅎㅎ

진짜 현재 모바일웹 개발은 수년전 IE5.5, IE6에서 개발하는 느낌입니다.-_-;;

그나마 예전에는 IE만 그랬는데 지금은 안드로이드 os버전별 기기별 차이가 있으니 이 모든 상황에서 최적화하기란 거의 불가능에
가깝네요. 거기다 사용자는 이미 보는 눈은 높아져서...

여튼 디버깅 도구나 브라우저들이 발전하고 있으니 이 또한 지나가리라고 생각하고 있습니다. ㅎㅎ



On Sunday, September 16, 2012, Sangwhan Moon wrote:

> 이번에 모바일 페이스북 어플리케이션을 네이티브로 전향하게 된 계기 및 한계점에
> 대해서 페이스북 입장에서 정리해놓은 메일입니다.
>
> 어플리케이션 개발하시는 분들께 참고가 되셨으면 하는 바램에서 전달합니다.
>
> 문상환 배상
>
> Begin forwarded message:
>
> > Hi,
> >
> > Following the recent announcements[1] we (Facebook) made about rebuilding
> > our iOS app using more native technology, we have had a lot of requests
> to
> > provide detailed feedback on the performance issues we encountered while
> > building for the mobile Web. Here it is. Comments welcomed.
> >
> > 1. Tooling / Developer APIs
> > ---------------------------
> >
> > The lack of tooling in mobile browsers makes it very difficult to dig
> down
> > and find out what the real issues are. Hence tooling, or rather,
> > lack-thereof is a key issue.
> >
> > The biggest issues we've been facing here are memory related. Given the
> > size of our content, it's not uncommon for our application to exhaust the
> > hardware capabilities of the device, causing crashes. Unfortunately, it's
> > difficult for us to understand exactly what's causing these issues. GPU
> > buffer exhaustion? Reaching resource limits? Something else? hard to say.
> >
> > ### What's missing? ###
> >
> > Mainly, dev tools on the device and/or easily accessible remotely.
> >
> > Things we'd want to know more about as we develop:
> >
> > #### Down memory lane ####
> >
> > - Heap size,
> > - Object count,
> > - GC cycles,
> > - GPU buffer size,
> > - resource limits.
> >
> > Some of those are very much useful outside of the development phase,
> > however. E.g.: Linkedin uses UA string sniffing[2] to determine how many
> > pictures can be kept in memory before hitting the device's limit, an API
> > to the device's memory resource would be a much more appropriate (albeit
> > finger-printable) way of doing that.
> >
> > #### FPS ####
> >
> > - The ability to measure fps at the hardware level. This is essential for
> > testing[3], but would also be very useful to determine whether to use
> > infinite scrolling or pagination, for example. Same fingerprinting caveat
> > as above.
> >
> >
> > 2. Scrolling performance
> > ------------------------
> > I've already started sharing some of it with the W3C WebPerf WG[4]. Will
> > continue bringing it to other relevant WG in the upcoming weeks.
> >
> > This is one of our most important issues. It's typically a problem on the
> > newsfeed and on Timeline which use infinite scrolling (content is
> > prefetched as the user scrolls down the app and appended) and end up
> > containing large amounts of content (both text AND images). Currently, we
> > do all of the scrolling using JS, as other options were not fast enough
> > (because of implementation issues).
> >
> > ### QoI Issues
> >
> > - Inconsistent framerates, UI thread lag (stuttering).
> > - GPU buffer exhaustion due to size of content and number of images.
> > - Native momentum scrolling has a different feel across operating
> systems.
> > JS implementation end up being tailored for one OS and feels wrong on
> > other ones (uncanny valley).
> > - Perf issue with touch events on Android devices (latency, not enough
> > events) which makes JS implementations of scrolling more brittle there.
> >
> > ### Requirements:
> >
> > - Scrolling must be fast and smooth (this is really important for
> > engagement).
> > - It must trigger a given set of events so content can be prefetched,
> > computed and appended as the user scrolls towards the bottom of the
> loaded
> > content.
> > - It must allow i/o and computation in the background (without affecting
> > the smoothness).
> > - It must allow appending fresh content to the main content while
> > scrolling (again, without affecting the smoothness).
> > - It must reliably handle scrolling though a lot of content, including
> > lots of images.
> > - It must be possible to capture touch events during scrolling.
> >
> > ### new API suggestions:
> >
> > - A standardized way to enable momentum scrolling across browsers.
> > - `onscroll` events triggered *during* scrolling.
> > - Structured cloning of rootless document fragments (for building doc
> > fragments in workers and moving them back to the main thread to be
> > appended).
> > - Simple way to implement pull to refresh (via dedicated off-bound-scroll
> > events?).
> >
> >
> > 3. GPU
> > ------
> >
> > Currently, the GPU is a black-box (which from what I understand is what
> > vendors would like to keep it as). In truth however, developers rely on
> > tricks[5] to force given content to be hardware accelerated. So it
> > basically a black-box with a clunky API to add things to it. Given the
> > size of GPU buffers relative to the size of content consumed on devices
> > nowadays, I doubt well get to a place where managing GPU can be left
> > strictly to the browser in a reasonable amount of time.
> >
> > Think there's value in at least discussing the pros and cons of providing
> > some form of API to the GPU, if that's possible at all.
> >
> >
> > 4. Other
> > --------
> >
> > - Better touch tracking support, especially on Android.
> > - Smoother animations are always an asset.
> > - Better caching.
> > - AppCache is soooooo busted we stopped using it[6].
> >
> > Best,
> >
> > --tobie
> >
> > ---
> > [1]:
> >
> https://www.facebook.com/notes/facebook-engineering/under-the-hood-rebuildi
> > ng-facebook-for-ios/10151036091753920
> > [2]:
> >
> http://engineering.linkedin.com/linkedin-ipad-5-techniques-smooth-infinite-
> > scrolling-html5
> > [3]:
> http://lists.w3.org/Archives/Public/public-coremob/2012Aug/0014.html
> > [4]: http://www.w3.org/2012/09/12-webperf-minutes.html
> > [5]: http://davidwalsh.name/translate3d
> > [6]: https://etherpad.mozilla.org/appcache-london
> >
> >
> >
>
>
>