Why is Android app optimisation still so poor?

[SlCKB0Y]

Fragmentation.

Too many different resolutions, cpu, and graphics chips running their own custom version of Android.

Do you understand the design decision as to why Google specifically chose to use Dalvik VM and how it relates to your above criticism?

----------

I love how everyone on here is either a developer or knows a developer. Also amusing how all the developers dont like coding for Android .

I know! There are more than 700,000 Android Apps and based on what is said here all the time, they must have coded themselves because no developers are willing to do it!

 

[Cod3rror]

This is due to several fundamental design choices, including (but not limited to):

• Native code (iOS) vs common use of Java (Android)
• Manual/compiler assisted Memory management (iOS) vs Garbage Collection (Android)
• Highly optimized for a small number of devices (iOS) vs generic code for wide deployment

The memory management is a big one - on iOS, the programmer decides when memory should be allocated/cleaned up. On Android, the java virtual machine decides when to do garbage collection in the background - which may not be the best time to do it (e.g., in the middle of scrolling the UI, for example).

The brute force approach to alleviate that is to throw faster hardware at the problem.

But, same hardware running iOS / some other non-GC native code will be faster/smoother.


The above is why you can't directly compare specs between the devices - because the software stack is so different. Different design choices were made and there is a different set of trade-offs for both platforms.

iOS memory management used to be hard for the programmer (tradeoff being made for speed). With ARC support in Objective-C / later versions of iOS, they have helped alleviate that.

Android memory management used to cause stuttering, etc at run time. They have improved that via hardware and software updates.

Thanks for an insightful reply.

However, this begs another question. Can Google actually do something to remedy the above listed problems without having to completely recode Android, which, I'm guessing is simply not feasible.

 

[TheHateMachine]

I've heard from a Dev for both iOS and Android and he said Android is a nightmare. Mainly due to resolution.

You should go read a little bit about the differences in the ways iOS and Android handle different resolutions. Should enlighten you as to why resolution is not a problem.

 

[SlCKB0Y]

Can Google actually do something to remedy the above listed problems without having to completely recode Android, which, I'm guessing is simply not feasible.

Maybe read some of that users post history to get an idea of their agenda against Android.

Also notice how they only stated their opinion of things they consider to be design issues in Android from a theoretical standpoint without actually providing any specific real-world examples of the manifestation of these "issues"?

 

[Fernandez21]

I'm no programmer, so correct me if I'm wrong, but I wonder if it has anything to do with the APIs. I've noticed on android that the apps are more functional due to less restrictions but don't perform as well as on iOS. It could be because of that, maybe they're using resources from the CPU or something that the OS needs and causes that?

 

[Rodimus Prime]

Thanks for an insightful reply.

However, this begs another question. Can Google actually do something to remedy the above listed problems without having to completely recode Android, which, I'm guessing is simply not feasible.

Just going to point out the poster you looked at is anti android and most of that post is pretty full of FUD. He has been ripped apart multiple times over for the BS and repeating things that are just plan wrong.

 

[SlCKB0Y]

You should go read a little bit about the differences in the ways iOS and Android handle different resolutions. Should enlighten you as to why resolution is not a problem.

The resolution one is great. It's very telling when this is brought up as anyone who has taken more than just a passing glance at Android will understand how the scaling of apps to different resolutions is handled very gracefully.

Then there are those who mindlessly regurgitate the resolution fragmentation FUD.

----------

I'm no programmer, so correct me if I'm wrong, but I wonder if it has anything to do with the APIs. I've noticed on android that the apps are more functional due to less restrictions but don't perform as well as on iOS.

I don't think this is completely true. I'd argue that a well coded Android App performs just as well as it's iOS counterpart.

What I think is that the greater freedom and access provided to Android applications has the flipside of making it much easier to code a bad App which can affect overall system performance.

Note that this is no different to how things are under Windows or OS X, except those Apps have even greater access and therefore a greater potential to cause performance issues.

Basically Android is less "idiot proof" and this places more of an onus on the end user to be selective about what apps to use... again, no different to desktop OS's.

 

[throAU]

There is just so much wrong with your post and clearly a lot of ignorance and FUD.

Sources? Otherwise, it's just your random babbling on here vs. mine.

My sources - you know, just some of the millions of pages and print written on the subject:
http://stackoverflow.com/questions/6385285/why-doesnt-ios-have-automatic-garbage-collection

http://www.levelofindirection.com/journal/2010/8/13/we-dont-need-no-stinking-garbage-collection.html

http://www.drdobbs.com/mobile/automatic-reference-counting-on-ios/240000820

Oh, and how about the official apple documentation on memory management. Doesn't seem very much like "don't do manual memory management, leave it to the OS!" to me. Because the OS doesn't do it for you entirely at all.

http://developer.apple.com/library/...onceptual/MemoryMgmt/Articles/MemoryMgmt.html


Amongst plenty of others, if you have bothered to read any iOS development documentation, reviews of the developer kit, or actually learn to code for iOS, etc. There are entire chapters devoted to iOS memory management in objective-c - rather than "don't do manual memory management".

Garbage collection is expensive. Which is why apple doesn't do it on iOS (it was briefly supported in Xcode for OS X, but it is recommended you switch to ARC now). It is a big reason why Apple have been pushing the clang/llvm compiler toolchain, which enabled them to develop ARC to get most of the GC benefits without the performance cost.

Which is one reason why iOS runs better on similar spec/lower spec hardware.

But hey, apple don't innovate at all, right?

And i did not say there is ZERO native code on android. However, java is common. Whether or not a particular game is in java or not, a lot of the OS and background running apps probably are.

http://developer.android.com/guide/components/fundamentals.html


But hey, just spew "FUD!! FUD!!" because someone has said things you don't like about your sacred cow.

I've provided some references to back up my points, where the hell are yours?

Seems to me, the only FUD here is yours.



----------

Thanks for an insightful reply.

However, this begs another question. Can Google actually do something to remedy the above listed problems without having to completely recode Android, which, I'm guessing is simply not feasible.

As hardware advances, the penalties for Garbage collection and the JVM will likely decrease. As RAM costs come down, the penalty for JVM overhead will become less relevant.

They already have a highly optimised JVM (davlik) to try and alleviate these "problems" but they aren't really due to bad code or anything like that, they are just a different set of design trade-offs.

Apple demands apps be written in Objective-C along with all the issues associated with that in order to get better performance from less hardware.

Android provides the JVM to gain platform independence (no reason you can't have an x86 android phone, or MIPS or whatever, so long as the platform has a JVM all your java-based apps will run on it without even a re-compile), but loses a little performance (both due to running non-native bytecode, and the garbage collection Java does) to gain that flexibility.

Basically Android is less "idiot proof" and this places more of an onus on the end user to be selective about what apps to use... again, no different to desktop OS's.

On the contrary, the need to do manual memory management via retain/release on iOS and programming in Objective-C is a lot less "idiot proof" than being able to write apps in Java which eliminates things like pointers which cause application crashes when the programmer screws up.

ARC in recent versions fixes that to an extent - which i would wager is why there's still no jailbreak for iOS 6 out yet - because the code is being migrated from retain/release to ARC and less prone to exploitable bugs.

 

[Rodimus Prime]

Sources? Otherwise, it's just your random babbling on here vs. mine.

My sources - you know, just some of the millions of pages and print written on the subject:
http://stackoverflow.com/questions/6385285/why-doesnt-ios-have-automatic-garbage-collection

http://www.levelofindirection.com/journal/2010/8/13/we-dont-need-no-stinking-garbage-collection.html

http://www.drdobbs.com/mobile/automatic-reference-counting-on-ios/240000820


Amongst plenty of others, if you have bothered to read any iOS development documentation, reviews of the developer kit, etc. There are entire chapters devoted to iOS memory management in objective-c - rather than "don't do manual memory management".

Garbage collection is expensive. Which is why apple doesn't do it on iOS (it was briefly supported in Xcode for OS X, but it is recommended you switch to ARC now). Which is one reason why iOS runs better on similar spec/lower spec hardware.

?

Source 1 and 2 are both invalided and out dated. Source 3 dances around the term but iOS does have it. Manual managing memory is just asking for problems and memory leaks. Mix that with the fact iOS likes to kill processes that use to much and is very limiting on what it lets you have. It has made the group I work with have to do some pretty fancy and quite frankly stupid things to get around them when we do need a large chunk of memory to hold a lot of data. Android is a lot nicer and as such we are not dealing with those crash bugs and to honest the memories ones are the biggest pain in the rear to track down and generally speaking it requires some guess work on what the cause could be.

Manually managing memory and having to do it is considered bad practice these days.

 

[throAU]

Source 1 and 2 are both invalided and out dated. Source 3 dances around the term but iOS does have it.

...

Manually managing memory and having to do it is considered bad practice these days.

Why are those sources invalidated? Because you say so?

You still have not provided a single source of your own.

iOS does not have GC and never has. OS X / objective C has it, but it was not included in iOS.

ARC is something entirely different, and until that was included in iOS 5, the only way you could initialize objects and destroy them in iOS was via the retain/release mechanism.

Yes, manual memory management is awkward, but is higher performance when you get it right. Because the programmer KNOWS when the phone is going to burn CPU to alloc/dealloc objects, because it is when he told it to. With garbage collection, the OS does it when it feels like it, and the running app has no control over that. The app could be in the middle of some time-critical operation, and the OS steals the CPU to go do its GC. Causing it to lag.

This isn't an android specific problem, it is a fundamental characteristic of garbage collection.

Which is why Apple toyed with GC in OS X (only, they never enabled it in iOS), before they developed ARC. Prior to that, memory management, as you say was a major pain in the backside on iOS.

ARC provides the same performance as manual memory management without the complexity for the programmer - the compiler takes care of it at compile time, not RUN TIME like GC (which costs CPU).

Manually managing memory and having to do it is considered bad practice these days.

You are completely and utterly wrong with regards to iOS with this statement, as shown in multiple links, including the official iOS developer documentation linked above.

 

[djshack]

It comes down to a simple fundamental OS difference: Essentially, iOS prioritizes the current process (i.e., the game you're playing) and freezes most background processes. Android truly multitasks, so there are likely other processes using CPU power in the background.

I'm not a programmer or engineer, but this is what I've learned in the past years from looking up the same problem. Android has true multitasking which is both a blessing and a curse. iOS doesn't. Until phone hardware improves with better battery life, the iOS way seems to prevail.

 

[throAU]

It comes down to a simple fundamental OS difference: Essentially, iOS prioritizes the current process (i.e., the game you're playing) and freezes most background processes. Android truly multitasks, so there are likely other processes using CPU power in the background.

Exactly, and that is another example.


Apple focused on making the app the user is interacting with perform as smoothly as possible, at the cost of flexibility.

Android went for flexibility instead.


As both evolve, you'll see the line begin to blur.



edit:
official memory management policy for cocoa

http://developer.apple.com/library/...es.html#//apple_ref/doc/uid/20000994-BAJHFBGH


And yes, i am a hobbyist/starting out OS X / iOS app developer. I've written a heap of C previously before (unix - a mud), but it has been a few years.





And for full disclosure: my "agenda against android" is personal preference. And yes, it is AGAINST android for ME because of the following:


Full background: my job is to support enterprise users in a business environment.

In this setting, android is going to be a nightmare. No single platform, ability for users to install whatever app they want from wherever they want. No app curation. No standard form factor or screen size for any apps that we may develop in house.

Yes, you can lock the phones down to an extent, but if the user roots it, all bets are off. Apple are attempting to lock the jailbreak scene down, and even without locking the devices down with a profile manager, they are inherently locked down to an extent by apple themselves.

In my environment, we want a standard, across the board UI. We want vetted apps to avoid malware. We want standard form factors.

We DON'T want to be dealing with a user on the other end of the phone who has busted their phone or is trying to get support out of the corporate helpdesk for one of a million different email programs, etc.


If they want to run android at home - fine. We don't want to spend the additional resources to officially support it on the corporate network at this time.



All that said, performance comments made are without bias. I have plenty of other reasons to dislike android and don't need to make stuff up regarding performance to justify it. Don't care if android is 2x as fast as iOS, still do not want due to reasons above. And i could have one on monday if I wanted for "free", as my phones are work-paid and I'm one of the team who steer purchasing decisions. A couple of our team are currently running Android handsets (S3 from memory).

It is clear from the design choices google made with android that outright application performance was very much secondary to the priority of being cross-platform. And there's nothing inherently wrong with that.

But if someone is wondering why this is, then I'm going to attempt to explain it.

 

[knucklehead]

Quote:
Originally Posted by Cod3rror
I agree.

I don't know what's iOS secret but it's just incredibly fluid and smooth, list scrolling on iOS is amazing. Even when iOS is lagging, it still is somehow smooth.

Android, while it may not lag, it just does not have the same fluidity and smoothness, something is off about it.

Something is "off" about Apple disciples

Right now, I have this thread open in Tapatalk on both an iPad 3 and Nexus 4. The Nexus 4's scrolling certainly isn't terrible, but no one with any sense at all would confuse it for being as fluid or smooth as the iPad 3.

Edit: Ooops, I ment to type Nexus 7. I opened the the same thing in Tapatalk on the Nexus 4, and that is about as smooth as on the iPad.

 

[The iGentleman]

And for full disclosure: my "agenda against android" is personal preference. And yes, it is AGAINST android for ME because of the following:


Full background: my job is to support enterprise users in a business environment.

In this setting, android is going to be a nightmare. No single platform, ability for users to install whatever app they want from wherever they want. No app curation. No standard form factor or screen size for any apps that we may develop in house.

Yes, you can lock the phones down to an extent, but if the user roots it, all bets are off. Apple are attempting to lock the jailbreak scene down, and even without locking the devices down with a profile manager, they are inherently locked down to an extent by apple themselves.

In my environment, we want a standard, across the board UI. We want vetted apps to avoid malware. We want standard form factors.

We DON'T want to be dealing with a user on the other end of the phone who has busted their phone or is trying to get support out of the corporate helpdesk for one of a million different email programs, etc.


If they want to run android at home - fine. We don't want to spend the additional resources to officially support it on the corporate network at this time.

Question...why is it that Android is secure enough to be used in the corporate environment at Google (which I'm sure houses much more sensitive information than your company), yet you can't seem to get it deployed securely due to the reasons you stated. Are you not familiar with Device Policy? What is it that is being done at Google that you don't know how to do?

 

[TacticalDesire]

I'm no programmer, so correct me if I'm wrong, but I wonder if it has anything to do with the APIs. I've noticed on android that the apps are more functional due to less restrictions but don't perform as well as on iOS. It could be because of that, maybe they're using resources from the CPU or something that the OS needs and causes that?

Many apps aren't doing any more than what they do on iOS. In Android they just let the user know what they're doing.

 

[RetepNamenots]

I've heard from a Dev for both iOS and Android and he said Android is a nightmare. Mainly due to resolution.

Sure, designing for a fixed set of resolutions is going to be easier than a for a fluid layout, just like it is when designing for the web.

But I can't think I've ever had a problem with Android where apps appear stretched, or have black bars, etc.

 

[blackhand1001]

Just have to point this out to you - the difference is less than 20 PPI, and the Tegra 3 has a weaker graphics chip than the A5. Yep.

Just wanted to point that out to you.

Um actually the difference is way more than 20ppi. The ipad mini is 163ppi vs 216ppi for the nexus 7. Thats a 63ppi difference.

----------

I've heard from a Dev for both iOS and Android and he said Android is a nightmare. Mainly due to resolution.

Its only a nightmare if you approach developing it from the ios mindset. AKA absolute coordinate layouts and using ios like UI paradigms. If you actually approach it using the android holo UI and layout system its actually incredibly easy and you don't even need to worry about resolution. That dev is obviously trying to make cheap iOS port apps and not real android apps which are very easy to make.

 

[Rodimus Prime]

Its only a nightmare if you approach developing it from the ios mindset. AKA absolute coordinate layouts and using ios like UI paradigms. If you actually approach it using the android holo UI and layout system its actually incredibly easy and you don't even need to worry about resolution. That dev is obviously trying to make cheap iOS port apps and not real android apps which are very easy to make.

To be fair there are something in in Android that are a nightmare to do and a cake walk in iOS for UI but on the flip side there are things in iOS UI that are a complete nightmare to do but a cake walk to do in iOS.
One example is I had some scrolling issue with a view that was on top of a view and how I needed stuff to move. Android cake walk to do. iOS required some rather massive work around to make it work. Hell the official solution from apple is something they say never to do and breaks many of their own design standards but that how Apple in their own documentation tell you to do it. Some of those issues are still causing use some pretty big head aches while the android version are pretty easy.

Sum it up each OS has their own set head aches and problems.

 

[iHailCarlo]

No matter how the Android fanboys try to spin it or make it like its some complete feature packed OS, its just the same unstable resource hog its always been. Thats why the phones always slow down to a crawl and get laggy after 4-5 months.

 

[The iGentleman]

No matter how the Android fanboys try to spin it or make it like its some complete feature packed OS, its just the same unstable resource hog its always been. Thats why the phones always slow down to a crawl and get laggy after 4-5 months.

Interesting...my Galaxy S3 before I sold it had an uptime of just about 6 months. In other words, it hadn't had a reboot in almost half a year. No crashing, no problems...sounds like stability to me. My Galaxy Nexus was the same way also. Also I experienced no slow downs AT ALL. Simply put, you're spewing nonsense.

 

[SlCKB0Y]

Apple focused on making the app the user is interacting with perform as smoothly as possible, at the cost of flexibility.

Android went for flexibility instead.

As both evolve, you'll see the line begin to blur.

Given the massive performance gains of Android 4.2, Google is already blurring this line and strangely enough, they didn't increase this performance by altering any of the design decisions that you consider to be problematic. Strange.

Apple is yet to significantly increase flexibility.

And for full disclosure: my "agenda against android" is personal preference. And yes, it is AGAINST android for ME because of the following:

Full background: my job is to support enterprise users in a business environment.

In this setting, android is going to be a nightmare. No single platform, ability for users to install whatever app they want from wherever they want. No app curation. No standard form factor or screen size for any apps that we may develop in house.

Translation:

"I dislike Android due to perceived theoretical issues I have with design decisions made by the Android team. I haven't yet given concrete examples of these issues manifesting themselves as real world problems.

My company hasn't yet deployed Android, but this doesn't stop me from hating it because in the hypothetical situation that my employer does use this technology and the criticisms I have of it's design do actually cause real-world problems, this might make my job harder.

And yes, i am a hobbyist/starting out OS X...developer

How? How on earth did you manage this? Why, you'd have to be designing your apps with a ridiculous range of hardware in mind. From 1GB of RAM to 64GB, from 11" MBA screens to 60" TV's. From Core duo's to dual hex Xeons.

Oh, wait, this is exactly what desktop developers have been doing for the last 3 decades. You know, designing for a range of hardware permutations (even though Android has way less variance of hardware than desktops).

Now suddenly, when Apple users need something to criticise Android with, this issue is suddenly an insurmountable problem. Convenient.

----------

Its only a nightmare if you approach developing it from the ios mindset. AKA absolute coordinate layouts and using ios like UI paradigms. If you actually approach it using the android holo UI and layout system its actually incredibly easy and you don't even need to worry about resolution.

This is precisely the point. Android Apps tend to scale to different screen resolutions very gracefully because Google was aware that Apps would be run across a variety of resolutions and built in mechanisms to allow this to be achieved.

To contrast this see how an iPhone app scales to being on an iPad. It doesn't.

 

[iHailCarlo]

Interesting...my Galaxy S3 before I sold it had an uptime of just about 6 months. In other words, it hadn't had a reboot in almost half a year. No crashing, no problems...sounds like stability to me. My Galaxy Nexus was the same way also. Also I experienced no slow downs AT ALL. Simply put, you're spewing nonsense.

Whatever you say, keep lying to yourself for the sake of forum board popularity.

 

[SlCKB0Y]

Whatever you say, keep lying to yourself for the sake of forum board popularity.

The user was commenting on this "contribution" from you:

No matter how the Android fanboys try to spin it or make it like its some complete feature packed OS, its just the same unstable resource hog its always been. Thats why the phones always slow down to a crawl and get laggy after 4-5 months.

Seeing as the post they were commenting on is devoid of facts, is completely unsupported by any sources and basically represents the inflammatory opinions made by an extremely biased person, I reckon they can say anything they want.

If this is the extent of your contribution then welcome to my ignore list.

 

[iHailCarlo]

The user was commenting on this "contribution" from you:



Seeing as the post they were commenting on is devoid of facts, is completely unsupported by any sources and basically represents the inflammatory opinions made by an extremely biased person, I reckon they can say anything they want.

If this is the extent of your contribution then welcome to my ignore list.

He is speaking of his personal experience as am I, does that validate or invalidate either way? I think you are a touch confused or just touched.

 

[3bs]

He is speaking of his personal experience as am I, does that validate or invalidate either way? I think you are a touch confused or just touched.

You said he's lying. How is he lying when he's talking about his experience on his devices? And how do you know he's lying? Why accuse him of trying to be popular (on an Apple forum btw) when he was just stating he hasn't had any of the issues you mentioned?