Why iPhone With 1GB RAM Performs Better Than Android Devices With 2GB Or More RAM?

[francescob]

The real question should be: why are most phones still stuck with Snapdragon 200, 400 or S4 SoCs? Any why haven't manufacturers all switched to Atoms on phablets yet? :O

[xankazo]

Because manufactures customize  the ###### out of Android. They add so much bloat, for it to run even remotely good they have to throw more ram at it. My Moto G 2013 with practically stock Android, 1 GB of ram and a Quad Core is Crazy responsive.

So is mine. It's my first Android phone and the experience has been quite positive so far. I'm a Windows Phone user at heart, but I also love tech and I think it was stupid not to try Android for such a bargain.

[Shadrack]

Back in the EVO 4G days (my wife had one, she hated it), I'd often compare Android to a gas guzzling SUV. Lots of features, but sure does burn a lot of fuel.

 

That analogy doesn't really hold as much water anymore because, well, RAM and faster processors really are cheap.

 

I don't really know much about Android, but the garbage collecting explanation was an interesting read.

 

iOS definitely benefits from more memory, but it doesn't really increase the smoothness of everything. Hold my iPad Air 2 with 2GB up against an iPad Air 1 with 1GB of memory, and the performance in you basic applications looks identical (mostly because the eye candy animations are what take so much time, not the actual loading). The difference is that applications don't have to re-load as often, and especially safari tabs stay open and do not require a reload as often. This helps usability tremendously.

 

The truth is, for as much as Apple charges for the iPhone 6/6+, they really should have included 2GB of RAM. Doesn't matter that iOS handles memory better than Android (or w/e). That is beside the point. Adding 2GB and keeping the same price would not have dramatically effected Apple's bottom line (IMHO) and it would have significantly improved the end user experience.

 

Edit: My SUV analogy had more to do with battery life than with RAM... but whatever.

[Noir Angel]

The FUD, and lack of technical knowledge displayed here really is utterly staggering.

 

Firstly, it's pretty much a known constant that Samsung load their devices to the gilt with bloatware. In simple terms they are not, and never will be an accurate measure of what kind of performance Android is capable of.

 

Secondly, the AOT compilation used in ART does produce native executables, which are no longer dependent on the Dalvik runtime. The APK files are still distributed as Java bytecode then compiled ahead of time to native machine code applications when they are installed. The junk collection algorithms in ART have also been improved which should result in reduced memory use for junk collection.

 

The information in this original post isn't sourced, it's not really explained that well, nor does the writer even come close to explaining his supposed testing methodology, and I have a theory: it's complete and utter crap. The idea that Android is using 8x as much memory for garbage collection makes absolutely no sense, the only way that could be possible would be if the initial amounts being used were so tiny that the difference is hard to notice. Android apps don't use staggering amounts of memory, the system doesn't either, it can all be explained by the fact that Android has a more advanced multitasking setup and requires more memory because it allows applications to install and run services. It's a simple design tradeoff, it's less memory efficient but allows for greater flexibility.

[Praetor]

any numbers for this?

 

http://lifehacker.com/android-art-vs-dalvik-runtimes-effect-on-battery-life-1507264545/all

 

ART, because it uses AOT compilation, improves the overall performance of Android devices. And still uses bytecode so it retains the flexibility of using the same APK in different Android devices, with different hardware.

[Draconian Guppy]

What's the difference between Android's "full-fledged" multitasking and Apple's "fake" multitasking?

 

 

The FUD, and lack of technical knowledge displayed here really is utterly staggering.

 

Firstly, it's pretty much a known constant that Samsung load their devices to the gilt with bloatware. In simple terms they are not, and never will be an accurate measure of what kind of performance Android is capable of.

 

Secondly, the AOT compilation used in ART does produce native executables, which are no longer dependent on the Dalvik runtime. The APK files are still distributed as Java bytecode then compiled ahead of time to native machine code applications when they are installed. The junk collection algorithms in ART have also been improved which should result in reduced memory use for junk collection.

 

The information in this original post isn't sourced, it's not really explained that well, nor does the writer even come close to explaining his supposed testing methodology, and I have a theory: it's complete and utter crap. The idea that Android is using 8x as much memory for garbage collection makes absolutely no sense, the only way that could be possible would be if the initial amounts being used were so tiny that the difference is hard to notice. Android apps don't use staggering amounts of memory, the system doesn't either, it can all be explained by the fact that Android has a more advanced multitasking setup and requires more memory because it allows applications to install and run services. It's a simple design tradeoff, it's less memory efficient but allows for greater flexibility.

See above and since you seem more knowledgeable, could you further insight us on this?

 

http://lifehacker.com/android-art-vs-dalvik-runtimes-effect-on-battery-life-1507264545/all

 

ART, because it uses AOT compilation, improves the overall performance of Android devices. And still uses bytecode so it retains the flexibility of using the same APK in different Android devices, with different hardware.

wow... %1 isn't much to write home about :/

[Praetor]

wow... %1 isn't much to write home about :/

 

It's more than that :p

 

This video shows a demo of both technologies:

https://www.youtube.com/watch?v=xgnZbdO4NV0

 

And that it's just using ART on Kitkat, where it's not the default nor optimized runtime. Also remember that most benchmark apps are using Dalvik, not ART.

 

I think it has great potential and will boost performance sky high, however it will take some time, of course.

[Noir Angel]

See above and since you seem more knowledgeable, could you further insight us on this?

 

The iPhone's multitasking setup is more limited. It doesn't let applications launch on boot and run as services, and when applications are left running in the background it just pauses them so that you can return to them when you want to (Granted, Android does that as well with apps that don't run as services), but because Android does let apps set and run services it's going to use a bit more memory.

[Draconian Guppy]

The iPhone's multitasking setup is more limited. It doesn't let applications launch on boot and run as services, and when applications are left running in the background it just pauses them so that you can return to them when you want to (Granted, Android does that as well with apps that don't run as services), but because Android does let apps set and run services it's going to use a bit more memory.

I think, I need to rephrase my statement...

 

To the end user, what is the difference between iphone and android multitasking? IMO iPhone does it better... IN my old iPhone 4. If I opened a video in safari and minimized it, it kept playing in the background, if I do that in android, it stops... Note, I have since become an android user, samsung galaxy s4  (never again sampus touchwizcrap) and now lg g3, so I don't root for either camp... just my 2 cents to further the discussion.

[Soldiers33]

My android is super smooth and its 2 years old. Where as my gf iphone has been slow since almost day 1. Ive never seen a fast and smooth iphone. The onlt ime is smooth is when you take it out brand new from the box.

[Noir Angel]

I think, I need to rephrase my statement...

 

To the end user, what is the difference between iphone and android multitasking? IMO iPhone does it better... IN my old iPhone 4. If I opened a video in safari and minimized it, it kept playing in the background, if I do that in android, it stops... Note, I have since become an android user, samsung galaxy s4  (never again sampus touchwizcrap) and now lg g3, so I don't root for either camp... just my 2 cents to further the discussion.

 

Applications running as background services do a variety of different things, for example the BBC app can run in the background and download articles, and deliver alerts when new articles get published (instead of just relying on push notifications). it also allows you to allow applications to sit there in the background and do things like automatically backing up files to your accounts, and it allows applications to deliver interactive alerts and notifications.

[Draconian Guppy]

Applications running as background services do a variety of different things, for example the BBC app can run in the background and download articles, and deliver alerts when new articles get published (instead of just relying on push notifications). it also allows you to allow applications to sit there in the background and do things like automatically backing up files to your accounts, and it allows applications to deliver interactive alerts and notifications.

Sorry, I don't mean to sound like an ass, I'm just trying to understand the difference.  But I see no difference from an app updating itself via push notificatications vrs running in the background? EG. Isn't the end result the same?

[adrynalyne]

The FUD, and lack of technical knowledge displayed here really is utterly staggering.

 

Firstly, it's pretty much a known constant that Samsung load their devices to the gilt with bloatware. In simple terms they are not, and never will be an accurate measure of what kind of performance Android is capable of.

 

Secondly, the AOT compilation used in ART does produce native executables, which are no longer dependent on the Dalvik runtime. The APK files are still distributed as Java bytecode then compiled ahead of time to native machine code applications when they are installed. The junk collection algorithms in ART have also been improved which should result in reduced memory use for junk collection.

 

The information in this original post isn't sourced, it's not really explained that well, nor does the writer even come close to explaining his supposed testing methodology, and I have a theory: it's complete and utter crap. The idea that Android is using 8x as much memory for garbage collection makes absolutely no sense, the only way that could be possible would be if the initial amounts being used were so tiny that the difference is hard to notice. Android apps don't use staggering amounts of memory, the system doesn't either, it can all be explained by the fact that Android has a more advanced multitasking setup and requires more memory because it allows applications to install and run services. It's a simple design tradeoff, it's less memory efficient but allows for greater flexibility.

You know what is funny?  You taking everything already being discussed and trying to pass it off as something new and somehow more correct.

 

/golfclap

[Noir Angel]

Sorry, I don't mean to sound like an ass, I'm just trying to understand the difference.  But I see no difference from an app updating itself via push notificatications vrs running in the background? EG. Isn't the end result the same?

 

Depends on the app, push notifications aren't capable of delivering the same level of advanced intereactive notification in most cases though. In fairness though I was over simplifying a bit as the functionality tends to differ depending on the app, for example you can get apps running in the background that can monitor performance, and perform tweaks to extend battery life, you can set things up that monitor system performance, memory usage, to change CPU scheduler settings, and so on. I'll try and dig for some better examples when I have a bit more time :)

You know what is funny?  You taking everything already being discussed and trying to pass it off as something new and somehow more correct.

 

/golfclap

 

Yep, almost as funny as you posting falsehoods and lies because you're an anti Google hipster.

[adrynalyne]

 

 

Yep, almost as funny as you posting falsehoods and lies because you're an anti Google hipster.

That is cute.  Simplezz and I already had this discussion and I stood corrected, but you seem to skim and not read.  Anti-Google hipseter is cute too...go Google my name sometime and see how anti-Google I am.

[Noir Angel]

That is cute.  Simplezz and I already had this discussion and I stood corrected, but you seem to skim and not read.  Anti-Google hipseter is cute too...go Google my name sometime and see how anti-Google I am.

 

You presented your opinions as facts without checking them, I stand by my assertion.

[adrynalyne]

You presented your opinions as facts without checking them, I stand by my assertion.

You re-presented yours without realizing they were already discussed and posted.  I am sure that you have never been wrong and been corrected, right?

 

Kudos to not reading first.

[Draconian Guppy]

That is cute.  Simplezz and I already had this discussion and I stood corrected, but you seem to skim and not read.  Anti-Google hipseter is cute too...go Google my name sometime and see how anti-Google I am.

Show off :P

 

adrynalyne Recognized Developer

Last Activity: 13th September 2014 05:55 PM

 

https://twitter.com/adrynalyne

http://adrynalyne.blogspot.com/

[adrynalyne]

 

Show off :p

 

adrynalyne Recognized Developer

Last Activity: 13th September 2014 05:55 PM

 

https://twitter.com/adrynalyne

http://adrynalyne.blogspot.com/

 

I'm in retirement . :)  Any development I do is in-house for the company I work for (and includes iOS occasionally too).

 

I certainly don't know it all, but I don't appreciate the anti-Google label.

[HawkMan]

JVM is true, but leaving it aside, which is obivious lead us to the other opinions

 

It doesn't usa a JVM it used a JVM like JIT compiler that read basically Java language, but not java... for copyright reasons.... 

 

but on never versions it doesn't use JIT and all apps are compiled on install and run natively anyway. even with JIT they basically ran natively so just because it's a java based JIT system doesn't make it non "native". 

[Draconian Guppy]

A little bit more on ART which I didn't know about:

 

 

 

 

ART?better performance, automatically, for free

It's not just the user-facing stuff that has gotten a revamp in Android 5.0. The under-the-hood components have seen an overhaul, too. While many parts of Android have changed over the years, one component from Android 1.0 that has survived to this day is Dalvik, the runtime that powers Android apps. Dalvik is a big part of what makes Android what it is. When you see projects that get Android apps running on another platform, likeBlackBerry 10 or Windows, those platforms are (mostly) implementing Dalvik.

 

Dalvik was originally designed for single-core, low-performance devices where fitting everything into small memory and storage pools was the primary concern. Over the years, Google has bolted on more and more upgrades to Dalvik, like JIT support, concurrent garbage collection, and multi-process support. Today's multi-core phones offer a 50x performance boost over the G1, though, and upgrades can only take you so far.

 

With Lollipop, Dalvik is dead. It's been replaced with a completely new runtime called "ART," the "Android RunTime." ART debuted in KitKat as an experimental option, but now in Lollipop it's the only option.

ART is written from the ground up to take advantage of modern smartphone hardware and provide smoother animations and longer battery life. Because the runtime is such a base component, ART offers an across-the-board performance improvement to Java apps without requiring the developer to do anything.

Dalvik used just-in-time (JIT) compilation, which compiled an app every time it was run. This is more portable than the alternative (ahead-of-time, or AOT, compilation), since JIT compilation has access to information about the hardware it is running on, it can be more aggressively optimized than traditional AOT compilation.

ART switches to AOT compilation, but rather than ship code that was compiled on the developer's computer, the Play Store ships uncompiled APKs, which are then compiled on the device at install time. This gives Android the best properties of JIT and AOT compiling. Since compilation happens on the device, ART gets the device-specific optimizations of JIT compiling, but since compilation only happens once, it gets the lower CPU usage of AOT compiling. The only downside is a longer install time for apps, since compilation has to happen before the app is installed. This only happens once, though, (and for each update install) so it's a very minor downside.

ART also brings lower memory usage and better multitasking on low-memory devices. Since Dalvik only compiled at runtime, the compiled code was never written to disk. It had to be kept in memory. In a low-memory situation, the process had to be killed and the compiled code was lost. If the user restarted the process, it needed to be recompiled again. This would lead to a lot of disk thrashing on low-memory devices, so much so that Google's recommendation for low memory devices was to disable JIT entirely.

Since ART is already compiled, the compiled code can be paged out to disk in a low-memory situation. This allows the OS to juggle apps in and out of memory without as much of a penalty as Dalvik.

Only one compilation per app should lead to better battery life with ART too, since you're not wasting CPU cycles repeating compilation work every time a program is run. The overall faster performance from ART will help with battery life, since faster code means less time feeding power to the processor and more time idling in a low-power mode.

ART is also better at memory allocation, which reduces the frequency of "jank"?animation stutters?compared to Dalvik. Android occasionally has to do "garbage collection"?basically cleaning and rearranging memory when something needs to load?and everything needs to come to a screeching halt while this is happening. ART has an entirely new garbage collector. It aims to make pauses shorter and less frequent, which should result in fewer dropped animation frames.

While ART does boost performance for most apps, it won't work for everything. There are two different ways to write Android apps: Developers can use the SDK, which will result in an app that runs on Android's runtime?first Dalvik and now ART?and uses Java code. There's also the NDK, which allows developers to write high-performance apps using less portable native code such as C and C++.

ART will only improve apps written in Java. Most benchmark apps are designed to test the hardware of a device, so they are written in native code and will mostly be unaffected by ART's performance boost. The same goes for 3D games and the rendering code of a browser. What ART can help are all the other apps on Android, including core stuff like the home screen, notification panel, Gmail, Maps, and the Play Store (really, any 2D app). Google estimates this to be 85 percent of apps on the Play Store.

With ART also comes the switch from 32 to 64-bit, which, in addition to more addressable memory, brings better performance from the 64-bit instruction set, particularly in media and cryptography apps. The best part is app support. While 32-bit apps will still run just fine, ART's on-device compiler can detect a 64-bit-capable device and compile apps for 64-bit, which, again, means instant improvements for 85% of apps with no developer work required. The remaining 15% of native apps will need to be recompiled by the developer to get these 64-bit improvements.

sauce:

 

http://arstechnica.com/gadgets/2014/11/android-5-0-lollipop-thoroughly-reviewed/3/#h2