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

이번에 모바일 페이스북 어플리케이션을 네이티브로 전향하게 된 계기 및 한계점에
대해서 페이스북 입장에서 정리해놓은 메일입니다. 

어플리케이션 개발하시는 분들께 참고가 되셨으면 하는 바램에서 전달합니다.

문상환 배상

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
> 
> 
>

Received on Sunday, 16 September 2012 01:11:23 UTC