9 ms·

I've been an Android user since my first smartphone. I've heard several times iPhone users complain that Android equivalents of their iOS apps felt sluggish; th

by jeswin 13y ago

I've been an Android user since my first smartphone. I've heard several times iPhone users complain that Android equivalents of their iOS apps felt sluggish; though they couldn't pinpoint it exactly. If these numbers are true, it might well be true. Objective-C might not suffer from such a significant slowdown. I think it is one of the things Apple gets right; they know what matters. As an outsider to the iOS/Mac ecosystem I've often felt that Apple makes trade-offs in productivity to achieve a better experience for the end user. While these tests aren't indicative of typical app performance (most apps aren't doing math in a loop), an order of magnitude performance difference is enough to show up on many apps. I wonder if Google made a mistake by not choosing native code for Android apps. We have heard forever about Java (and other run-times) getting close to C in performance, but outside of specific test cases native code still runs circles around everything else out there.

hcho 13y ago
The perceived sluggishness of Android was down to how the system was architected, especially around the way the UI thread was prioritised. I say was, because Google threw a lot of hardware and money to workarounds for that problem. It is less noticeable these days. They won't be able to fix it completely without a ground up redesign though.
- officialjunk 13y ago
  I also read a breakdown of the touch screen scan rate (the refresh rate at which touch gestures are captured), which was significantly faster for ios devices. That also contributed to the difference in feel. Do you know if android devices have "caught up?"
  - gareim 13y ago
    I think you might be interested in this: http://forum.xda-developers.com/showthread.php?t=2706200 http://forum.xda-developers.com/showthread.php?t=2706200 I have had an S3, iPhone 5, and HTC One (M7) and the iPhone 5 definitely felt the smoothest, but now I'm interested in seeing if the M8 really has leveled the playing field.
  - mdwrigh2 13y ago
    The scan rate isn't typically the worst factor, which is usually between 120-300hz (meaning a max additional latency of 3 - 30ms), but rather deriving meaning from that data is. Filtering in a noise-free environment typically adds a few scan frames of latency, which is what puts devices in the 60-120ms of latency, and a noisy environment (i.e. plugged in to a cheap charger) can easily up that to a few hundred ms of latency.
- mikeash 13y ago
  The UI thread doesn't get any special treatment on iOS, so unless Android is deprioritizing its UI thread, it doesn't seem likely that this would be a problem.
  - mdwrigh2 13y ago
    Doesn't get any special treatment by Android either. All other threads get set to background priority (well, most, but all that we care about), which by default can only consume 10% of CPU resources.
- mdwrigh2 13y ago
  > The perceived sluggishness of Android was down to how the system was architected, especially around the way the UI thread was prioritised UI thread priority has been debunked time and time again: https://plus.google.com/105051985738280261832/posts/XAZ4CeVP6DC https://plus.google.com/105051985738280261832/posts/XAZ4CeVP... Even if it hadn't been, what evidence is there that it would require a ground up redesign?
bluerobotcat 13y ago
In the long run, having a more modern language should benefit Android because it means the barrier of entry is lower for programmers. In the meantime it does seem likely that Java has a non-negligible performance cost. My personal worry is that fast Garbage Collectors usually assume that twice the memory is available than is used. That might put the fact that Android phones typically have more memory than Apple devices in an interesting light.
- rsynnott 13y ago
  _Is_ Java significantly more 'modern', than Objective C, though? How? It's not like it's much newer; development started in 1991, vs early 80s for ObjC.
  - pjmlp 13y ago
    - GC - namespaces - memory safe - you don't have to type @ and [] everywhere to switch between dynamic and static worlds As for the vm thing, there are also commercial native compilers, even though the general HNer tend not to be aware of them.
    - rsynnott 13y ago
      > GC Thus giving Android developers all the fun of dealing with GC pauses. There's a lot to be said for ARC, really; I'm quit glad Apple ditched their brief experiment with ObjC GC. > namespaces I'll give you that one; lack of namespaces it the worst thing about ObjC. > ... Dynamic and static worlds... I'm not sure what you mean here; Java is a statically typed language, and does not have a 'dynamic world'. ObjC has a fo of optional dynamic typing, which is arguably modern, though also only arguably a good thing.
      - pjmlp 13y ago
        > I'm quit glad Apple ditched their brief experiment with ObjC GC. Because they failed to implement a GC that didn't crash all the time, as the Apple forums used to testify before ARC was touted as the best thing since sliced bread. The wonders of mixing Objective-C libraries compiled in mixed mode. > I'm not sure what you mean here; The mixed nature of Objective-C. With @ and [] one is in Smalltalk land. Without them, one is in C world. > Java is a statically typed language, and does not have a 'dynamic world'. Yes it has, via reflection, annotations and dynamic bytecode generation.
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...
  - 13y ago
personZ 13y ago
This benchmark is a bit artificial (though still interesting and illuminating), given that much of what we do on our smartphone is not so computationally intensive in our own code, but instead most apps are a relatively thin layer of glue and duct tape that coordinates and orchestrates the underlying native platform code. The choice of Java/Dalvik does seem like a mistake, and was a carry-over of Android coming from classic J2ME roots, which worked well with Google's love of all things Java.
- mdwrigh2 13y ago
  >The choice of Java/Dalvik does seem like a mistake, and was a carry-over of Android coming from classic J2ME roots, which worked well with Google's love of all things Java. Where did you get the idea that Android had J2ME roots? It definitely did not.
  - pjmlp 13y ago
    At least they had planned J2ME support as well. http://www.theverge.com/2012/4/25/2974676/this-was-the-original-google-phone-presented-in-2006 http://www.theverge.com/2012/4/25/2974676/this-was-the-origi...
    - mdwrigh2 13y ago
      Through a compatibility mode. The platform itself was specifically not J2ME.
  - personZ 13y ago
    Rubin came from Danger, which was a J2ME company. They started Android (pre-Google) as yet another J2ME company. When they were eventually acquired by Google, Google didn't want to play ball with Sun, so they went with a clean-room simile, but, to consult actual Google documentation (three years after Android was started)- http://www.scribd.com/doc/217988654/13/Boot-Loader http://www.scribd.com/doc/217988654/13/Boot-Loader the Platform will be compatible with Java Platform, Micro Edition (Java ME).
pjmlp 13y ago
> I wonder if Google made a mistake by not choosing native code for Android apps. I would say yes. > We have heard forever about Java (and other run-times) getting close to C in performance, but outside of specific test cases native code still runs circles around everything else out there. Please don't mix language vs implementation.
smrtinsert 13y ago
First, the word iphone isn't even mentioned in the article, but its funny how quickly HN drops into an iphone vs. android Second, the author points out NDK over Java as a solution which is already leveraged by some popular apis transparently from java, such as libgdx. Finally, the ui is responsive enough. My biggest annoyance whenever I have to help my in laws or my parents with their iphones and there is no back button - I don't notice any significant difference between their iphones and my Galaxy S3, and I'm sure Samsungs phones have only gotten better.
- gmac 13y ago
  (Equally, my biggest annoyance on Android is often the lack of an on-screen back button, and the small but annoying proportion of times when the hardware back button takes me somewhere other than I expected.)
  - sizzle 13y ago
    You can get around the back button part by rooting and allowing double tap of back arrow to jump between last open application. This solved that pain point for me
    - coin 13y ago
      People don't want to have to root a device to work around usability issues. That's why iOS devices are so popular, out of the box they just work (for the most part).
      - mikeash 13y ago
        On the other hand, when you do bump into a problem, you generally can root Android devices, while iOS is getting to be pretty rough there.
      - bananas 13y ago
        I've used both extensively. When iOS screws up, which at least it does in my house regularly[1], you're SOL. We're moving to Android devices slowly (up two Moto Gs at the moment). [1] we have three iOS devices and I'm the loveless tech support for them.
chrisdevereux 13y ago
> If these numbers are true, it might well be true. Objective-C might not suffer from such a significant slowdown. Kinda. I imagine that if these benchmarks were run on idiomatic Objective-C, they'd be an order of magnitude slower than Java. All method calls are un-inlineable and often require a hash table lookup to resolve. However, the nice thing about Objective-C is that it's ridiculously easy to write performance-critical stuff in C or C++, then expose it with a nice OO interface. Which means that you (or, more likely, the people who wrote the library you're using) are more likely to bother. That and the lack of GC making latency easier to reason about. So while it is probably easier to write performant UIs in Objective-C than Java, it isn't because of the reasons mentioned here.
- gmac 13y ago
  Yes — in fact, it's arguably more natural in most cases to write your performance-critical stuff (e.g. math in loops) in plain C. There's rarely any reason to start boxing values up in NSNumbers and then unboxing them again. In addition, Apple's Accelerate framework makes it easy and natural to take advantage of SIMD for further speedups — you can get powerful vector operations with single function calls. This seems to have no Android equivalent.
  - pjmlp 13y ago
    > This seems to have no Android equivalent. Renderscript?
    - gmac 13y ago
      Thanks — previous Googling hadn't turned this up for some reason.
- Someone 13y ago
  "If these benchmarks were run on idiomatic Objective-C" s/idiomatic/pure/ I haven't programmed it much, but to me, idiomatic objective-C is when you use it as a sort-of scripting layer on top of your C code. No sane programmer would write ten layers of Objective-C message passing code; two or three is fine, on the bottom of your call stack (and hence, rarely executed)
saosebastiao 13y ago
Ive tried pointing this out before on HN and was met with a downvote army...my worst ranked post of all time IIRC. The thing is, I didnt need to see benchmarks to know iOS was significantly better. How is it not obvious to everyone else?
Ologn 13y ago
> I wonder if Google made a mistake by not choosing native code for Android apps. We have heard forever about Java (and other run-times) getting close to C in performance, but outside of specific test cases native code still runs circles around everything else out there. You can use native code for Android apps. I do. In the NDK samples there is an app called NativeActivity which is 100% C/C++. You compile an APK without writing any Java/Dalvik code. From my anecdotal knowledge, most of the popular Android games are written mostly in C++, using the OpenGL ES library, and have a common code base with their iOS counterparts. Maybe they are all native code, maybe they use some Java and JNI stuff, but they are mostly C++. So Android is native on the game side, where it is needed. A deep look at how all native code runs will show some non-native system code run when it launches, but that becomes pedantry if performance and not purity is the focus. Android is cleft in two - applications are mostly Java/Dalvik with maybe some JNI access to C/C++ libraries, games from all my discussions with Android game developers are usually mostly the same C++ code and OpenGL ES they are using on iOS. One example I know a little about is Jigzo. It is an open source game which is C++ and uses OpenGL and SDL libraries. The original developer ported it to iOS. I ported it to Android. Same basic code base, with a few tweaks for each OS. I changed the name from Jigzo to Jigsaw Puzzles on Play though.
- mdwrigh2 13y ago
  The NDK is great for games, but is really not meant for other types of applications. It lacks a ton of mechanisms to interact with other pieces of the platform.
- pjmlp 13y ago
  I also do use NDK for my hobby graphics programming, but outside games it is pretty much handicapped and very few people like to write JNI code everywhere. Not to mention the performance issues due to marshaling. At least now the NDK has some sample source code for JNI helper classes to ease the pain. Qt is the only sane approach for doing full Android applications in C++, but then one is writing multiplatform code anyway.
ibrahima 13y ago
Eh, most apps are not doing computations like this in their main thread. Android does have some touch responsiveness issues, but this article has nothing to do with that.
kllrnohj 13y ago
> I wonder if Google made a mistake by not choosing native code for Android apps. Seeing as Android runs on a lot more than just ARMv7, no, they didn't appear to make a mistake here at all. Apple can tell developers to compile their app twice for ARMv7 w/ NEON & ARMv8-A64, but is Google going to go tell everyone to compile for ARMv6 (Android devices running this are still shipping), ARMv7 w/o NEON, ARMv7 w/ NEON, ARMv8 (not here yet on Android, but obviously coming), MIPS, X86, etc...? > We have heard forever about Java (and other run-times) getting close to C in performance, but outside of specific test cases native code still runs circles around everything else out there. The vast majority of the Java code in an Android app isn't performance-critical either. The code that actually renders an app is all in native anyway. The code to handle touch events and such isn't, but the difference between .1ms and .2ms isn't going to break the 16ms bank either.
- fleitz 13y ago
  They don't 'tell' you, you press Command-B and it happens. When there are new architectures, you get a warning in XCode and press "Upgrade Project". Right now my 'default' build is for armv7, armv7s, armv8, x86, x86_64. This setup required no effort on my part. I just created a new project.
- deleted 13y ago
  [deleted]
- Tmmrn 13y ago
  > ARMv7 w/o NEON Several of Google's own google apps depend on native libraries. Try to install google apps for android 4.2+ on a device without neon like tegra2 and see how many of them actually work and how many crash with SIGILL.

by jeswin 13y ago

hcho 13y ago

The perceived sluggishness of Android was down to how the system was architected, especially around the way the UI thread was prioritised. I say was, because Google threw a lot of hardware and money to workarounds for that problem. It is less noticeable these days. They won't be able to fix it completely without a ground up redesign though.

officialjunk 13y ago
I also read a breakdown of the touch screen scan rate (the refresh rate at which touch gestures are captured), which was significantly faster for ios devices. That also contributed to the difference in feel. Do you know if android devices have "caught up?"
- gareim 13y ago
  I think you might be interested in this: http://forum.xda-developers.com/showthread.php?t=2706200 http://forum.xda-developers.com/showthread.php?t=2706200 I have had an S3, iPhone 5, and HTC One (M7) and the iPhone 5 definitely felt the smoothest, but now I'm interested in seeing if the M8 really has leveled the playing field.
- mdwrigh2 13y ago
  The scan rate isn't typically the worst factor, which is usually between 120-300hz (meaning a max additional latency of 3 - 30ms), but rather deriving meaning from that data is. Filtering in a noise-free environment typically adds a few scan frames of latency, which is what puts devices in the 60-120ms of latency, and a noisy environment (i.e. plugged in to a cheap charger) can easily up that to a few hundred ms of latency.
mikeash 13y ago
The UI thread doesn't get any special treatment on iOS, so unless Android is deprioritizing its UI thread, it doesn't seem likely that this would be a problem.
- mdwrigh2 13y ago
  Doesn't get any special treatment by Android either. All other threads get set to background priority (well, most, but all that we care about), which by default can only consume 10% of CPU resources.
mdwrigh2 13y ago
> The perceived sluggishness of Android was down to how the system was architected, especially around the way the UI thread was prioritised UI thread priority has been debunked time and time again: https://plus.google.com/105051985738280261832/posts/XAZ4CeVP6DC https://plus.google.com/105051985738280261832/posts/XAZ4CeVP... Even if it hadn't been, what evidence is there that it would require a ground up redesign?

bluerobotcat 13y ago

In the long run, having a more modern language should benefit Android because it means the barrier of entry is lower for programmers. In the meantime it does seem likely that Java has a non-negligible performance cost. My personal worry is that fast Garbage Collectors usually assume that twice the memory is available than is used. That might put the fact that Android phones typically have more memory than Apple devices in an interesting light.

rsynnott 13y ago
_Is_ Java significantly more 'modern', than Objective C, though? How? It's not like it's much newer; development started in 1991, vs early 80s for ObjC.
- pjmlp 13y ago
  - GC - namespaces - memory safe - you don't have to type @ and [] everywhere to switch between dynamic and static worlds As for the vm thing, there are also commercial native compilers, even though the general HNer tend not to be aware of them.
  - rsynnott 13y ago
    > GC Thus giving Android developers all the fun of dealing with GC pauses. There's a lot to be said for ARC, really; I'm quit glad Apple ditched their brief experiment with ObjC GC. > namespaces I'll give you that one; lack of namespaces it the worst thing about ObjC. > ... Dynamic and static worlds... I'm not sure what you mean here; Java is a statically typed language, and does not have a 'dynamic world'. ObjC has a fo of optional dynamic typing, which is arguably modern, though also only arguably a good thing.
    - pjmlp 13y ago
      > I'm quit glad Apple ditched their brief experiment with ObjC GC. Because they failed to implement a GC that didn't crash all the time, as the Apple forums used to testify before ARC was touted as the best thing since sliced bread. The wonders of mixing Objective-C libraries compiled in mixed mode. > I'm not sure what you mean here; The mixed nature of Objective-C. With @ and [] one is in Smalltalk land. Without them, one is in C world. > Java is a statically typed language, and does not have a 'dynamic world'. Yes it has, via reflection, annotations and dynamic bytecode generation.

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...
- 13y ago

personZ 13y ago

This benchmark is a bit artificial (though still interesting and illuminating), given that much of what we do on our smartphone is not so computationally intensive in our own code, but instead most apps are a relatively thin layer of glue and duct tape that coordinates and orchestrates the underlying native platform code. The choice of Java/Dalvik does seem like a mistake, and was a carry-over of Android coming from classic J2ME roots, which worked well with Google's love of all things Java.

mdwrigh2 13y ago
>The choice of Java/Dalvik does seem like a mistake, and was a carry-over of Android coming from classic J2ME roots, which worked well with Google's love of all things Java. Where did you get the idea that Android had J2ME roots? It definitely did not.
- pjmlp 13y ago
  At least they had planned J2ME support as well. http://www.theverge.com/2012/4/25/2974676/this-was-the-original-google-phone-presented-in-2006 http://www.theverge.com/2012/4/25/2974676/this-was-the-origi...
  - mdwrigh2 13y ago
    Through a compatibility mode. The platform itself was specifically not J2ME.
- personZ 13y ago
  Rubin came from Danger, which was a J2ME company. They started Android (pre-Google) as yet another J2ME company. When they were eventually acquired by Google, Google didn't want to play ball with Sun, so they went with a clean-room simile, but, to consult actual Google documentation (three years after Android was started)- http://www.scribd.com/doc/217988654/13/Boot-Loader http://www.scribd.com/doc/217988654/13/Boot-Loader the Platform will be compatible with Java Platform, Micro Edition (Java ME).

pjmlp 13y ago

> I wonder if Google made a mistake by not choosing native code for Android apps. I would say yes. > We have heard forever about Java (and other run-times) getting close to C in performance, but outside of specific test cases native code still runs circles around everything else out there. Please don't mix language vs implementation.

smrtinsert 13y ago

First, the word iphone isn't even mentioned in the article, but its funny how quickly HN drops into an iphone vs. android Second, the author points out NDK over Java as a solution which is already leveraged by some popular apis transparently from java, such as libgdx. Finally, the ui is responsive enough. My biggest annoyance whenever I have to help my in laws or my parents with their iphones and there is no back button - I don't notice any significant difference between their iphones and my Galaxy S3, and I'm sure Samsungs phones have only gotten better.

gmac 13y ago
(Equally, my biggest annoyance on Android is often the lack of an on-screen back button, and the small but annoying proportion of times when the hardware back button takes me somewhere other than I expected.)
- sizzle 13y ago
  You can get around the back button part by rooting and allowing double tap of back arrow to jump between last open application. This solved that pain point for me
  - coin 13y ago
    People don't want to have to root a device to work around usability issues. That's why iOS devices are so popular, out of the box they just work (for the most part).
    - mikeash 13y ago
      On the other hand, when you do bump into a problem, you generally can root Android devices, while iOS is getting to be pretty rough there.
    - bananas 13y ago
      I've used both extensively. When iOS screws up, which at least it does in my house regularly[1], you're SOL. We're moving to Android devices slowly (up two Moto Gs at the moment). [1] we have three iOS devices and I'm the loveless tech support for them.

chrisdevereux 13y ago

> If these numbers are true, it might well be true. Objective-C might not suffer from such a significant slowdown. Kinda. I imagine that if these benchmarks were run on idiomatic Objective-C, they'd be an order of magnitude slower than Java. All method calls are un-inlineable and often require a hash table lookup to resolve. However, the nice thing about Objective-C is that it's ridiculously easy to write performance-critical stuff in C or C++, then expose it with a nice OO interface. Which means that you (or, more likely, the people who wrote the library you're using) are more likely to bother. That and the lack of GC making latency easier to reason about. So while it is probably easier to write performant UIs in Objective-C than Java, it isn't because of the reasons mentioned here.

gmac 13y ago
Yes — in fact, it's arguably more natural in most cases to write your performance-critical stuff (e.g. math in loops) in plain C. There's rarely any reason to start boxing values up in NSNumbers and then unboxing them again. In addition, Apple's Accelerate framework makes it easy and natural to take advantage of SIMD for further speedups — you can get powerful vector operations with single function calls. This seems to have no Android equivalent.
- pjmlp 13y ago
  > This seems to have no Android equivalent. Renderscript?
  - gmac 13y ago
    Thanks — previous Googling hadn't turned this up for some reason.
Someone 13y ago
"If these benchmarks were run on idiomatic Objective-C" s/idiomatic/pure/ I haven't programmed it much, but to me, idiomatic objective-C is when you use it as a sort-of scripting layer on top of your C code. No sane programmer would write ten layers of Objective-C message passing code; two or three is fine, on the bottom of your call stack (and hence, rarely executed)

saosebastiao 13y ago

Ive tried pointing this out before on HN and was met with a downvote army...my worst ranked post of all time IIRC. The thing is, I didnt need to see benchmarks to know iOS was significantly better. How is it not obvious to everyone else?

Ologn 13y ago

> I wonder if Google made a mistake by not choosing native code for Android apps. We have heard forever about Java (and other run-times) getting close to C in performance, but outside of specific test cases native code still runs circles around everything else out there. You can use native code for Android apps. I do. In the NDK samples there is an app called NativeActivity which is 100% C/C++. You compile an APK without writing any Java/Dalvik code. From my anecdotal knowledge, most of the popular Android games are written mostly in C++, using the OpenGL ES library, and have a common code base with their iOS counterparts. Maybe they are all native code, maybe they use some Java and JNI stuff, but they are mostly C++. So Android is native on the game side, where it is needed. A deep look at how all native code runs will show some non-native system code run when it launches, but that becomes pedantry if performance and not purity is the focus. Android is cleft in two - applications are mostly Java/Dalvik with maybe some JNI access to C/C++ libraries, games from all my discussions with Android game developers are usually mostly the same C++ code and OpenGL ES they are using on iOS. One example I know a little about is Jigzo. It is an open source game which is C++ and uses OpenGL and SDL libraries. The original developer ported it to iOS. I ported it to Android. Same basic code base, with a few tweaks for each OS. I changed the name from Jigzo to Jigsaw Puzzles on Play though.

mdwrigh2 13y ago
The NDK is great for games, but is really not meant for other types of applications. It lacks a ton of mechanisms to interact with other pieces of the platform.
pjmlp 13y ago
I also do use NDK for my hobby graphics programming, but outside games it is pretty much handicapped and very few people like to write JNI code everywhere. Not to mention the performance issues due to marshaling. At least now the NDK has some sample source code for JNI helper classes to ease the pain. Qt is the only sane approach for doing full Android applications in C++, but then one is writing multiplatform code anyway.

ibrahima 13y ago

Eh, most apps are not doing computations like this in their main thread. Android does have some touch responsiveness issues, but this article has nothing to do with that.

kllrnohj 13y ago

> I wonder if Google made a mistake by not choosing native code for Android apps. Seeing as Android runs on a lot more than just ARMv7, no, they didn't appear to make a mistake here at all. Apple can tell developers to compile their app twice for ARMv7 w/ NEON & ARMv8-A64, but is Google going to go tell everyone to compile for ARMv6 (Android devices running this are still shipping), ARMv7 w/o NEON, ARMv7 w/ NEON, ARMv8 (not here yet on Android, but obviously coming), MIPS, X86, etc...? > We have heard forever about Java (and other run-times) getting close to C in performance, but outside of specific test cases native code still runs circles around everything else out there. The vast majority of the Java code in an Android app isn't performance-critical either. The code that actually renders an app is all in native anyway. The code to handle touch events and such isn't, but the difference between .1ms and .2ms isn't going to break the 16ms bank either.

fleitz 13y ago
They don't 'tell' you, you press Command-B and it happens. When there are new architectures, you get a warning in XCode and press "Upgrade Project". Right now my 'default' build is for armv7, armv7s, armv8, x86, x86_64. This setup required no effort on my part. I just created a new project.
deleted 13y ago
[deleted]
Tmmrn 13y ago
> ARMv7 w/o NEON Several of Google's own google apps depend on native libraries. Try to install google apps for android 4.2+ on a device without neon like tegra2 and see how many of them actually work and how many crash with SIGILL.