Its called caching. Fifos. Schedulers...etc.... all classically implement MRU algorithms for various purposes. All of which are the building blocks of just about every significant computer technology. They don't have to know your exact usage to provide value. They need only be close enough. The simple fact is, its doubtful even you know your usage pattern, if there is one at all. As such, its equally a good guess that most recently used (MRU) applications and/or services are also good candidates to remain cached.
Ever use a shortcut on Android? Very probable you just benefited from MRU caching. Want to take a picture and then review your pictures? Same thing...so on and so on...
themselves to intelligently save state and handle random termination gracefully is hardly "almost every facet of modern computing."
You're looking at the specific - look to the abstract, which is absolutely topical. After all, MRU caching is exactly what's being stepped on here. Not exactly hard to figure out.
Yet some of the more reasonably behaved ones managed it. As a previous poster mentioned pandora is one such app, the *oid series of emulators all have a perfectly functioning quite option.
Meaningless.
Indeed, and being forced into this should carry the same stigma as the linux oom process killer. If it goes that far something has gone wrng.
Learn to read. Then comprehend what you read. That's the way it is. Period. End of discussion. Get that into your head. Android has absolute control over application and service lifecycles - not the other way around. As part of the released guidelines, developers should be terminating their unneeded services - and that's the abuse. The same is not true for activities.
The primary problem is abuse of services, not missing menu items from activities. I've already stated what needs to be done about those. It doesn't change the fact that Android has 100% control over application life cycles - not the other way around. Period. Get that into your head! Service abuse places additional memory pressures which frequently causes thrashing of activities and services. The fact that services are abused is not proof that the android life cycle is broken, and in no way suggests that adding a useless menu item is a solution. Despite abusive services, Android's life cycle still works well.
Search Google's developer groups. There you'll find various benchmark statements as well as benchmarks referring to the anticipated, initial Dalvik JIT implementation. Some of these also come from the NDK groups - which make the need for the NDK obvious.
The fact that the parent post was modded down does wonders to highlight the mental dysfunction that is seemingly common with the current generation. Such moderating screams that either the moderator is a completely idiot or they failed to read the entire post. Either way, negative moderation of the parent post is trolling at best.
Also, the Police are a lot less likely to "catch and release" these days, so back in the day a kid could actually break the law a bit and they were treated like kids testing their boundaries, nowadays a kid with joint is a potential high school blood bath.
That's exactly the point. These days kids are not only willing to push far beyond what "common sense" says is absolutely idiotic, but police are far, far less likely to be understanding and dismiss it as, "kids being kids - no body got hurt."
An adult telling you that getting hit by a car is bad, don't let it happen, really should be all that's required. That should be the end of it - but not with many of this current generation.
Also - not everyone seems to have this problem but I will tell you all right now my phone does a hell of a lot better without any kind of task/app killer than with it.
Its hard to prove a negative. Your anecdotal evidence is a far cry from proving a negative. Especially since part of the problem is that people often state not everyone is experiencing the issue.
Also, having it kill it self doesn't necessarily fix the issue as the system will naturally restart the associated service.
This is nonsense and verging on asinine. I don't mean that as a personal insult as you did mention this is in google's guidelines, but no automatic app manager no matter how advanced knows enough about how I use my phone and how the apps I use function to successfully perform its role.
This statement is contrary to almost every facet of modern computing. And almost without fail, those who take your position are wrong.
Not only are there issues of badly behaving apps draining battery when not terminated, but there are issues of apps with persistent roles sch as internet radio, remote terminals, download managers, badly behaving websites with non-interruptible multi page operations, etc.
We were not broadly talking about badly behaving apps - though there are some. In this case, users should either contact the developer and report it as a bug or report it to google as a malicious app. The problem here is, most users are clueless as to the lifecycles of applications and they would almost always be wrong in their reports.
The only likely place you can nail an application is when you see a service running when its application has been terminated and you know for a fact that the application should not be performing background tasks. That's surprisingly common.
Asking for an extra menu entry to quit an application is not too much to ask. The few lines of code it'd require would fit in the tail end of an unfilled memory page. Don't give me any nonsense about compounding memory pressure. If I hit back or home fine, stay up. If I hit menu > quit then by all means terminate.
Yes, I know, it highlights that you don't know what you're talking about. There are only two or three ways to immediately terminate an Android application and none are recommended. Some provide negative feedback to the user, further annoying them. Even when a developer requests an application to be terminated Android is free not do so, or to do so on a deferred basis. In fact, its not terribly uncommon for deferred termination to take place; only after Android decided another application needed the memory. As such, providing a menu item to terminate an application accomplishes exactly nothing - other than take up additional memory. When Android decides it needs more memory it will terminate applications as it sees fit. That's the end of it, no matter how much you want to complain.
My number one complaint for Android applications is, if the application creates a persistent service and it does not provide a means to terminate the persistent service, that's bad.
My number two complaint is, if an application starts at boot and fails to provide a means to disable auto start on boot, I consider that to be very poorly written. I should not have to spend lots of extra time at boot to start all these applications which I rarely run and do not provide real value by starting at boot.
If you want to see significant battery life improvements, look at trying WiSyncPlus. Unlike Advanced Task Killer, you won't have trouble finding people recommending that app.
Bother to do some quick searches. You won't have trouble finding many recommending to uninstall the application so as to drastically improve battery life. And it makes absolutely sense. You can't get the information without polling the system.
It's true that I can recompile the OS and raise the memory limit.
I never said that. That would silly. I said check to see if the limits can be determined at run time so you can allow for larger limits, if you so wish. Otherwise, you'll be forced to only support the L.C.D.
In practice, is the amount of available ram actually higher than 16M on most platforms? I haven't bothered to check what my droid returns for ActivityManager.getMemoryClass(), and I don't have a HTC or any other Android phones. As a practical matter, am I over-constraining myself by limiting myself to just 16 megs?
I left that as an exercise for the reader as I don't know the answer my self. What I do now is that 16MB is likely not a fixed limit across all phones. And even if it is currently a limit across all phones it likely won't be over the next year or so as new hardware is introduced. So being adaptive may be a strategic advantage.
I agree. If Parents would just stop worrying and let us make mistakes, things would be a lot better for us. We learn by making mistakes, not by parents trying to prevent every little thing from happening. It's a bit cold outside. So what? I'm not going to die.
The problem is, too many kids run around with this misconception. And when they make that mistake from which they've *maybe* learned from, mommy and daddy have to come behind and pay thousands of dollars to keep little Johny out of jail and/or prison - or worse. In the end, its often the parents and/or the rest of the family that suffers from the broken, "let us make our own mistakes", mentality.
Ultimately, you can't help but look at some of the kids that run around with this broken mentality as, "how stupid are you?" Some things you just shouldn't have to learn first hand unless you have a serious mental disability. Obviously, people do need to learn from their own mistakes - but that has limits which seems to be beyond comprehension of so many young these days.
Generally Android's java is very optimized and is terrific and surprisingly fast
I have no idea where you get this impression. Android's dalvik engine is widely known to be roughly 20x slower than most other non-JIT'd java VMs. Its slow by any measure. And worse, most CPU intensive tasks which are commonly required for many mobile applications fall into a category where performance is especially poor for the current Dalvik implementation.
The good news is that Android's Dalvik will soon have its initial JIT offering which will speed up applications, on average, roughly 100%-150%. Once readily available, Dalvik will be 10x-500x slower than native code; depending on the nature of the code.
Apps only get to use 16 megs of memory on Android.
That's actually not true. That's a hardware manufacturer's limit and can vary from device to device. Android itself places no such constraint on application memory. The limit is set on a per hardware basis.
From a programmer's perspective, that likely means supporting the lowest common denominator, which is entirely a different issue. Though pragmatically for you, that hardly makes a difference.
You might check and see if the limits are accessible at runtime which will allow you more adaptive flexibility in your applications.
Granted, it doesn't chew battery, but it's a cleanness thing. They should be playing by the rules.
They absolutely ARE playing by the rules. You just don't know/understand the rules.
Most android apps don't, even Google-provided software. The Exchange calendar client continuously starts up even though I don't have a calendar configured.
Unused applications are services are terminated by the system. Unused memory is a waste. The Android framework is in charge of all application and service life cycles.
Really the only problem is that many developers are abusing services when they should be requesting the service be terminated. Or worse, they are starting the service as a persistent service rather than an on-demand service. Both of which are application bugs. Regardless of the bug, the framework still manages the service lifecycle, which is why these abusive developers don't fix their bugs.
The problem with that is that I might want to have music playing while I do other things like webbrowsing.
That's why the framework supports priorities. Background tasks are automatically assigned a lower priority. Tasks which play music, etc., should be assigned the corresponding priority so that it reacts accordingly to priority changes. The framework already accounts for all this; assuming the developer is properly using the framework.
The people who think HP is what makes a car go and don't even know what "torque means" are making the error of only looking at PEAK horsepower.
That's exactly right!
Another problem is people always assume more low end torque is better but fail to understand that too much torque causes wheel spin. Wheel spin wasted energy....but wheel spin can also be a safeguard to prevent component breakage elsewhere in the drive train...
I can't tell you how many Car And Driver readers I just want to slap the crap out of because all they understand is peak HP and falsely believe that tells the whole story. Even worse, they tend to flaunt their superior ignorance. Its sad, funny, and frustrating.
It's a problem with developers, and it annoys the piss out of me.
Then you are annoyed by developers following Google's guidelines. The sole exception is that many developers are abusing (incorrectly using) services but even then the OS takes care of it.
There are a precious few apps that actually completely close when you hit menu -> quit. Most don't, and many even lack a quit command altogether.
That's because a quit button or menu item doesn't actually do anything. As such, most developers don't waste space and memory adding a feature which only serves to compound memory pressures.
I get tired of having to run a task manager to manually kill each app after I'm done using it.
That's because the system will re-use the memory as it sees fit. Generally speaking, its vastly smarter than any user at doing so. The notion is, a cached application provides for a better user experience. By killing applications you require the system to reload it from flash. In short, you are actually making the system slower and actively working against Android's entire design.
Fire up something like advanced task killer and see what your memory utilization is like. He has a point, getting an app to "close" in the sense that it's not running and not hogging memory is a problem with Android.
The entire point of applications like Advanced Task Killer is to free up memory. But it entirely defeats the purpose as it is itself an application consuming memory. Plus, the application kills battery power like its going out of style because it constantly polls to obtain process lists and per process information. Add in the fact that many users break applications by using it means that most developers absolutely hate the application because it generates bugs reports wasting endless developer time.
That specific application has widely been dubbed, "Advanced Battery Killer." Who would think that an application constantly polling in the background, consuming CPU, and using scarce memory would be an absolutely waste...lol...
Thankfully many savvy users are finally realizing that the task killer applications are as much a waste of battery life as they are a waste of dollars. In short, these types of applications prey on the ignorance of the masses and are completely counter productive while being the bane of other developers.
There is a reason diesel train engines have been replaced by diesel-electric hybrids or electric-only train engines - that diesel engines do not have enough low-end torque.
Actually its because the transmissions were becoming massive, adding huge amounts of weight and requiring yet another series of parts to be maintained. The solution was to replace the transmission with a series of electric motors and use the diesel as a generator. Electric motors have excellent low end torque and in doing so, they've increased the longevity of the diesel engine while saving considerable weight and maintenance.
Gasoline engines don't have low end torque, but that doesn't matter at all.
Unless your objective is to start something moving.
Most car guys have it pounded into them that HP is what matters. HP absolutely does not matter. Its torque that matters. Comparing HP between two unlike engines is a true sign of ignorance. What good is an engine which makes 10,000HP if it takes a month to come to full power? Its not good for anything. Torque is what matters. If you know the torque curve, you can calculate the HP at any given RPM.
There is a reason why diesel has been slowly displacing gas engines in many motor sports over the last decade. Even aviation has been trying to get diesels into the air.
History shows companies who aggressively advertise during economic slow downs are drastically more likely to make it out the other side far more successful then those who didn't.
Slashdot Mirror
How so? Do you have examples?
Its called caching. Fifos. Schedulers...etc.... all classically implement MRU algorithms for various purposes. All of which are the building blocks of just about every significant computer technology. They don't have to know your exact usage to provide value. They need only be close enough. The simple fact is, its doubtful even you know your usage pattern, if there is one at all. As such, its equally a good guess that most recently used (MRU) applications and/or services are also good candidates to remain cached.
Ever use a shortcut on Android? Very probable you just benefited from MRU caching. Want to take a picture and then review your pictures? Same thing...so on and so on...
themselves to intelligently save state and handle random termination gracefully is hardly "almost every facet of modern computing."
You're looking at the specific - look to the abstract, which is absolutely topical. After all, MRU caching is exactly what's being stepped on here. Not exactly hard to figure out.
Yet some of the more reasonably behaved ones managed it. As a previous poster mentioned pandora is one such app, the *oid series of emulators all have a perfectly functioning quite option.
Meaningless.
Indeed, and being forced into this should carry the same stigma as the linux oom process killer. If it goes that far something has gone wrng.
Learn to read. Then comprehend what you read. That's the way it is. Period. End of discussion. Get that into your head. Android has absolute control over application and service lifecycles - not the other way around. As part of the released guidelines, developers should be terminating their unneeded services - and that's the abuse. The same is not true for activities.
The primary problem is abuse of services, not missing menu items from activities. I've already stated what needs to be done about those. It doesn't change the fact that Android has 100% control over application life cycles - not the other way around. Period. Get that into your head! Service abuse places additional memory pressures which frequently causes thrashing of activities and services. The fact that services are abused is not proof that the android life cycle is broken, and in no way suggests that adding a useless menu item is a solution. Despite abusive services, Android's life cycle still works well.
Search Google's developer groups. There you'll find various benchmark statements as well as benchmarks referring to the anticipated, initial Dalvik JIT implementation. Some of these also come from the NDK groups - which make the need for the NDK obvious.
The fact that the parent post was modded down does wonders to highlight the mental dysfunction that is seemingly common with the current generation. Such moderating screams that either the moderator is a completely idiot or they failed to read the entire post. Either way, negative moderation of the parent post is trolling at best.
Also, the Police are a lot less likely to "catch and release" these days, so back in the day a kid could actually break the law a bit and they were treated like kids testing their boundaries, nowadays a kid with joint is a potential high school blood bath.
That's exactly the point. These days kids are not only willing to push far beyond what "common sense" says is absolutely idiotic, but police are far, far less likely to be understanding and dismiss it as, "kids being kids - no body got hurt."
An adult telling you that getting hit by a car is bad, don't let it happen, really should be all that's required. That should be the end of it - but not with many of this current generation.
From the provided link:
Also - not everyone seems to have this problem but I will tell you all right now my phone does a hell of a lot better without any kind of task/app killer than with it.
Its hard to prove a negative. Your anecdotal evidence is a far cry from proving a negative. Especially since part of the problem is that people often state not everyone is experiencing the issue.
Also, having it kill it self doesn't necessarily fix the issue as the system will naturally restart the associated service.
This is nonsense and verging on asinine. I don't mean that as a personal insult as you did mention this is in google's guidelines, but no automatic app manager no matter how advanced knows enough about how I use my phone and how the apps I use function to successfully perform its role.
This statement is contrary to almost every facet of modern computing. And almost without fail, those who take your position are wrong.
Not only are there issues of badly behaving apps draining battery when not terminated, but there are issues of apps with persistent roles sch as internet radio, remote terminals, download managers, badly behaving websites with non-interruptible multi page operations, etc.
We were not broadly talking about badly behaving apps - though there are some. In this case, users should either contact the developer and report it as a bug or report it to google as a malicious app. The problem here is, most users are clueless as to the lifecycles of applications and they would almost always be wrong in their reports.
The only likely place you can nail an application is when you see a service running when its application has been terminated and you know for a fact that the application should not be performing background tasks. That's surprisingly common.
Asking for an extra menu entry to quit an application is not too much to ask. The few lines of code it'd require would fit in the tail end of an unfilled memory page. Don't give me any nonsense about compounding memory pressure. If I hit back or home fine, stay up. If I hit menu > quit then by all means terminate.
Yes, I know, it highlights that you don't know what you're talking about. There are only two or three ways to immediately terminate an Android application and none are recommended. Some provide negative feedback to the user, further annoying them. Even when a developer requests an application to be terminated Android is free not do so, or to do so on a deferred basis. In fact, its not terribly uncommon for deferred termination to take place; only after Android decided another application needed the memory. As such, providing a menu item to terminate an application accomplishes exactly nothing - other than take up additional memory. When Android decides it needs more memory it will terminate applications as it sees fit. That's the end of it, no matter how much you want to complain.
My number one complaint for Android applications is, if the application creates a persistent service and it does not provide a means to terminate the persistent service, that's bad.
My number two complaint is, if an application starts at boot and fails to provide a means to disable auto start on boot, I consider that to be very poorly written. I should not have to spend lots of extra time at boot to start all these applications which I rarely run and do not provide real value by starting at boot.
Opps...
I hosed the last link...
If you want to see significant battery life improvements, look at trying WiSyncPlus. Unlike Advanced Task Killer, you won't have trouble finding people recommending that app.
So now I'm an accountant?
Bother to do some quick searches. You won't have trouble finding many recommending to uninstall the application so as to drastically improve battery life. And it makes absolutely sense. You can't get the information without polling the system.
This is just one example which was very hastily found via Google.
If you want to see significant battery life improvements, look at trying
That's the difference between, "fast enough" and, "surprisingly fast".
I never said Dalvik wasn't "fast enough" for many simple applications. Otherwise Android would be DOA.
So it's better to coddle and pamper our kids 'til they're 18 and then toss them out into the world to survive on their own?
I never said anything even remote close to your assertion.
It's true that I can recompile the OS and raise the memory limit.
I never said that. That would silly. I said check to see if the limits can be determined at run time so you can allow for larger limits, if you so wish. Otherwise, you'll be forced to only support the L.C.D.
In practice, is the amount of available ram actually higher than 16M on most platforms? I haven't bothered to check what my droid returns for ActivityManager.getMemoryClass(), and I don't have a HTC or any other Android phones. As a practical matter, am I over-constraining myself by limiting myself to just 16 megs?
I left that as an exercise for the reader as I don't know the answer my self. What I do now is that 16MB is likely not a fixed limit across all phones. And even if it is currently a limit across all phones it likely won't be over the next year or so as new hardware is introduced. So being adaptive may be a strategic advantage.
I agree. If Parents would just stop worrying and let us make mistakes, things would be a lot better for us. We learn by making mistakes, not by parents trying to prevent every little thing from happening. It's a bit cold outside. So what? I'm not going to die.
The problem is, too many kids run around with this misconception. And when they make that mistake from which they've *maybe* learned from, mommy and daddy have to come behind and pay thousands of dollars to keep little Johny out of jail and/or prison - or worse. In the end, its often the parents and/or the rest of the family that suffers from the broken, "let us make our own mistakes", mentality.
Ultimately, you can't help but look at some of the kids that run around with this broken mentality as, "how stupid are you?" Some things you just shouldn't have to learn first hand unless you have a serious mental disability. Obviously, people do need to learn from their own mistakes - but that has limits which seems to be beyond comprehension of so many young these days.
Generally Android's java is very optimized and is terrific and surprisingly fast
I have no idea where you get this impression. Android's dalvik engine is widely known to be roughly 20x slower than most other non-JIT'd java VMs. Its slow by any measure. And worse, most CPU intensive tasks which are commonly required for many mobile applications fall into a category where performance is especially poor for the current Dalvik implementation.
The good news is that Android's Dalvik will soon have its initial JIT offering which will speed up applications, on average, roughly 100%-150%. Once readily available, Dalvik will be 10x-500x slower than native code; depending on the nature of the code.
Apps only get to use 16 megs of memory on Android.
That's actually not true. That's a hardware manufacturer's limit and can vary from device to device. Android itself places no such constraint on application memory. The limit is set on a per hardware basis.
From a programmer's perspective, that likely means supporting the lowest common denominator, which is entirely a different issue. Though pragmatically for you, that hardly makes a difference.
You might check and see if the limits are accessible at runtime which will allow you more adaptive flexibility in your applications.
Granted, it doesn't chew battery, but it's a cleanness thing. They should be playing by the rules.
They absolutely ARE playing by the rules. You just don't know/understand the rules.
Most android apps don't, even Google-provided software. The Exchange calendar client continuously starts up even though I don't have a calendar configured.
Unused applications are services are terminated by the system. Unused memory is a waste. The Android framework is in charge of all application and service life cycles.
Really the only problem is that many developers are abusing services when they should be requesting the service be terminated. Or worse, they are starting the service as a persistent service rather than an on-demand service. Both of which are application bugs. Regardless of the bug, the framework still manages the service lifecycle, which is why these abusive developers don't fix their bugs.
Actually, this is a developer sin.
Actually its not.
Why Task Killer is for ignorant fools... ....and why you're fighting Android...
The problem with that is that I might want to have music playing while I do other things like webbrowsing.
That's why the framework supports priorities. Background tasks are automatically assigned a lower priority. Tasks which play music, etc., should be assigned the corresponding priority so that it reacts accordingly to priority changes. The framework already accounts for all this; assuming the developer is properly using the framework.
Simplicity is hard.
We have a winner!
Can't tell you how many times I've run into coders who believe complex = elegance. Or even worse, terse, cryptic coding is elegant.
Simplicity is its own reward - and a bonus for the developer who follows.
The people who think HP is what makes a car go and don't even know what "torque means" are making the error of only looking at PEAK horsepower.
That's exactly right!
Another problem is people always assume more low end torque is better but fail to understand that too much torque causes wheel spin. Wheel spin wasted energy....but wheel spin can also be a safeguard to prevent component breakage elsewhere in the drive train...
I can't tell you how many Car And Driver readers I just want to slap the crap out of because all they understand is peak HP and falsely believe that tells the whole story. Even worse, they tend to flaunt their superior ignorance. Its sad, funny, and frustrating.
It's a problem with developers, and it annoys the piss out of me.
Then you are annoyed by developers following Google's guidelines. The sole exception is that many developers are abusing (incorrectly using) services but even then the OS takes care of it.
There are a precious few apps that actually completely close when you hit menu -> quit. Most don't, and many even lack a quit command altogether.
That's because a quit button or menu item doesn't actually do anything. As such, most developers don't waste space and memory adding a feature which only serves to compound memory pressures.
I get tired of having to run a task manager to manually kill each app after I'm done using it.
That's because the system will re-use the memory as it sees fit. Generally speaking, its vastly smarter than any user at doing so. The notion is, a cached application provides for a better user experience. By killing applications you require the system to reload it from flash. In short, you are actually making the system slower and actively working against Android's entire design.
Fire up something like advanced task killer and see what your memory utilization is like. He has a point, getting an app to "close" in the sense that it's not running and not hogging memory is a problem with Android.
The entire point of applications like Advanced Task Killer is to free up memory. But it entirely defeats the purpose as it is itself an application consuming memory. Plus, the application kills battery power like its going out of style because it constantly polls to obtain process lists and per process information. Add in the fact that many users break applications by using it means that most developers absolutely hate the application because it generates bugs reports wasting endless developer time.
That specific application has widely been dubbed, "Advanced Battery Killer." Who would think that an application constantly polling in the background, consuming CPU, and using scarce memory would be an absolutely waste...lol...
Thankfully many savvy users are finally realizing that the task killer applications are as much a waste of battery life as they are a waste of dollars. In short, these types of applications prey on the ignorance of the masses and are completely counter productive while being the bane of other developers.
There is a reason diesel train engines have been replaced by diesel-electric hybrids or electric-only train engines - that diesel engines do not have enough low-end torque.
Actually its because the transmissions were becoming massive, adding huge amounts of weight and requiring yet another series of parts to be maintained. The solution was to replace the transmission with a series of electric motors and use the diesel as a generator. Electric motors have excellent low end torque and in doing so, they've increased the longevity of the diesel engine while saving considerable weight and maintenance.
The biggest reason he gives while this is bad is because it destroys then recreates an activity upon rotating the screen
That's the default. The behavior can be overridden such that the activity is not destroyed and recreated.
Gasoline engines don't have low end torque, but that doesn't matter at all.
Unless your objective is to start something moving.
Most car guys have it pounded into them that HP is what matters. HP absolutely does not matter. Its torque that matters. Comparing HP between two unlike engines is a true sign of ignorance. What good is an engine which makes 10,000HP if it takes a month to come to full power? Its not good for anything. Torque is what matters. If you know the torque curve, you can calculate the HP at any given RPM.
There is a reason why diesel has been slowly displacing gas engines in many motor sports over the last decade. Even aviation has been trying to get diesels into the air.
History shows companies who aggressively advertise during economic slow downs are drastically more likely to make it out the other side far more successful then those who didn't.