- From: Wonsuk Lee <wonsuk73@gmail.com>
- Date: Wed, 19 Sep 2012 21:48:55 +0900
- 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 UTC