Quote:
Originally Posted by S_U_N ^
@joslics: I still feel that if an application (e.g. browser) is used and then kept running in the background, it might still be a much better option to exit an unneeded application cleanly rather than keep it running till the next time you reboot it or using task manager to forcibly kill it. |
Since you dont want to bother opening that link, I'll copy-paste relevant info here:
So comes the first myth:
if you open many apps in Android there will be not enough of memory for hungry software and the phone will work much slower.
There is a bit of truth in the statement, but do not forget the nuances. All applications for Android are made of
modules, in other words an app contains many independent elements (unless they are connected with another module). The presence of the app in the memory does not mean it is fully used at the moment. It may be idle and
not executing any code. It is located in the memory to ensure the next operation is started faster from the
cache. When the memory is needed to other apps the least important modules will be unloaded in accordance with the system of priorities. The same concept of dumping is used in WP7. In this case task managers are harmful, because they unload apps, which have to be loaded again soon, which slows down the process.
The presence of the app in memory does not slow down the phone automatically. It is pointless to free the memory only to boost this parameter.
There is no smoke without fire and I will try to explain why.
This section is slightly too technical and describes the architecture of apps for Android. I would like to tell about the internal structure for readers to get a clear picture of the OS.
In Android all modules are divided into three main types:
- Activity
- Broadcast Receivers
- Services
Let's analyze them by the example of a music player.
Activity
These are windows of our application. Each window represents one activity. In other words a window with the track title, control elements and the album cover is one activity. Its life cycle is extremely short, because when you switch to another window (even within the same app), everything is paused, the resources are freed in a moment and the activity is disabled. In the background
nothing is handled as it is not possible this way. When you move away from the player with the nice looking equalizer it will not require any resources as this part of the app is completely idle at the moment.
To be more precise if the app contains activities only (let's say a calculator) it stops consuming resources when you move away from it. It is languishing in the cache waiting for your return.
Broadcast Receivers
These are elements of applications responsible for receiving global messages. There are many standard ones and you can expect almost any message to be received if you notify the system about it, which is useful to connect different apps. Messages vary dramatically. It can be a message that the WiFi network is available and you can go online searching for new tracks. When you insert the phone into the dock station a nice window with the clock appears. Press the pause on the headset and the playback stops. This way you can send a picture to Twitter from the gallery: your Twitter app is registered for events like "I can share pictures" and the gallery sends a similar message to all appropriate apps for the user to choose what to do with the picture. It gives flexibility to Android regarding the installation of different apps.
The module stays active as long as it is necessary to handle the message from the system. The app remains in the memory to be on the safe side if the system sends another similar message. Instead of starting the app again it will be called for from the background.
Here the issues with resources start. If the app registers itself to receive a global message the system will always start it and disabling it with the task manager is useless and harmful. On the other hand the application may receive messages only when it is active. For example, the music player must receive messages from the headset to manage the playback and use the pauses if you receive a call. If the app is not active it will ignore these events.
In this case you can disable a useless app from time to time if it sucks in resources for nothing (it often happens when the phone has acres of free memory). One of examples is that of the music and podcast players, which if started simultaneously may compete for the same resources.
Services
Now it is time to mention the least resources efficient elements. Services are components of an app, which must run in the background and have no other purpose. These are tiny blocks active to implement multitasking in Android, iOS and WP7 Mango. These are services of synchronization, updates and downloads. For the music player the track must be played by the services! Even during the call an element responsible for the conversation is the service allowing you to speak and enjoy Angry Birds at the same time.
These are the main users of resources, but task managers do not detect them well. You'd better analyze them in standard Running Services.
Android can disable services when you lack free memory, but they have a priority and the OS will try to run them again to return to the status quo.
The highest priority is given to services with the
icon in the status bar, no matter how silly it sounds. These services tell the users that they are active and Android keeps them going until the very end. That is why almost all music players have an icon in the status bar.
Conclusion
It is important to understand that different elements of applications can be active at a time and serve different purposes. By disabling the app you make the system load it again. It is necessary to disable unstable apps, which do exist in the Market due to the absence of
moderation.
Only small elements of applications will work, but the rest will be hibernating without influencing the system.