Related
I don't think this quite merits a development thread so i'll just post it here.
How bloated is the Android OS?
The number one priority of a mobile phone has always been to keep the OS nice and "slim". Android is pretty good at this since it uses Linux (which is pretty slim compared to Windows/MacOS).
Windows Mobile is FAT. It's ridiculously bloated and as it's been around for so long it's just kind of accumulated mass like a rolling snowball. HTC and XDA do a great job of hiding it but you can just always tell.
The iPhone OS is shockingly bloated. They think 16GB and adequate specs give them an excuse but it's almost as bloated as WinMo and it only caters to ONE PHONE (two models now).
Surely the Java side to Android surely must bloat it, and something about it makes me think it is. Java is a bloated tool as it is, and it's useful for many reasons among dynamic compiling (I think), but it seems like they could have done a better job sticking to pure Linux. Looks at Maemo for example.
How does one answer how bloated a OS is?
My attempt: Android is NOT bloated
Antiskunk said:
I don't think this quite merits a development thread so i'll just post it here.
How bloated is the Android OS?
The number one priority of a mobile phone has always been to keep the OS nice and "slim". Android is pretty good at this since it uses Linux (which is pretty slim compared to Windows/MacOS).
Windows Mobile is FAT. It's ridiculously bloated and as it's been around for so long it's just kind of accumulated mass like a rolling snowball. HTC and XDA do a great job of hiding it but you can just always tell.
The iPhone OS is shockingly bloated. They think 16GB and adequate specs give them an excuse but it's almost as bloated as WinMo and it only caters to ONE PHONE (two models now).
Surely the Java side to Android surely must bloat it, and something about it makes me think it is. Java is a bloated tool as it is, and it's useful for many reasons among dynamic compiling (I think), but it seems like they could have done a better job sticking to pure Linux. Looks at Maemo for example.
Click to expand...
Click to collapse
What in the world do you mean by 'bloat'? You can't use such a subjective word so much without qualifying it with some sort of description.
lol yeah. Sometimes it just feels like there's excess, causing the OS to slow down unnecessarily.
For instance, android using java. It seems like it's a waste; causing over-use of the hardware, where something customised may reduce it.
Like Vista. Vista was bloated compared to xp, making it run much more slowly, despite having above-adequate hardware.
I suppose it's not true java, it is custom java, is it not?
I just feel sometimes it slows down when it shouldn't.
Don't get me wrong, it does an incredible job and I love it over any other OS.
Antiskunk said:
lol yeah. Sometimes it just feels like there's excess, causing the OS to slow down unnecessarily.
Click to expand...
Click to collapse
Bloat is a subjective term at best. And unecessarily? Everything is a tradeoff. Generally, especially without JIT, java based apps will not run as fast as a C based app. The tradeoff is in sandboxing, control, and ease of development. The question is whether the speed difference significantly impacts the user experience. It varies with the individual but I suspect most people would find the Nexus 1 to be sufficiently responsive.
Antiskunk said:
For instance, android using java. It seems like it's a waste; causing over-use of the hardware, where something customised may reduce it.
Click to expand...
Click to collapse
Clearly you have never tried to develop a complex system, much less an operating system. The vast majority of the time the CPU is barely used. The concept of "over-use of hardware" is not a well formed one. The question instead should be whether the infrastructure makes efficient use of the hardware. In real life you look at the infrastructure and make a balance as to what can be done to ease development and support while maintaining the sense of responsiveness for the end user.
Vista is an example where the balance was not weighted to match user expectation and thus all the complaints of "bloat." The N1 by comparison can not be said to be slow or unresponsive. Sure, it could be made faster, and chances are future releases will reflect that. This does not mean that the N1 is "bloated".
Antiskunk said:
Like Vista. Vista was bloated compared to xp, making it run much more slowly, despite having above-adequate hardware.
I suppose it's not true java, it is custom java, is it not?
Click to expand...
Click to collapse
Yes, Dalvik is a custom java bytecode format. Again a compromise for the memory and cpu found in an embedded device versus a full size computer.
Antiskunk said:
I just feel sometimes it slows down when it shouldn't.
Don't get me wrong, it does an incredible job and I love it over any other OS.
Click to expand...
Click to collapse
Don't take this personally but bloated is an annoying term used when people do not understand how to phrase "I want it faster." Bloat implies the removal of something unnecessary to make the system better.
What shall we remove from Android? Java/Dalvik? The entire platform is based on Dalvik, remove it and you are essentially starting over with your own set of compromises. Memory management? Can't remove it at all. Multitasking/background threads? Well here is something that can/does slow down the main system but for good reason. Commercial apps like Amazon MP3? Well they do not impact performance and are considered desirable by some.
So no, the N1 is not "bloated". It is a sum of parts to support a specified set of features and level of effort for development. Feel free to write your own platform though, or a custom ROM with the components you feel are unnecessary removed.
The work on JIT will likely improve speed a good deal, but that is not removing features; That is optimizing the platform, if we waited for the platform to be optimized it would never get released at all.
The op definately knows the defintion of bloated.
There's so much bloat infused into one post my brain slowed down trying to read it.
Yeah, it is really streamlined considering.
My main concern was really about the java side to it.
I guess it's just my experience with the difference between something like Vuze and uTorrent.
How much/well is it customised?
Just a blog re: ICS enabling full hardware acceleration of the GUI. We've all figured it would make our tablets sprint but this is putting things in a new light so I figured I'd post it here.
Linky
I'm sure the programmers and people on top of Android out there knew this. It sort of worries me though. Keeping in mind, Apple is running a totally different system - it sort of makes me respect iOS more so, to know that such a smooth system exists within the limits of 256MB of Memory when we're going upwards of 512MB and still having 'issues'. Don't jump down my throat, I don't want iOS (or an idevice), I'm just sayin'.
Jesus. I've known for a long time that there is something wrong with the way Android accelerates stuff and the whole UI design paradigm, but that's just boneheaded o_o That begs the question though: who made the decision to implement acceleration in such a horrible way and why wasn't it designed properly from the get-go? Anyone who has the slightest experience in OpenGL programming would've been able to tell them they're doing it wrong.
What a stunningly stupid way to implement things.
Just goes to show how much difference it really makes when it comes to having experience in OS development...
I like Android, but this design choice was just... dumb.
FloatingFatMan said:
What a stunningly stupid way to implement things.
Just goes to show how much difference it really makes when it comes to having experience in development...
I like Android, but this design choice was just... dumb.
Click to expand...
Click to collapse
Well, there are several shortcomings to Android exactly because of these kinds of brainfarts, like e.g. the permissions system is terribly sketchy and should've received a lot more Q/A. But now that it's released there's little Google can do about it without breaking compatibility as they didn't even plan for it to be extendable.
I do quite like Android, but it's too uneven to really feel professional or trustworthy. I just recently pondered about what I'd want from a future mobile tablet on my Google+ page and while I didn't mention it there, I feel like Win8 would've been in a terrific position for the OS on such a device if they didn't decide to remove traditional desktop from the ARM-version. I know Windows and Microsoft aren't popular here, but they've got a lot more experience with OS-development than Google and are a lot better at power-management design and acceleration of UI and its drivers, plus they've really put some real effort into security lately. Alas, with them scrapping traditional desktop from ARM-version Win8 won't cut it, either.
You guys should read Google's blog post. That article misses one huge point: the trade off. This was far from a bad implementation, it was just a very different one. If you read the article you would know that ios freezes if you hold your finger on screen while loading a large list, Android does not. Android balances the CPU threads for ui display and data processing somewhat equally, while ios grants utter priority to their ui display thread . Basically, if the ui display thread is busy, data processing stops. Android is the winner, it is ios that will now be limited in speed with this configuration until it is optimized for new hardware much like how Android currently works!
autom8r said:
You guys should read Google's blog post. That article misses one huge point: the trade off. This was far from a bad implementation, it was just a very different one. If you read the article you would know that ios freezes if you hold your finger on screen while loading a large list, Android does not. Android balances the CPU threads for ui display and data processing somewhat equally, while ios grants utter priority to their ui display thread . Basically, if the ui display thread is busy, data processing stops. Android is the winner, it is ios that will now be limited in speed with this configuration until it is optimized for new hardware much like how Android currently works!
Click to expand...
Click to collapse
Uh, it is a bad implementation. You can have both a good implementation AND still balance priority of both the rendering queue and application threads, they are not mutually exclusive.
WereCatf said:
Well, there are several shortcomings to Android exactly because of these kinds of brainfarts, like e.g. the permissions system is terribly sketchy and should've received a lot more Q/A. But now that it's released there's little Google can do about it without breaking compatibility as they didn't even plan for it to be extendable.
I do quite like Android, but it's too uneven to really feel professional or trustworthy. I just recently pondered about what I'd want from a future mobile tablet on my Google+ page and while I didn't mention it there, I feel like Win8 would've been in a terrific position for the OS on such a device if they didn't decide to remove traditional desktop from the ARM-version. I know Windows and Microsoft aren't popular here, but they've got a lot more experience with OS-development than Google and are a lot better at power-management design and acceleration of UI and its drivers, plus they've really put some real effort into security lately. Alas, with them scrapping traditional desktop from ARM-version Win8 won't cut it, either.
Click to expand...
Click to collapse
If Microsoft is dumb enough to kill desktop mode on ARM, that really destroys the Win8 tablet market outside of running on Intel chips, which puts them at sub-par graphics. I suppose the only hope then is if AMD steps in and I'm not all that much a fan of AMD, though they have tried to make good efforts in the mobile arena with their A-series chips and having decent GPUs.
I suppose I'll keep an eye on this and see what Microsoft does. Given their lack of intelligent decision making of late (ie. far dumber than their normal stupidity), I don't hold out much hope. Pity, Win8 tablets were looking strong, too.
Gnoop said:
If Microsoft is dumb enough to kill desktop mode on ARM, that really destroys the Win8 tablet market outside of running on Intel chips, which puts them at sub-par graphics. I suppose the only hope then is if AMD steps in and I'm not all that much a fan of AMD, though they have tried to make good efforts in the mobile arena with their A-series chips and having decent GPUs.
I suppose I'll keep an eye on this and see what Microsoft does. Given their lack of intelligent decision making of late (ie. far dumber than their normal stupidity), I don't hold out much hope. Pity, Win8 tablets were looking strong, too.
Click to expand...
Click to collapse
The Metro-interface is aimed for touch-based devices, including tablets. Desktop-mode doesn't work too well on such. The problem is that Win8 tablet could serve as BOTH a mobile device AND a desktop computer if Microsoft played its cards right and thus reserve a very nice spot for itself.
WereCatf said:
The Metro-interface is aimed for touch-based devices, including tablets. Desktop-mode doesn't work too well on such. The problem is that Win8 tablet could serve as BOTH a mobile device AND a desktop computer if Microsoft played its cards right and thus reserve a very nice spot for itself.
Click to expand...
Click to collapse
Indeed. Being able to handle both of those would hook me in pretty easily.
View the thread : http://forum.xda-developers.com/showthread.php?t=1400110
edit : link removed
Not true and ive posten respons in the original thread.
Yes, is TRUE
So says you.
that's what I say, but it is mostly what you hear with your ears and see with your eyes : http://forum.xda-developers.com/showthread.php?t=1400110
It's an issue with Android's sound system. More info here: code.google.com/p/android/issues/detail?id=3434
From the video, it appears that this relates to a particular app (mini piano), so in that case, I'm not sure why it's Google's responsibility to improve the responsiveness of a third party piece of software.
That said, there are some very basic reasons for why iOS will invariably be smoother and more responsive than Android almost 100% of the time.
Put simply, iOS and Android both began their respective development at totally different times. Android started development during a time when the market was saturated with keyboard-centric devices like Blackberry's and such. There wasn't a whole lot of touch-screen proliferation, and even then, those devices with touch screens were still very proprietary and basically none of them offered multi-touch. As such, Android was never originally designed for multi-touch screens; that kind of functionality is more of an evolutionary adaptation than anything else really. Android's core design principles focus on multi-tasking and cloud service connectivity in order to maximize productivity. That's why Android has always more effortlessly been good at both of those things.
iOS on the other hand was designed from ground up to be used on a multi-touch user interface. As such, iOS products have been more focused on being UI-centric, while other functions take a lower priority. Basically, when the user interacts with the screen of an iOS device, the system will drop everything it's doing (if need be) just to make sure that the UI runs smoothly. For example, say you try to interact with a webpage as it's loading on an iOS device. The device will actually stop loading the page, as long as you are touching the device to interact with it. As soon as you're no longer touching it, the page will continue to load. This is also why multi-tasking was more of an afterthought than a core principle with iOS. Apple could have easily implemented some form of multi-tasking right with their first iPhone, but considering the resource limitations at the time, that would have come at the cost of an interface that wouldn't have been as smooth or responsive.
So, to sum up:
Generally speaking, iOS will almost ALWAYS have a smoother and more responsive touch interface than Android has (unless Google basically rebuilds Android for touch screens from ground up).
That said, Android will almost ALWAYS be a better at multi-tasking and integrating cloud services than iOS (unless Apple decides to basically rebuild iOS from ground up with a bigger focus on those services).
Which is better than the other? Well, that's up to you really; it's totally subjective. If you want a simple to use UI which is smooth and responsive, then maybe iOS is better suited for you. If a more diverse ecosystem with endless customization options and very powerful multi-tasking beasts are important enough that you can accept a reasonable cost in the UI smoothness, then Android is your best bet.
Jade Eyed Wolf said:
From the video, it appears that this relates to a particular app (mini piano), so in that case, I'm not sure why it's Google's responsibility to improve the responsiveness of a third party piece of software.
That said, there are some very basic reasons for why iOS will invariably be smoother and more responsive than Android almost 100% of the time.
Put simply, iOS and Android both began their respective development at totally different times. Android started development during a time when the market was saturated with keyboard-centric devices like Blackberry's and such. There wasn't a whole lot of touch-screen proliferation, and even then, those devices with touch screens were still very proprietary and basically none of them offered multi-touch. As such, Android was never originally designed for multi-touch screens; that kind of functionality is more of an evolutionary adaptation than anything else really. Android's core design principles focus on multi-tasking and cloud service connectivity in order to maximize productivity. That's why Android has always more effortlessly been good at both of those things.
iOS on the other hand was designed from ground up to be used on a multi-touch user interface. As such, iOS products have been more focused on being UI-centric, while other functions take a lower priority. Basically, when the user interacts with the screen of an iOS device, the system will drop everything it's doing (if need be) just to make sure that the UI runs smoothly. For example, say you try to interact with a webpage as it's loading on an iOS device. The device will actually stop loading the page, as long as you are touching the device to interact with it. As soon as you're no longer touching it, the page will continue to load. This is also why multi-tasking was more of an afterthought than a core principle with iOS. Apple could have easily implemented some form of multi-tasking right with their first iPhone, but considering the resource limitations at the time, that would have come at the cost of an interface that wouldn't have been as smooth or responsive.
So, to sum up:
Generally speaking, iOS will almost ALWAYS have a smoother and more responsive touch interface than Android has (unless Google basically rebuilds Android for touch screens from ground up).
That said, Android will almost ALWAYS be a better at multi-tasking and integrating cloud services than iOS (unless Apple decides to basically rebuild iOS from ground up with a bigger focus on those services).
Which is better than the other? Well, that's up to you really; it's totally subjective. If you want a simple to use UI which is smooth and responsive, then maybe iOS is better suited for you. If a more diverse ecosystem with endless customization options and very powerful multi-tasking beasts are important enough that you can accept a reasonable cost in the UI smoothness, then Android is your best bet.
Click to expand...
Click to collapse
Dont forget to give credits to Andrew Munn as the source of your "reply"
which can be found here:
https://plus.google.com/100838276097451809262/posts/VDkV9XaJRGS
Also its not true that when you touch the screen on an iOS device every thing stops, at least not on my experience.. the page still continues to load, installation still continues and things still run in the background, simply put iOS has a better frame work for keeping 60fps on the UI at any given time, nothing is stopped or placed in real time as per several replies on that article.
I actually didn't know about this article. Thanks! Most of what I know comes from my Apple Fanboy friend, so we banter a lot. Maybe he read that article
There are still room for improvement for the touch interface. Hope it gets better on ICS update.
Jade Eyed Wolf said:
I actually didn't know about this article. Thanks! Most of what I know comes from my Apple Fanboy friend, so we banter a lot. Maybe he read that article
Click to expand...
Click to collapse
It just so happens your words are exactly as the same on the article, massive coincidence eh?
I think the problem does not come from the music software. This is a problem with Android. There are very large application vendors musical (korg, IK, etc ...) that have failed them porting iOS> Android OS as this has a level of latency too high for the "Touch games."
In searching I found very interesting articles about it and even a letter to Google:
http://www.musiquetactile.fr/android-is-far-behind-ios/
http://www.musiquetactile.fr/more-thoughts-on-audio-latency-in-android/
http://www.musiquetactile.fr/open-letter-to-google-improve-android-for-music/
Of course this relates to audio latency, but Android also suffers from a general latency. the touch of a AndroPhone is less reactive than an iPhone. This is the only thing I blame my rating Galaxy.
I'm just wondering, with all the top devices now being on ICS or JB, or having updates in the near future, is there a conscious effort from developers to start recoding their apps in native code to keep them fast, bugfree and light? And if not, what would it take, as an online community to try to get them to do so?
Now, I am not a dev so I realise that anything I say here may be inaccurate, but to the best of my knowledge:
Most android apps are currently programmed in HTML5 or Java, both of which are easy to port and run on all android versions with the power to run them, as they have some kind of virtual emulator to run them, but that means they bottle-neck the phone, they run slow, they force close, these scripts are often buggy and unstable and they don't run or look as good/well as they should. This was great in early days when phones were slow anyways so you wouldn't notice the difference, but iOS and Android (and perhaps WP7, Rim and Symbian) apps would all get the same update in a relatively close timeframe and all be almost the same. In the current world of ultraphones such as the S3, iPhone 5 and Lumia 920, regardless of how you feel about their manufactureres or firmwares, are all powerful and fast phones, all capable of running native coded apps on the latest firmware versions and they are kick-ass all round. Now, native coded apps, as far as I'm aware, no longer need to be emulated, there is no program running to handle them, they are being read as if part of the system itself, kind of a synthetic arm attached to a person rather than a robot being operated by remote control (???), and therefore are faster and more efficient and if coded well, stable.
Apps currently seem to be the bottle neck on my s3, I can make the phone speed through the internet like there's no tomorrow, but if I open, for argument's sake, the YouTube app, it takes 2 or 3 seconds to open. The Facebook app (yes, Suckerberg has confirmed a native app for Android similar to the native iOS app for this one) is still kind of slow though I think it isn't as bad as people say. Lots of apps crap-out and die or load much slower than they should when 4 cores are pumping pure mobile testosterone into them, so we really need the boost.
A lot of iOS apps are natively coded now, they load up so fast on the 4S, and they are more reliable, which is a shame, because for obvious reasons I love the S3 much more but I find myself still reaching for the 4S for certain actions because I know that the apps will be ready quicker and wont decide they've had enough and die half way through use.
What do you guys, many of whom know more about this kind of stuff than me, have to offer in terms of this subject or what are your opinions?
This is specifically development related how? Wrong section.
OP, Please read the rules about posting and the proper places to post.
If you need to revisit the rules the link is in my sig. Please do NOT post non development threads in the development section.
Thread moved to general
Sorry, my logic was that 3rd party apps talk was to p do with developers and development, my apologies.
So, any answers?
There is a very simple reason to use Java for apps - write once run anywhere. If apps were native then they would have to be recompiled for every phone. In the Apple world this is not such a big problem but in the Android world this would soon become impractical. Your view on native vs emulated is not correct and probably a relic from Java version 1.0. Native apps do not necessarily run faster than Java apps and in most cases there is not difference in speed. People make a lot of assumptions that because its a virtual machine that it will be slow. The Davlik VM uses highly optimised byte code and is simply not the case. Most Android apps are UI and I/O bound and not CPU bound so you will not see any performance improvements by making them native. You mentioned loading times. Most apps are Odexed to optimise loading so its as fast as possible. Also bear in mind that many CPU intensive tasks are often handed over to specific chips i.e. graphics is handed over to the GPU e.g. a native call to OpenGL will be the same speed as a Java call to OpenGL. Games are the most CPU intensive apps you get on a phone but Android provides hardware acceleration pipelines to handover the workload to the GPU and not the CPU. So for significant majority of applications you will not notice a speed difference between a Java app and a native app and this applies to many other platforms and not just Android phones. This is of course not true for the kernel. Since that has to deal with multiple apps all accessing resources possibly simultaneously then that has to be as fast as it possibly can be. This is why the kernel is native but all of the apps that sit on it are not. Since there are a limited number of kernels usually one per version of Android, each manufacturer has no trouble porting that since that's much easier than porting millions of apps.
Also, your assumptions that non Java code is bug free is also not true. Apps in C/C++ are just as likely to have bugs in as Java code. In some cases they are more likely because you don't have to worry about memory management in Java because of the Garbage Collector in the VM. It sounds like you experienced some poor performing apps but this will be to do with poor coding and not because its written in Java.
So deploying apps in native code would be a major headache when when testing and debugging on multiple hardware platforms and the unlikely speed benefits of native are likely to not be visible to the end user. We would not have the rich world of apps on Android and multiple Android hardware vendors that we do today if apps were native.
I hope this answers your query.
dodgebizkit said:
I'm just wondering, with all the top devices now being on ICS or JB, or having updates in the near future, is there a conscious effort from developers to start recoding their apps in native code to keep them fast, bugfree and light? And if not, what would it take, as an online community to try to get them to do so?
Now, I am not a dev so I realise that anything I say here may be inaccurate, but to the best of my knowledge:
Most android apps are currently programmed in HTML5 or Java, both of which are easy to port and run on all android versions with the power to run them, as they have some kind of virtual emulator to run them, but that means they bottle-neck the phone, they run slow, they force close, these scripts are often buggy and unstable and they don't run or look as good/well as they should. This was great in early days when phones were slow anyways so you wouldn't notice the difference, but iOS and Android (and perhaps WP7, Rim and Symbian) apps would all get the same update in a relatively close timeframe and all be almost the same. In the current world of ultraphones such as the S3, iPhone 5 and Lumia 920, regardless of how you feel about their manufactureres or firmwares, are all powerful and fast phones, all capable of running native coded apps on the latest firmware versions and they are kick-ass all round. Now, native coded apps, as far as I'm aware, no longer need to be emulated, there is no program running to handle them, they are being read as if part of the system itself, kind of a synthetic arm attached to a person rather than a robot being operated by remote control (???), and therefore are faster and more efficient and if coded well, stable.
Apps currently seem to be the bottle neck on my s3, I can make the phone speed through the internet like there's no tomorrow, but if I open, for argument's sake, the YouTube app, it takes 2 or 3 seconds to open. The Facebook app (yes, Suckerberg has confirmed a native app for Android similar to the native iOS app for this one) is still kind of slow though I think it isn't as bad as people say. Lots of apps crap-out and die or load much slower than they should when 4 cores are pumping pure mobile testosterone into them, so we really need the boost.
A lot of iOS apps are natively coded now, they load up so fast on the 4S, and they are more reliable, which is a shame, because for obvious reasons I love the S3 much more but I find myself still reaching for the 4S for certain actions because I know that the apps will be ready quicker and wont decide they've had enough and die half way through use.
What do you guys, many of whom know more about this kind of stuff than me, have to offer in terms of this subject or what are your opinions?
Click to expand...
Click to collapse
Amazing answer.
Sent from an electronic device.
If your reaching for your 4s you should be on medication....
Sent from my GT-I9300 using xda premium
I don't buy that "native apps need to be compiled many times so it's a major headache" argument. The compilation can be done as a part of the deployment to store process. Play store knows the phone it installs the app on so can substitute a right executable. It can all be done behind the scene. Linux is C++ and yet is deployed on many various platforms.
Google should rather encourage people writing native code for performance critical applications rather than discouraging it, what they are doing now. Things like launchers, maps, browsers should be native. Java is often a lot slower than c++. If you want to see this try comparing map rendering in native and java in OsmAnd for example.
Adittionally, apps performing fast drain proportionally less battery, as they use less cpu cycles to do the same job. This is an important factor on mobile phones.
I've been professionally coding for 13 years both in c++ and java and have a good clue what I talk about. Also java coders tend to be less organized than c++ ones, which can explain the fact that we see more fc's on android than crashes on windows. A friend of mine likes telling "java is a language for programmers who cannot program".
"Smartphone is no longer a phone"
ahacker said:
Also java coders tend to be less organized than c++ ones, which can explain the fact that we see more fc's on android than crashes on windows. A friend of mine likes telling "java is a language for programmers who cannot program".
Click to expand...
Click to collapse
I call troll.
If you'd been a professional developer for 13 years you would know full well that both those statements are utter tosh.
Geoff (professional developer - not java - for 17 years)
Sent from my GT-I9300 using xda app-developers app
ahacker said:
Linux is C++ and yet is deployed on many various platforms.
Click to expand...
Click to collapse
If by "Linux", you mean the kernel then no. Linux is written in C. The GNU coreutils are also C. (Though the GCC people do want to make GCC a C++ program. But I digress.)
Sent from my GT-I9300 using Tapatalk 2
If you do raw speed benchmark tests to CPU intensive apps then a compiled app will always beat a VM app. Benchmarks do vary widely based on the type of benchmark and what compiler optimisations you turn on. This adds a complexity to your idea of letting the Play Store do the compilation. As a developer I'd hate to be in the situation that my compiled app worked fine on my phone and emulator but didn't work when compiled by the play store. How would you debug that? However despite native being faster the speed benefits are almost entirely hidden in most apps because they are interacting with the user, downloading from the web or offloading to the GPU. In my last mail I didn't even touch on security. Using a VM is a very neat way to give an app a limited security sandbox which is very secure.
I think you're maybe being a little harsh on Java programmers. You get good and bad programmers in any language. I think the reality is with a language as open as Java you get more "have a go" programmers which can result in some very dodgy apps on the Play Store. However, the developers of the core Android apps do not fall into this category and its the core apps that we really care about here.
I myself have over 20 years experience coding an Java, C/C++ and a variety of different platforms but rather than descend into a Java vs C++ war and focus back on the original question. The efficiency gains using native are not enough to warrant having to support native apps. If they were, a tech savy firm like Google would have done it. I think the security, support and deployment advantages far outweigh the performance gains for most applications. Sure there would some parts of a few apps that may benefit from the optimisation that native would provide but to facilitate native development Google would have to provide two APIs. Instead Google has ONE platform for all apps, theirs and everyone else's which is very sensible. If Google had to support a native API and a Java API then the doubles the support and development work which would increase time to market and increase cost. For a commercial company the right solution is always a balance between the right technical solution and practicality and cost considerations.
Marsbar said:
I call troll.
Click to expand...
Click to collapse
I call an aggressive idiot, who instead of arguing against my points attacks me personally.
"Smartphone is no longer a phone"
ahacker said:
I call an aggressive idiot, who instead of arguing against my points attacks me personally.
Click to expand...
Click to collapse
If you really think that was a personal attack you have some issues.
To come to a developers forum that is likely to have a high proportion of java developers and say that about them is a troll, pure and simple. If you want to prove otherwise then make an argument that makes any sort of sense.
Quality developers develop quality code whatever language they use. I've worked on quality codebases in VB6 of all things and I've worked on C++ from supposed professionals that made my brain spin from the mess.
Sent from my GT-I9300 using xda app-developers app
Then what is the advantage of native coding?
dodgebizkit said:
Then what is the advantage of native coding?
Click to expand...
Click to collapse
These days, when the majority of app time is io and memory bound and when things like graphic manipulation is handled by the graphics chips or (failing that) by tightly optimized native libraries, far less than you might think, especially since dalvik (the android jvm) comes with a just-in-time compiler that effectively turns java bytecode into native code. Any advantage there might be is rarely worth the extra development time required.
People like Mozilla are perhaps the exception in that they have a huge amount of investment in legacy code that would cost a fortune to redevelop. But for a new app, there's little obvious advantage.
Sent from my GT-I9300 using xda app-developers app
This is just so annoying.
I was playing a game on FPSE during the lunch break. At 13:30, back to work, did not have the opportunity to save my game. Nevermind, I just put the telephone on screen saver / lock screen so that I can continue later, after the work.
...
...
...
Meanwhile I received a text. Fine, I can read it and possibly answer to it... Android is supposed to hadle multitask rather well after all.
...
...
...
Pwned.
After texting, back to FPSE, just to check and make sure that it's still on... Just to notice that the app has been killed by Android...
This is sooo annoying. It's supposed to be mobile phone specialized in gaming. You should be able to interrupt your game to answer a call or a message!!!
I previously owned a Nokia N8 Powered by Symbian^3. It was much much more efficient. Could lauch many apps without worrying of the multitaking. Apps where running in the background, not simply killed by the OS...
Any similar experience to share guys? (or solution, but I doubt there is any...)
What you are experiencing is the brilliant idea of putting a small amount of ram into a android gaming phone (well thought out, Sony). When the ram is low and another app needs to use that ram, Android will automatically kill another app to claim free ram. The problem Android has is it uses Java as the base programming language. The problem with Java is it is a resource hog and totally steals as much ram as possible...see the problem yet? Also, the problem Sony has is that they are stupid.
And now for the reasons. Google choose Java as the base because of its popularity and ease of use for noobs at programming, which is also why there are so many bad apps in the Google Market compared to the iphone. While this was a smart choice for Google at the time to help accelerate their market growth to help catch up with the ios market, it's now a problem they'll always have as a consequence to that choice. To counter this problem of having a horrible base program language android phones constantly needs to have ridiculous specs in order to have comparable performance to the iphone (quad core, gig of ram, phones anyone?).
So there you have it, the core and unavoidable problem with Android. An operating system so inefficient that it warrants quad cores with close to pc specs (That is amazingly bad). So bad that they must've been really high when the folks at Sony thought it was a good idea that a GAMING phone would only need a single core with crap ram. Well played.
So what you are saying is, the entire Android platform is garbage because you made that decision with a garbage phone? Try multitasking on the SG3, then come back. Or, go deal with the fake multitasking of iOS.
you can try supercharger, n use multitasking choice, that's the best multitasking option that i ever try, altough it will makes your free RAM under 70 MB, but multitasking is very great....
DubleJayJ said:
So what you are saying is, the entire Android platform is garbage because you made that decision with a garbage phone? Try multitasking on the SG3, then come back. Or, go deal with the fake multitasking of iOS.
Click to expand...
Click to collapse
All I'm saying is Android is inefficient. This is generally known and Google has been constantly criticized because of it. Going back to my point, this is why manufactures are pushing out quads on their phones.
@cityhunter62
@coreyon
So, why are you even here?
narflynn619 said:
@cityhunter62
@coreyon
So, why are you even here?
Click to expand...
Click to collapse
I provided information on the problem...? I think a better question would be why are YOU here? You didn't provide anything on this thread.
just wonder if V6 supercharger bulletproof app might help?
Tje great thing about android is that normally there is an app for whatevet you need or a flashable zip or a script ect so it just takes a quick search and abitta time and you could be tip top and there's allways the quick save feature in fpse
Sent from my R800i using xda app-developers app
narflynn619 said:
@cityhunter62
@coreyon
So, why are you even here?
Click to expand...
Click to collapse
Coreyon answered to my question and I thank him for that. Now I understand why multitasking does not work on Android, or at least on Android phones with few ram. Still, N8 had 256mb ram but handled multitasking perfectly.
Anyway, mathacer and foryou168 gave some advices that might be helpful. I had some answers, that was the point of this thread...
I'm sure I'm not the only one who experienced that kind of problem...
coreyon said:
All I'm saying is Android is inefficient. This is generally known and Google has been constantly criticized because of it. Going back to my point, this is why manufactures are pushing out quads on their phones.
Click to expand...
Click to collapse
Inefficient because it ran out of RAM? OEM's are pushing for quads because the software and Linux foundation is the most advanced out there. No other mobile is has such supreme multitasking and such a myriad of emulation apps.
Enable zRAM or use a swap partition if you expect this low-RAM device to keep a 32-bit-era console emulator in the background while doing phone functions.
Or get a tablet for gaming. Its still just a smartphone dude.
Or get an iPhone.
Or learn development and help the "horrible android" to be better.
Sent from Xperia Play (R800a) with Tapatalk
Just don't say that android is rubbish,.. it's awesome.. And it's open.. we can customize our phone to our need... that's make it different..
Sent from my GT-I9100 using xda premium
Android is insufficient, but on my Galaxy S3 samsungs multitasking is absolutely terrible for 1GB, but now once I flashed the Multitaskingfix I have to say its like multitasking on a 2GB android device, I love it! and in the latest leak (with Multi view, etc) XXELK4 4.1.2 the ram used is almost half of what is used on 4.1.1, Love you samsung! can't say that about Sony, but Xperia play will always be with me until I get use to Touch screen gaming.
For everyone that somehow got offended when I said Android is inefficient, please read on. Android IS inefficient, but that does not mean it's a bad operating system. I personally use it myself. It's certainly better than ios with Apples lockdown. The great positives of Android is that it uses the Linux kernel which is very advanced, and the entire operating system itself is very customizable (partly thanks to java it self).
Now with that said, like I've mentioned I don't know how many times now, it will always have a problem as apps and games become more and more advanced; there will always be the new apps that pushes the hardware to a new level and with the Android overhead will cause it to be slower than it could be. A good example of this is how Minecraft (with its amazingly bad graphics) on the PC needs Crysis-like specs to play with good fps on a PC. That's ridiculous, and it's because the game runs in Java. I know there is Minecraft for Android, but let's be honest it's a very very small map that barely has any of the pc gameplay, otherwise the phone would explode. However, just like Android, even with Minecraft's horrible lag issues it is still an awesome game, and is very easy to customize the game which is also very awesome. Does everyone understand my point now?
CosmicDan said:
Or learn development and help the "horrible android" to be better.
Click to expand...
Click to collapse
I AM a developer, and I have had the pleasure of struggling with Java's limitation on a multiple array of platforms. I do know what I'm talking about, it's a well known issue.
I'm personally suprised Java is still alive
Thought it would have died years ago because java programs would be slow as molasses/bog down any PC.
So I'm surprised it actually runs decently on phones... tho the phones are more powerful than PCs from a few years ago lol
And yeah, its' the same old cycle.
Software always gets bloated as hardware specs increase so it's tough to get ahead - kinda like how inflation negates pay raises
coreyon said:
I AM a developer, and I have had the pleasure of struggling with Java's limitation on a multiple array of platforms. I do know what I'm talking about, it's a well known issue.
Click to expand...
Click to collapse
I can agree from my experience with Java software, especially the security concerns. I heard a saying: hell is a world where Java is the only programming language. I'm more annoyed by Google trying to do things different and separating itself from Linux standard.
I have to say you are very lucky to present your thoughts here, if this was a Nexus forum all hell would break loose. The Nexus fanboys are relentless.
Sent from my Galaxy Nexus
eksasol said:
I can agree from my experience with Java software, especially the security concerns. I heard a saying: hell is a world where Java is the only programming language. I'm more annoyed by Google trying to do things different and separating itself from Linux standard.
I have to say you are very lucky to present your thoughts here, if this was a Nexus forum all hell would break loose. The Nexus fanboys are relentless.
Sent from my Galaxy Nexus
Click to expand...
Click to collapse
Aha, I should've made a thread for this. This went way off topic from the original purpose of the thread.
JAVA OS?
I thought IOS apps were Java also?
Either way, they have similar "multitasking", except that the programmer can control how an Android app "moves through the states" (ie. from pause when its in background to being killed) so if the FPSE programmers took advantage of the power of Android OS, they could have set the game to do a save as it was killed...
In fact, Android AUTOMATICALLY dumps some of the programs memory when killed involuntarily (the OS needs more RAM) so really, all the programmer needs to do is check to see if there is a bundle already there when the programs oncreate() is (re)called - if so, then resume!
developer[dot]android[dot]com/training/basics/activity-lifecycle/recreating.html
For the record I hate Java, and more so - ECLIPSE (Java IDE that was also itself made in Java) makes me want to shoot myself in the face whilst listening to Enya and letting spiders crawl on my testicles.
Hicsy said:
I thought IOS apps were Java also?
Either way, they have similar "multitasking", except that the programmer can control how an Android app "moves through the states" (ie. from pause when its in background to being killed) so if the FPSE programmers took advantage of the power of Android OS, they could have set the game to do a save as it was killed...
In fact, Android AUTOMATICALLY dumps some of the programs memory when killed involuntarily (the OS needs more RAM) so really, all the programmer needs to do is check to see if there is a bundle already there when the programs oncreate() is (re)called - if so, then resume!
developer[dot]android[dot]com/training/basics/activity-lifecycle/recreating.html
For the record I hate Java, and more so - ECLIPSE (Java IDE that was also itself made in Java) makes me want to shoot myself in the face whilst listening to Enya and letting spiders crawl on my testicles.
Click to expand...
Click to collapse
I don't touch ios even with a 50 foot pole, but I'm pretty sure ios apps don't use Java. Even if they did, the core operating system doesn't, and that's enough to make a huge impact difference in performance.
I heard about some developer porting Android to C+. By passing all those legal issues with Microsoft, if Android ran on C+ wouldn't it fix all the lag much like Project Butter has and evidently fixed the incredible RAM usage by the device?