geleng2 saya dulu dari android HD2 lompat ke iphone 4.. sempet kaget ama smoothnya iphone 4... trus pegang GTab 10.1 masih aja lag.. sempet kaget.. gile tegra 2 and dual core tp si android masih aja lag...
trus beli liat kegantengan SGS2 sumpe ngiler bgt!! tp blom pengen lepas dr iphone 4 gara2 cicilan blom lunas :p akhirnya pas mas ary jual sgs2 cdma (epic 4g touch) langsung tanpa pikir panjang saya sikat wekeke.. dan ternyata so far saya bener2 ga ngerasain tuh lag2an lagi... bener2 fluid and smooooth... malah lebih smooth dr iphone 4 saya.. so far puaaaazzzz bgt ama si epic 4g touch ini... mana batreny irit bener.. jadi saya binging jg knp hrs nunggu android 5 buat nunggu smooth?? On 12/7/11, Henry Wiwiet <[email protected]> wrote: > Hadoh..gak ngerti :) > Emang Android ga smooth ya...baru tau :) > > On Wed, Dec 7, 2011 at 3:13 PM, Ali Ramdani - Thoa - <[email protected] >> wrote: > >> 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 >> <[email protected]>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: [email protected] Ph. 021-25536796 >>> -------------------- >>> i-gadget Store - BEC Bandung >>> E-mail: [email protected] Ph. 0812-21111191 >>> -------------------- >>> Toko EceranShop - BEC Bandung >>> E-mail: [email protected] 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: [email protected] Ph. 021-25536796 >> -------------------- >> i-gadget Store - BEC Bandung >> E-mail: [email protected] Ph. 0812-21111191 >> -------------------- >> Toko EceranShop - BEC Bandung >> E-mail: [email protected] Ph. 0815-56599888 >> =============== >> >> Aturan Jualan dan Kloteran ID-Android http://goo.gl/YBN21 >> > > -- > "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: [email protected] Ph. 021-25536796 > -------------------- > i-gadget Store - BEC Bandung > E-mail: [email protected] Ph. 0812-21111191 > -------------------- > Toko EceranShop - BEC Bandung > E-mail: [email protected] Ph. 0815-56599888 > =============== > > Aturan Jualan dan Kloteran ID-Android http://goo.gl/YBN21 > -- Cheers, Imam Moeloek Proud Owner of SGS2 4G -- "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: [email protected] Ph. 021-25536796 -------------------- i-gadget Store - BEC Bandung E-mail: [email protected] Ph. 0812-21111191 -------------------- Toko EceranShop - BEC Bandung E-mail: [email protected] Ph. 0815-56599888 =============== Aturan Jualan dan Kloteran ID-Android http://goo.gl/YBN21
