4 ms·

While I'm sure Dalvik contributes, Android has had many more serious issues in terms of user responsiveness. * Android devices have very laggy touch responsive

by lhl 13y ago

While I'm sure Dalvik contributes, Android has had many more serious issues in terms of user responsiveness. * Android devices have very laggy touch responsiveness in general, while this is something Apple has spent considerable effort optimizing [1] * Only in recent revisions (Project Butter [2]) has Android made significant improvements to its general UI lag/smoothness issues. At various times, Google employees have gone into extensive descriptions of why the UI is so janky [3][4] * Many of the default Android elements were for quite a long time, very unoptimized - this included calls w/ lots of overdraw, or lack of node recycling for lists. This forced app developers to take on the bulk of performance optimization. You can take a guess how often that is done well. [5] Over time, Android the OS, SDK/API, tools have all improved but I believe your second paragraph gets it right. At the end of the day, people at Apple cared a lot about getting the first versions of iOS to feel great. No one at Google cared enough about about it. Even today, when you compare the iPhone to the latest Nexus devices, there's lots of hardware integration issues that will probably never get fixed (outside of community patches). [1] http://venturebeat.com/2013/09/19/apples-iphone-5-touchscreen-is-2-5-times-faster-than-android-devices/ http://venturebeat.com/2013/09/19/apples-iphone-5-touchscree... [2] http://www.androidpolice.com/2012/07/12/getting-to-know-android-4-1-part-3-project-butter-how-it-works-and-what-it-added/ http://www.androidpolice.com/2012/07/12/getting-to-know-andr... [3] https://plus.google.com/105051985738280261832/posts/2FXDCz8x93s https://plus.google.com/105051985738280261832/posts/2FXDCz8x... [4] http://lazytechguys.com/news/google-dev-explains-why-android-user-interface-is-laggy-while-ios-wp7-qnx-are-fluid/ http://lazytechguys.com/news/google-dev-explains-why-android... [5] http://www.curious-creature.org/2012/12/01/android-performance-case-study/ http://www.curious-creature.org/2012/12/01/android-performan...

simmons 13y ago
From my experience with working on Android internals, I also get the impression there is a ridiculous amount of IPC happening during normal operation, much of which involves Dalvik components (such as the activity manager) as intermediaries. I've sometimes wondered if this could contribute to a noticeable performance degradation. Quantifying this IPC might make an interesting experiment and blog post...
- hackcasual 13y ago
  The IPC implementation is Binder, and I believe the overhead, even in the G1 days was microseconds.
  - simmons 13y ago
    Binder itself is very fast. I'm mostly thinking about the overhead of higher-level constructs build on top of binder (broadcast intents, etc.) that are handled in Dalvik code and that can become numerous as various apps make connections to various other apps.
asveikau 13y ago
> [4] http://lazytechguys.com/news/google-dev-explains-why-android-user-interface-is-laggy-while-ios-wp7-qnx-are-fluid/ http://lazytechguys.com/news/google-dev-explains-why-android... Man that was a weird read. Guy spends a few months interning and all of a sudden talks about his profound connection to the campus, the fundamental flaws in the product architecture, but watch out! He may be biased since he will be interning on a competing product the next summer! Regardless of the facts of the matter this seems like a very non-authoritative source.
- magicalist 13y ago
  It's like no one actually reads Dianne Hackborn's post (#3 above), which was in direct response to that guy's musings going viral when he had no idea what he was talking about. edit: oops, that was the post that sparked the original specious musings. I meant this followup one: https://plus.google.com/105051985738280261832/posts/XAZ4CeVP6DC https://plus.google.com/105051985738280261832/posts/XAZ4CeVP...
  - asveikau 13y ago
    What drew me to #4 was the baiting headline (Google dev explains...)
kllrnohj 13y ago
[1] The Android code for that test is messed up, and suffers from a race condition and isn't tied to vsync like a normal Android app is. There's a pull request on their github page to fix it, but they haven't accepted it. Regardless, this is a hardware thing not a software one. Apple uses very, very good touch screens. The Nexus 5 also has a really good touch screen, with total touch-to-display latency in the 60ms range. [4] is total horseshit. He doesn't know squat about any of the platforms. iOS devs also called him out for getting just about everything wrong about how iOS works. [5] is something iOS devs totally also have to do as well. That is so not an Android-specific thing.
zht 13y ago
[4] was a post written by a QA intern on a different team. His post was thoroughly debunked by Dianne. I know the guy in person and he is a general loud mouth who never hesitates to spew nonsense about topics that he knows nothing about.
deleted 13y ago
[deleted]
thrownaway2424 13y ago
Interesting post. I would throw in a social angle. Android will suffer from UI lag until it's scrapped and rewritten, because its early development was heavily influenced by Romain Guy, a developer who was a huge proponent of Swing and who actually thought that JavaFX was a good idea. This is a person who has basically never seen a responsive UI and cannot understand what makes Android "laggy" at a deep level. Some of your other links show that Android is pretty long on people who will write long defensive blog posts, short on people who can make efficient, responsive graphics stacks. Social problem, basically.
- agumonkey 13y ago
  Even post 4.1 isn't smooth enough for you ? Project butter was a great leap forward to me, and it seems romain guy was involved in it https://www.google.com/search?q=romain+guy+project+butter https://www.google.com/search?q=romain+guy+project+butter
mdwrigh2 13y ago
> lack of node recycling for lists Adapter#getView[1] has been around since API 1, which is used in ListView (as well GridView, etc.) to recycle view nodes. [1]: http://developer.android.com/reference/android/widget/Adapter.html#getView(int http://developer.android.com/reference/android/widget/Adapte..., android.view.View, android.view.ViewGroup)

by lhl 13y ago

simmons 13y ago

From my experience with working on Android internals, I also get the impression there is a ridiculous amount of IPC happening during normal operation, much of which involves Dalvik components (such as the activity manager) as intermediaries. I've sometimes wondered if this could contribute to a noticeable performance degradation. Quantifying this IPC might make an interesting experiment and blog post...

hackcasual 13y ago
The IPC implementation is Binder, and I believe the overhead, even in the G1 days was microseconds.
- simmons 13y ago
  Binder itself is very fast. I'm mostly thinking about the overhead of higher-level constructs build on top of binder (broadcast intents, etc.) that are handled in Dalvik code and that can become numerous as various apps make connections to various other apps.

asveikau 13y ago

> [4] http://lazytechguys.com/news/google-dev-explains-why-android-user-interface-is-laggy-while-ios-wp7-qnx-are-fluid/ http://lazytechguys.com/news/google-dev-explains-why-android... Man that was a weird read. Guy spends a few months interning and all of a sudden talks about his profound connection to the campus, the fundamental flaws in the product architecture, but watch out! He may be biased since he will be interning on a competing product the next summer! Regardless of the facts of the matter this seems like a very non-authoritative source.

magicalist 13y ago
It's like no one actually reads Dianne Hackborn's post (#3 above), which was in direct response to that guy's musings going viral when he had no idea what he was talking about. edit: oops, that was the post that sparked the original specious musings. I meant this followup one: https://plus.google.com/105051985738280261832/posts/XAZ4CeVP6DC https://plus.google.com/105051985738280261832/posts/XAZ4CeVP...
- asveikau 13y ago
  What drew me to #4 was the baiting headline (Google dev explains...)

kllrnohj 13y ago

[1] The Android code for that test is messed up, and suffers from a race condition and isn't tied to vsync like a normal Android app is. There's a pull request on their github page to fix it, but they haven't accepted it. Regardless, this is a hardware thing not a software one. Apple uses very, very good touch screens. The Nexus 5 also has a really good touch screen, with total touch-to-display latency in the 60ms range. [4] is total horseshit. He doesn't know squat about any of the platforms. iOS devs also called him out for getting just about everything wrong about how iOS works. [5] is something iOS devs totally also have to do as well. That is so not an Android-specific thing.

zht 13y ago

[4] was a post written by a QA intern on a different team. His post was thoroughly debunked by Dianne. I know the guy in person and he is a general loud mouth who never hesitates to spew nonsense about topics that he knows nothing about.

deleted 13y ago

[deleted]

thrownaway2424 13y ago

Interesting post. I would throw in a social angle. Android will suffer from UI lag until it's scrapped and rewritten, because its early development was heavily influenced by Romain Guy, a developer who was a huge proponent of Swing and who actually thought that JavaFX was a good idea. This is a person who has basically never seen a responsive UI and cannot understand what makes Android "laggy" at a deep level. Some of your other links show that Android is pretty long on people who will write long defensive blog posts, short on people who can make efficient, responsive graphics stacks. Social problem, basically.

agumonkey 13y ago
Even post 4.1 isn't smooth enough for you ? Project butter was a great leap forward to me, and it seems romain guy was involved in it https://www.google.com/search?q=romain+guy+project+butter https://www.google.com/search?q=romain+guy+project+butter

mdwrigh2 13y ago

> lack of node recycling for lists Adapter#getView[1] has been around since API 1, which is used in ListView (as well GridView, etc.) to recycle view nodes. [1]: http://developer.android.com/reference/android/widget/Adapter.html#getView(int http://developer.android.com/reference/android/widget/Adapte..., android.view.View, android.view.ViewGroup)