Jadi ngerti dan jelas sekarang.... mudah2an kelemahan ini bisa ilang di Android 5.0... seperti yang ada pada artikel ini... aamiin....
On Wed, Dec 7, 2011 at 11:49 AM, Reski Droid <funky81.andr...@gmail.com>wrote: > Jawaban Andrew Munn ke blog Dianna Hackborn ( > https://plus.google.com/100838276097451809262/posts/VDkV9XaJRGS) > > Andrew Munn <https://plus.google.com/100838276097451809262> - 3:41 AM > (edited) <https://plus.google.com/100838276097451809262/posts/VDkV9XaJRGS> > - Public > *Follow up to “Android graphics true facts”, or The Reason Android is > Laggy* > > Yesterday +Dianne Hackborn <https://plus.google.com/105051985738280261832> > posted > to Google+ an article that dismissed the common accusation that Android is > laggy because UI rendering wasn’t hardware accelerated until Honeycomb: > > https://plus.google.com/105051985738280261832/posts/2FXDCz8x93s > > It’s an insightful post that illuminates many of the complex issues with > smooth Android rendering. Unfortunately, it doesn’t answer the fundamental > question asked by both technical and nontechnical android users: > > *Why is Android laggy, while iOS, Windows Phone 7, QNX, and WebOS are > fluid?* > > This post will attempt to answer that question. > > However before I jump in, a couple disclaimers. First, I am a 3rd year > undergraduate software engineering student. I interned on the Android team, > and +Romain Guy <https://plus.google.com/111962077049890418486> who was > responsible for much of the hardware acceleration work in Honeycomb, > reviewed some of my code, but I was not on the framework team and I never > read the Android rendering source code. I do not have any authoritative > Android knowledge and I cannot guarantee what I say here is necessarily > 100% accurate, but I have done my best to do my homework. > > Second, I’m interning with the Windows Phone team starting in January, so > it’s possible that this post will be unconsciously biased against Android, > but if you ask any of my friends, it’s really hard to shut me up about > Android. I have more Android t-shirts than days of the week and I’d rather > give away my Macbook than my Nexus S. The Googlplex is like a second home - > I’ve slept there on more than a few occasions to the dismay of startled > janitors (and if you ever get a chance to visit, the banana french toast at > *Big Table Cafe* is to die for). If anything, I’m probably biased in > Android’s favor. > > Finally, any opinions expressed in this article are solely my own and do > not represent those of any past or future employers. > > With that out of the way, lets dive right in. > > Dianne starts off her post with a surprising revelation: > > *“Looking at drawing inside of a window, you don’t necessarily need to do > this in hardware to achieve full 60fps rendering. This depends very much on > the number of pixels in your display and the speed of your CPU. For > example, Nexus S has no trouble doing 60fps rendering of all the normal > stuff you see in the Android UI like scrolling lists on its 800x480 screen.” > * > > Hun? How can this be the case? Anybody who’s used a Nexus S knows it slows > down in all but the simplest of ListViews. And forget any semblance of > decent performance if a background task is occurring, like installing an > app or updating the UI from disk. On the other hand, iOS is 100% smooth > even when installing apps. But we know Dianne isn’t lying about the > potential CPU performance, so what’s going on? > > *The Root Cause* > > It’s not GC pauses. It’s not because Android runs bytecode and iOS runs > native code. It’s because *on iOS all UI rendering occurs in a dedicated > UI thread with real-time priority*. On the other hand, Android follows > the traditional PC model of rendering occurring on the main thread with > normal priority. > > This is a not an abstract or academic difference. You can see it for > yourself. Grab your closest iPad or iPhone and open Safari. Start loading a > complex web page like Facebook. Half way through loading, put your finger > on the screen and move it around. All rendering instantly stops. The > website will literally never load until you remove your finger. This is > because the UI thread is intercepting all events and rendering the UI at > real-time priority. > > If you repeat this exercise on Android, you’ll notice that the browser > will attempt to both animate the page and render the HTML, and do an ‘ok’ > job at both. On Android, this a case where an efficient dual core processor > really helps, which is why the Galaxy S II is famous for its smoothness. > > On iOS when an app is installing from the app store and you put your > finger on the screen, the installation instantly pauses until all rendering > is finished. Android tries to do both at the same priority, so the frame > rate suffers. Once you notice this happening, you’ll see it everywhere on > an Android phone. Why is scrolling in the Movies app slow? Because movie > cover thumbnails are dynamically added to the movie list as you scroll > down, while on iOS they are lazily added after all scrolling stops. > > *EDIT*:[Several people (+Chi-Ho > Kwok<https://plus.google.com/100952146715427669835> > and +Brent Royal-Gordon <https://plus.google.com/105929214842555343739> > especially) > have taken the time to explain some mistakes I made in my description of > iOS. The fundamental distinction between Android and iOS rendering I > identified still stands, but I made some over simpliifcations in my > description of iOS because I wasn't familar enough with the workings. I'll > let +Brent Royal-Gordon <https://plus.google.com/105929214842555343739> > explain: > > "The iOS description here isn't quite accurate. There are several things > at work: > > 1. Compositing and previously set-up animations—all the stuff that > involves the Core Animation rendering layer tree—do indeed happen on a > background thread. > > 2. Drawing new content into Core Animation layers and setting up their > animations happens on the main thread. This is the same thread that user > interface actions occur on. > > 3. In naively written code, all developer-written code would occur on the > main thread. However, Apple provides very easy APIs (Grand Central Dispatch > and NSOperation) to move things into system-managed background threads. In > iOS 5, you can even declare that a Core Data (object-relational database) > context cannot be used directly on the main thread. > > All that stuff you noticed—the way images aren't drawn into lists while > you're scrolling, the way WebKit rendering stops when the system is > tracking a touch—isn't inherently built-in by a mechanism that pauses the > world when a finger is on the screen.* It's deliberate behavior > painstakingly implemented by the developer of each individual app. > > This is not a technical difference; it's a cultural difference. Good iOS > developers don't ship software until it runs at something near 60 fps while > scrolling and tracks touches almost perfectly; good Android developers do. > > * This isn't strictly true: the main thread is put into a special mode > during touch tracking, and by default, certain callbacks are delayed in > that mode. However, a lot of other things, like loads from disk or network > activity kept completely on a background thread, are not paused; nor is > anything automatically paused during momentum scrolling. The developer has > to explicitly delay those things." ] > > *Other Reasons* > > The fundamental reason Android is laggy is UI rendering threading and > priority, but it’s not the only reason. First, hardware acceleration, > despite Dianna’s reservations, does help. My Nexus S has never been > snappier since upgrading to ICS. Hardware acceleration makes a huge > difference in apps like the home screen and Android market. Offloading > rendering to the GPU also increases battery life, because GPUs are > fixed-function hardware, so they operate at a lower power envelope. > > Second, contrary to what I claimed earlier, garbage collection is still a > problem, even with the work on concurrent GC in Dalvik. For example, if > you’ve ever used the photo gallery app in Honeycomb or ICS you may wonder > why the frame rate is low. It turns out the frame rate is capped at 30 FPS > because without the cap, swiping through photos proceeds at 60 FPS most of > the time, but occasionally a GC pause causes a noticeable “hiccup”. Capping > the frame rate at 30 fixes the hiccup problem at the expense of buttery > smooth animations at all times. > > Third, there are the hardware problems that Dianne discussed. The Tegra 2, > despite Nvidia’s grandiose marketing claims, is hurt by low memory > bandwidth and no NEON instruction set support (NEON instructions are the > ARM equivalent of Intel’s SSE, which allow for faster matrix math on CPUs). > Honeycomb tablets would be better off with a different GPU, even if it was > theoretically less powerful in some respects than the Tegra 2. For example, > the Samsung Hummingbird in the Nexus S or Apple A4. It’s telling that the > fastest released Honeycomb tablet, the Galaxy Tab 7.7, is running the > Exynos CPU from the Galaxy S II. > > Fourth, Android has a ways to go toward more efficient UI compositing. On > iOS, each UI view is rendered separately and stored in memory, so many > animations only require the GPU to recomposite UI views. GPUs are extremely > good at this. Unfortunately, on Android, the UI hierarchy is flattened > before rendering, so animations require every animating section of the > screen to be redrawn. > > Fifth, the Dalvik VM is not as mature as a desktop class JVM. Java is > notorious for terrible GUI performance on desktop. However, many of the > issues don’t carry over to the Dalvik implementation. Swing was terrible > because it was a cross platform layer on top of native APIs. It is > interesting to note that Windows Phone 7’s core UI is built in native code, > even though the original plan was to base it entirely on Silverlight. > Microsoft ultimately decided that to get the kind of UI performance > required, the code would have to be native. It’s easy to see the difference > between native and bytecode on Windows Phone 7, because third party apps > are written in Silverlight and have inferior performance (NoDo and Mango > have alleviated this problem and the Silverlight UIs are generally very > smooth now). > > Thankfully, each of the five issues listed above is solvable without > radical changes to Android. Hardware acceleration will be on all Android > phones running ICS, Dalvik continues to improve GC efficiency, the Tegra 2 > is finally obsolete, there are existing workarounds for the UI compositing > problems, and Dalvik becomes a faster VM with every release. I recently > asked +Jason Kincaid of > +TechCrunch<https://plus.google.com/103037366582313115962> if > his Galaxy Nexus was smooth, and he had this to say: > > *“In general I've found ICS on the Galaxy Nexus to be quite smooth. There > are occasional stutters — the one place where I can consistently get > jitters on the Galaxy Nexus is when I hit the multitasking button, where it > often will pause for a quarter second. That said, I find that the iPhone 4S > also jitters more than I had expected, especially when I go to access the > systemwide search (where you swipe left from the home screen).”* > > So there you go, the Android lag problem is mostly solved, right? Not so > fast. > > *Going Forward* > > > Android UI will never be completely smooth because of the design > constraints I discussed at the beginning: > > - UI rendering occurs on the main thread of an app > - UI rendering has normal priority > > Even with a Galaxy Nexus, or the quad-core EeePad Transformer Prime, *there > is no way to guarantee a smooth frame rate if these two design constraints > remain true*. It’s telling that it takes the power of a Galaxy Nexus to > approach the smoothness of a three year old iPhone. So why did the Android > team design the rendering framework like this? > > Work on Android started before the release of the iPhone, and at the time > Android was designed to be a competitor to the Blackberry. The original > Android prototype wasn’t a touch screen device. Android’s rendering > trade-offs make sense for a keyboard and trackball device. When the iPhone > came out, the Android team rushed to release a competitor product, but > unfortunately it was too late to rewrite the UI framework. > > This is the same reason why Windows Mobile 6.5, Blackberry OS, and Symbian > have terrible touch screen performance. Like Android, they were not > designed to prioritise UI rendering. Since the iPhone’s release, RIM, > Microsoft, and Nokia have abandoned their mobile OS’s and started from > scratch. *Android is the only mobile OS left that existed pre-iPhone*. > > So, why doesn’t the Android team rewrite the rendering framework? I’ll let > Romain Guy explain: > > *“...a lot of the work we have to do today is because of certain choices > made years ago... ...having the UI thread handle animations is the biggest > problem. We are working on other solutions to try to improve this (schedule > drawing on vsync instead of block on vsync after drawing, possible use a > separate rendering thread, etc.) An easy solution would of course to create > a new UI toolkit but there are many downsides to this also.”* > > Romain doesn’t elaborate on what the downsides are, but it’s not difficult > to speculate: > > - All Apps would have to be re-written to support the new framework > - Android would need a legacy support mode for old apps > - Work on other Android features would be stalled while the new framework > is developed > > However, I believe the rewrite must happen, despite the downsides. As an > aspiring product manager, I find Android’s lagginess absolutely > unacceptable. It should be priority #1 for the Android team. > > When the topic of Android comes up with both technical and nontechnical > friends, I hear over and over that Android is laggy and slow. The reality > is that Android can open apps and render web pages as fast or faster than > iOS, but perception is everything. Fixing the UI lag will go a long way to > repairing Android’s image. > > Beyond the perception issue, lag is a violation of one of Google’s core > philosophies. Google believes that things should be fast. That’s a driving > philosophy behind Google Search, Gmail, and Chrome. It’s why Google created > SPDY to improve on HTTP. It’s why Google builds tools to help websites > optimize their site. It’s why Google runs it’s own CDN. It’s why Google > Maps is rendered in WebGL. It’s why buffering on Youtube is something most > of us remember, but rarely see anymore. > > But perhaps the most salient reason why UI lag in Android is unacceptable > comes from the field of Human-Computer Interaction (HCI). Modern touch > screens imply an affordance language of 1 to 1 mapping between your finger > and animations on the screen. This is why the iOS over-scroll (elastic > band) effect is so cool, fun, and intuitive. And this is why the touch > screens on Virgin America Flights are so frustrating: they are incredibly > laggy, unresponsive, and imprecise. > > A laggy UI breaks the core affordance language of a touch screen. The > device no longer feels natural. It loses the magic. The user is pulled out > of their interaction and must implicitly acknowledge they are using an > imperfect computer simulation. I often get “lost” in an iPad, but I cringe > when a Xoom stutters between home screens. The 200 million users of Android > deserve better. > > And I know they will have it eventually. The Android team is one of the > most dedicated and talented development teams in the world. With stars like > +Dianne Hackborn <https://plus.google.com/105051985738280261832> and +Romain > Guy <https://plus.google.com/111962077049890418486> around, the Android > rendering framework is in good hands. > > I hope this post has reduced confusion surrounding Android lag. With some > luck, Android 5.0 will bring the buttery-smooth Android we’ve all dreamed > about since we first held an HTC G1. In the mean time, I’ll be in Redmond > working my butt off trying to get a beautiful and smooth mobile OS some of > the recognition it deserves. > > *Credits* > > Parts of this post was inspired by this reddit comment by ddtro who > explained the UI thread and real-time issue: > > http://www.reddit.com/r/Android/comments/mztwk/facts_and_fiction_about_android_graphics/c358f0x > > This explanation of Android versus iOS UI compositing on Hacker News by > Corun was illuminating: > http://news.ycombinator.com/item?id=3310475 > > Information about Android’s historical roots taken from *In the Plex* by > +Steven > Levy <https://plus.google.com/109074857816744029470> and *Steve Jobs* by > Walter Isaacson > > -- > "Indonesian Android Community" Join: http://forum.android.or.id > > =============== > Download Aplikasi Kompas versi Digital dan Keren > https://market.android.com/details?id=com.kompas.android.kec > --------------------- > Gunakan Paket Unlimited Data XL Mobile Broadband > http://www.xl.co.id/XLInternet/BroadbandInternet > -------------------- > PING'S Mobile - Plaza Semanggi > E-mail: i...@pings-mobile.com Ph. 021-25536796 > -------------------- > i-gadget Store - BEC Bandung > E-mail: a...@i-gadgetstore.com Ph. 0812-21111191 > -------------------- > Toko EceranShop - BEC Bandung > E-mail: wi...@eceranshop.com Ph. 0815-56599888 > =============== > > Aturan Jualan dan Kloteran ID-Android http://goo.gl/YBN21 > -- Regards, Ali Ramdani | Thoa Past is experience, Present is experiment & Future is expectation. Use experience in your experiments to achieve your expectations. -- "Indonesian Android Community" Join: http://forum.android.or.id =============== Download Aplikasi Kompas versi Digital dan Keren https://market.android.com/details?id=com.kompas.android.kec --------------------- Gunakan Paket Unlimited Data XL Mobile Broadband http://www.xl.co.id/XLInternet/BroadbandInternet -------------------- PING'S Mobile - Plaza Semanggi E-mail: i...@pings-mobile.com Ph. 021-25536796 -------------------- i-gadget Store - BEC Bandung E-mail: a...@i-gadgetstore.com Ph. 0812-21111191 -------------------- Toko EceranShop - BEC Bandung E-mail: wi...@eceranshop.com Ph. 0815-56599888 =============== Aturan Jualan dan Kloteran ID-Android http://goo.gl/YBN21
