W3C home > Mailing lists > Public > public-html-ig-ko@w3.org > September 2012

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

From: Wonsuk Lee <wonsuk73@gmail.com>
Date: Wed, 19 Sep 2012 21:48:55 +0900
Message-ID: <CAKmBCi1i=d7Cv3u13WKOxTRXde5GPDOjctW2rUR5pJwT9+F0UA@mail.gmail.com>
To: Sangwhan Moon <sangwhan.moon@hanmail.net>
Cc: HTML KIG <public-html-ig-ko@w3.org>
상환님.
좋은 정보 감사합니다~^^

이원석 드림.

2012/9/16 Sangwhan Moon <sangwhan.moon@hanmail.net>:
> 이번에 모바일 페이스북 어플리케이션을 네이티브로 전향하게 된 계기 및 한계점에
> 대해서 페이스북 입장에서 정리해놓은 메일입니다.
>
> 어플리케이션 개발하시는 분들께 참고가 되셨으면 하는 바램에서 전달합니다.
>
> 문상환 배상
>
> 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
>>
>>
>>
>
>



-- 

=========================================
이 원 석 (Wonsuk, Lee) / Principal Engineer, Ph.D
SAMSUNG ELECTRONICS Co., LTD. (三星電子)
Mobile: +82-10-5800-3997
E-mail: wonsuk11.lee@samsung.com, wonsuk73@gmail.com
http://www.wonsuk73.com/, twitter: @wonsuk73
-----------------------------------------
Inspire the World, Create the Future !!!
=========================================
Received on Wednesday, 19 September 2012 12:49:23 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 19 September 2012 12:49:24 GMT