Hi,
I noticed that OS constantly unloads my applications.
Say, I visit some page using IE, then switch to another application, then switch back - it is usually at the same page, but, probably depending on idle time, it sporadically gets closed.
That said, when I go to IE again, it starts afresh on its initial page and I must reload my page again. Needless to say, in most cases this is unacceptable. (extra traffic, so it costs $$, also GPRS could become unavailable etc :x )
How do I PREVENT this behaviour?
Not only IE suffers, any application! Sporadically exits despite of fact there are tons of free memory and I would better free resources with another way than just closing what is required for me.
I have elder device with PocketPC 3.0 (Cassiopeia E-125) and it does NOT behave in such a way. Does not close even it has 4times less memory! Now I understand how nice it is.
While this problem persists, I forced to have both devices with me.
Please help me solving this!
Vadim.
I've noticed the same behavior randomly also. I don't have a fix, but you're not alone.
What ROM version are you using? There was an issue with the earlier ROMS in that there were too many programs running and when you launched another program the OS would terminate a background program to provide the necesssary process space.
The newer ROMs have solved this problem, but CheckNotify and ClearNotify (search the forum) will help with the earlier ROMs.
This is an old problem, related to the number of running processes.
Consult this thread
http://www.ppcw.net/?itemid=1645
which will show you how to solve it. Also the newer roms cut down on the number of processes at startup, which helps.
Surur
Mine is much more random than that described. Sometimes I can have a half dozen apps open with no problem, and sometimes a single app will close itself while I work in the phone or the Today screen.
Carlos said:
Mine is much more random than that described. Sometimes I can have a half dozen apps open with no problem, and sometimes a single app will close itself while I work in the phone or the Today screen.
Click to expand...
Click to collapse
Don't forget that we are talking processes, not appications, here. One app. may have many processes and multiple app's may use the same common processes. Therefore, launching one application can generate a number of new processes and that can push you over the limit (e.g. ActiveSync, which launches three or four I recall), so something gets nuked.
I understand, and was looking for a pattern, but there is none. In fact, it seems reversed, as it happens more often while I'm just out and about and less frequenty while the device is in the cradle. Very often it happens after a fresh boot with a single app running.
I may look at it more closely with a process viewer. It's not bugging me enough to make it a priority.
Thank you all for providing many help!
surur said:
This is an old problem, related to the number of running processes.
Consult this thread
http://www.ppcw.net/?itemid=1645
which will show you how to solve it. Also the newer roms cut down on the number of processes at startup, which helps.
Click to expand...
Click to collapse
That explains it all, many fruitful comments, and a prove that there could be no fix but just temporary solutions to reduce a problem a bit.
It is a bit larger problem in my case, because I use special sotware to support Russian.
Too bad MS can't recognize and fix such a big design mistakes.
Here's an article posted at http://geekfor.me that is by far the best explanation I've ever seen on this issue:
flipz: said:
FAQ: Why You Shouldn’t Be Using a Task Killer with Android
I see this come up over and over again. People saying that a task is running in the background and they think it is killing their battery or hogging all of their memory. So their natural reaction is to download a program made to kill tasks. Here’s the thing… you are likely doing more harm than good by killing tasks that aren’t ready to end. I was the same way when I first got my CDMA Hero. There were tons of things running that I didn’t want so I just kept killing them. After a few weeks I realized that if I stopped using a task killer (and totally uninstalled it in fact) my phone actually began to run better! The applications would close themselves and things just seemed to be running better. I get that there may be short term benefits from clearing a task, but you should still take the time to read through this.
Here is some information directly from Android’s developer page. I have put the important parts in bold. This is quite a lengthy read but honestly I think it’s important. If you want the full read then you can check out the dev page here. If you just want the quick TL;DNR version then scroll to the bottom.
Google: said:
By default, every application runs in its own Linux process. Android starts the process when any of the application's code needs to be executed, and shuts down the process when it's no longer needed and system resources are required by other applications.
A content provider is active only while it's responding to a request from a ContentResolver. And a broadcast receiver is active only while it's responding to a broadcast message. So there's no need to explicitly shut down these components.
Activities, on the other hand, provide the user interface. They're in a long-running conversation with the user and may remain active, even when idle, as long as the conversation continues. Similarly, services may also remain running for a long time. So Android has methods to shut down activities and services in an orderly way:
An activity can be shut down by calling its finish() method. One activity can shut down another activity (one it started with startActivityForResult()) by calling finishActivity().
A service can be stopped by calling its stopSelf() method, or by calling Context.stopService().
Components might also be shut down by the system when they are no longer being used or when Android must reclaim memory for more active components.
If the user leaves a task for a long time, the system clears the task of all activities except the root activity. When the user returns to the task again, it's as the user left it, except that only the initial activity is present. The idea is that, after a time, users will likely have abandoned what they were doing before and are returning to the task to begin something new.
Click to expand...
Click to collapse
Google: said:
Activity lifecycle
An activity has essentially three states:
It is active or running when it is in the foreground of the screen (at the top of the activity stack for the current task). This is the activity that is the focus for the user's actions.
It is paused if it has lost focus but is still visible to the user. That is, another activity lies on top of it and that activity either is transparent or doesn't cover the full screen, so some of the paused activity can show through. A paused activity is completely alive (it maintains all state and member information and remains attached to the window manager), but can be killed by the system in extreme low memory situations.
It is stopped if it is completely obscured by another activity. It still retains all state and member information. However, it is no longer visible to the user so its window is hidden and it will often be killed by the system when memory is needed elsewhere.
If an activity is paused or stopped, the system can drop it from memory either by asking it to finish (calling its finish() method), or simply killing its process. When it is displayed again to the user, it must be completely restarted and restored to its previous state.
The foreground lifetime of an activity happens between a call to onResume() until a corresponding call to onPause(). During this time, the activity is in front of all other activities on screen and is interacting with the user. An activity can frequently transition between the resumed and paused states - for example, onPause() is called when the device goes to sleep or when a new activity is started, onResume() is called when an activity result or a new intent is delivered. Therefore, the code in these two methods should be fairly lightweight.
Click to expand...
Click to collapse
The following diagram illustrates these loops and the paths an activity may take between states. The colored ovals are major states the activity can be in. The square rectangles represent the callback methods you can implement to perform operations when the activity transitions between states.
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
So… the TL;DNR Version:
Android is hard coded to automatically kill a task when more memory is needed.
Android is hard coded to automatically kill a task when it's done doing what it needs to do.
Android is hard coded to automatically kill a task when you haven't returned to it in a long time.
Most services (while possibly running in the background) use very little memory when not actively doing something.
A content provider is only doing something when there is a notification for it to give. Otherwise it uses very little memory.
Killing a process when it isn't ready only causes it to have to reload itself and start from scratch when it's needed again.
Because a task is likely running in the background for a reason, killing it will only cause it to re-spawn as soon as the activity that was using it looks for it again. And it will just have to start over again.
Killing certain processes can have undesirable side effects. Not receiving text messages, alarms not going off, and force closes just to name a few.
The only true way to prevent something from running at all on your phone would be to uninstall the .apk.
Most applications will exit themselves if you get out of it by hitting "back" until it closes rather than hitting the "home" button. But even with hitting home, Android will eventually kill it once it's been in the background for a while.
Questions? Concerns? Feel that I’m wrong? Comment below and let’s discuss!
Addendum:
One thing that I forgot to even address here is that memory works a bit differently in linux than it does in Windows. In general the way memory works is you really only need as much as you plan on using. So if your combined running programs use 100mb of memory, 150mb is more than enough. There is no need to clear what's running in memory before you hit that 150mb cap. Now in Windows it seems that the system performs a bit better when you have less stuff in memory, even if it's not full. No doubt those who have been on computers for a while will remember there used to be programs that could clear your memory in Windows also.
Linux however isn't generally affected by this. While I admit that I don't know the architecture and reason for this& linux will run the same regardless of if you have 20mb free memory or 200mb. And as I outlined above, Android will automatically start to kill applications if you do get low on memory! Stealing a quote from Chris Johnston, Buffers and cache in RAM being cleared is silly. Imagine a professor, who rather than writing all the way across the chalkboard, finishes a sentence and immediately erases and starts writing in the upper left corner AGAIN and AGAIN and AGAIN OR imagine you like a song. You record it to the beginning of a cassette tape. When you want a new song, do you re-record over the first song or record after it?"
I have also seen people incorrectly assume that the more memory in use, the faster their battery will die. This would actually be more attributed to the amount of processor cycles (CPU %) going on and not the amount of memory being taken up by a certain program. However, that does lead to a good point! When can a task manager be a good thing?? To help you determine what IS slowing down your phone; what may actually be draining your battery faster. That is actually what helped us discover that there appears to be a bug still left over from 1.5 that is causing slow downs on our CDMA Hero's even today. While an item using up memory isn't going to hurt things, an item chewing through your CPU absolutely will. Now I still don't suggest using a task killer to kill a program that is using up your processor (unless of course it is a zombie process that is going crazy, but you should probably just reboot in that case). But it can help you see what's going on with your phone.
I hope this has helped someone. With all of that said& I always encourage experimenting. It is your phone, and you can do with it what you please. If you swear that a task killer makes your phone amazing, then by all means use it! Thanks for reading.
Click to expand...
Click to collapse
Another great resource:
A video from Google's Android Team:
Androidology - Part 2 of 3 - Application Lifecycle
http://www.youtube.com/watch?v=ITfRuRkf2TM
And finally:
Check out the application "Task Manager". You'll notice dozens of processes running that you didn't even know were running. Here's my phone right now:
Look at the CPU usage column (the rightmost column) and notice that almost everything is at 0%. (The exception is TaskManager which is constantly polling since it's the active app. Menu -> Quit stops it.)
This is the best visualization that killing "running" apps will do nothing, since they're not really doing anything anyway. I have all these apps open yet they're all using 0% CPU. And I have "only" 47 MB free.
From monitoring this over the weeks, I've had as many as 60+ processes listed, and as few as 10. I've had as high as 200+ MB free and as low as 30 MB.
And my phone ran just the same.
Get rid of all your task killers for a week (and get WatchDog instead) and see how your phone feels.
Hope this helps clear up any confusion.
.
Paul is always great for good information. Everyone should look over his comment's to learn new things
Got a question though, with certain apps like Music and SIPagent there's not a way to close them. I can only pause music and there's no way to exit SIPagent without using a task killer. Shouldn't I use a task killer on these two applications?
ap3604 said:
Paul is always great for good information. Everyone should look over his comment's to learn new things
Got a question though, with certain apps like Music and SIPagent there's not a way to close them. I can only pause music and there's no way to exit SIPagent without using a task killer. Shouldn't I use a task killer on these two applications?
Click to expand...
Click to collapse
that's a good question; some apps doesn't have that quit button, like the Skyfire browser, so if i were to use the browser and close it, will still be running in the background? shouldn't i have to kill that app somehow?
anyway, will remove task killers now and give it a shot
Great thread as always, Paul, but which "Task Manager" are you talking about?
http://www.appbrain.com/search?q=task+manager
There are quite a few
I don't use a task manager, but I *have* used SeePU++'s task kill feature a couple times.
I think I found it:
http://www.appbrain.com/app/com.houmiak.taskmanager
And if you guys don't believe Paul:
jblazea50 said:
that's a good question; some apps doesn't have that quit button, like the Skyfire browser, so if i were to use the browser and close it, will still be running in the background? shouldn't i have to kill that app somehow?
anyway, will remove task killers now and give it a shot
Click to expand...
Click to collapse
They all work the same way as described in the post. You don't have to quite Skyfire, the Music app, SIPagent, or anything at all. Read through the post again, the Android OS will stop those when it needs memory.
For example, if Music is playing, it asks the Android system to consider it foreground, so it will never get forced to quit. But when music is paused it just runs as a normal app. When Android needs the memory, it force quits it immediately.
Same with Skyfire, it will remain loaded in the background if no other process needs the memory. This way if you leave and go back to it quickly it will be there, and won't have to reload. When something else needs the memory Android closes Skyfire. If you force it to close all the time, you only force it to load more often when you need it again, wasting time and battery life.
So how do I get more ram?
muncheese said:
So how do I get more ram?
Click to expand...
Click to collapse
You don't. Applications will be closed automatically by the OS when you need more RAM.
Clarkster said:
They all work the same way as described in the post. You don't have to quite Skyfire, the Music app, SIPagent, or anything at all. Read through the post again, the Android OS will stop those when it needs memory.
For example, if Music is playing, it asks the Android system to consider it foreground, so it will never get forced to quit. But when music is paused it just runs as a normal app. When Android needs the memory, it force quits it immediately.
Same with Skyfire, it will remain loaded in the background if no other process needs the memory. This way if you leave and go back to it quickly it will be there, and won't have to reload. When something else needs the memory Android closes Skyfire. If you force it to close all the time, you only force it to load more often when you need it again, wasting time and battery life.
Click to expand...
Click to collapse
thanks for the explanation; i already removed the task killers from my phone and will see how it goes
muncheese said:
So how do I get more ram?
Click to expand...
Click to collapse
You're in luck my friend!
Here you go:
http://www.downloadmoreram.com/index.html
Your phone will FLY!
Paul22000 said:
You're in luck my friend!
Here you go:
http://www.downloadmoreram.com/index.html
Your phone will FLY!
Click to expand...
Click to collapse
Awesome, I left a little on the server for you guys.
Re: FAQ: Why You Shouldnt Be Using a Task Killer with Android (geekfor.me)
I have a problem with the way android does this multitasking because when I send opera or skyfire to the background, I want it to stay there no matter what. Most of the time It's still there when I switch back to it in a few moments. But sometimes the OS has decided to close it, even though I only switched away a few moments ago to read a quick email, and my webpage is completely gone. This is a major problem for me. It's especially maddening when you then see that the OS closed opera or sky fire to pre load a bunch of apps that I haven't used in a month. Like sms backup. That's an app that I need once a month to back up my texts. So I DON'T want to uninstall it.
-------------------------------------
Sent via the XDA Tapatalk App
I agree with your post but there are a few reasons to have an app that allows you to control your apps and yes, kill them from time to time. The main one is some apps need to run in the background to work properly and it can be a quicker way to kill them when you are done with them. One I use like this is trapster. Trapster uses a lot of battery. In order to kill it I have to switch to it and drill a menu. I dont kill it because of memory concerns, I kill it because of battery usage which is not a fault, it needs to run in the background to work properly. Rather than do that though I just click one icon and kill all with my tool of choice, systempanel. I'll get back to that.
Systempanel gives you a lot of information about what your apps are doing both in real time and can log. CPU cycles used, data, etc. With it you can easily locate that app that is killing your battery or just get real data about your processes and their consumption. Just a few days ago my battery took a 10% dump in an hour and I had not even been using the phone. Only took a minute with systempanel to figure out an app I had called quick settings had been smoking crack and gone bat**** on me. One uninstall/reinstall later, all good. Try that with atk. I set up so that all my frequently used apps are excluded from a kill all as well as lower level processes. This means in the odd case like after running trapster when I kill all I'm only killing apps that would have likely been completely shut down and need to fully restart anyways and I probably wasnt going to use them regardless because they are not frequently used apps. In other words I lose somewhere between very little and nothing but save the hassle of drilling menus to kill an app I want to stop. Im pretty high on this app, you can read more here http://androidforums.com/android-ap...task-killer-people-who-hate-task-killers.html
Re: FAQ: Why You Shouldnt Be Using a Task Killer with Android (geekfor.me)
I understand all that, but I DON'T run anything but stock apps plus opera. So I DON'T have any unique situations of certain apps needing to be running for things to work properly. If you saw my system panel list you would see how downright simple my phone setup is, yet something like opera can't even stay open because the OS killed it. It's a horrible multitasking mechanism.
I was responding to a different post Roger, sorry for the confusion. Yours and several others came in before I was done typing.
I have had that one a couple times myself. I have been keeping my eye out for a good startup manager. Something that will allow me to stop amazon and others alltogether as well as manage when apps can startup. Something along the lines of only when the phone has been asleep for a set amount of time and so on. Might be a guy could make it so that the problem is reduced that way although it doesnt attack the problem directly.
Re: FAQ: Why You Shouldnt Be Using a Task Killer with Android (geekfor.me)
Oh sorry I got confused.
Well anyway I don't have it in me to make a long detailed post, but I'm finding that android's multitasking is seriously flawed on a fundamental level. In fact it does the exact opposite of what I'm trying to do in many instances.
One quick example, load up a few webpages in the default browser, maybe an article or 2 and have the pages fully load so they are there to read. Great, now minimize the browser and go to the homescreen and then back to the browser. Your pages are still there, good.
Now I lost my data connection cause I'm commuting on the the train to work in a tunnel. If I open up any other app the OS closes the browser. When I reopen the browser all my loaded pages are still there in memory to read, but the browser immediately tries to refresh the pages, which won't work cause no data connection, and now my cached page disappears. Horrible. I purposely loaded those pages to read offline. The ass kicker is that all the while this happened because the OS decided to pre load a bunch of apps during this time which were not running previously and caused this browser to close. Apps I've not used in weeks, yet the app I WANT suffers.
I have more extreme examples but don't have the energy to post them now. But Google has closed out this item on their suggestion/bug forum.
RogerPodacter said:
Oh sorry I got confused.
Well anyway I don't have it in me to make a long detailed post, but I'm finding that android's multitasking is seriously flawed on a fundamental level. In fact it does the exact opposite of what I'm trying to do in many instances.
One quick example, load up a few webpages in the default browser, maybe an article or 2 and have the pages fully load so they are there to read. Great, now minimize the browser and go to the homescreen and then back to the browser. Your pages are still there, good.
Now I lost my data connection cause I'm commuting on the the train to work in a tunnel. If I open up any other app the OS closes the browser. When I reopen the browser all my loaded pages are still there in memory to read, but the browser immediately tries to refresh the pages, which won't work cause no data connection, and now my cached page disappears. Horrible. I purposely loaded those pages to read offline. The ass kicker is that all the while this happened because the OS decided to pre load a bunch of apps during this time which were not running previously and caused this browser to close. Apps I've not used in weeks, yet the app I WANT suffers.
I have more extreme examples but don't have the energy to post them now. But Google has closed out this item on their suggestion/bug forum.
Click to expand...
Click to collapse
You could easily download taskpanel, and add apps you do not need to the "auto kill list". I didn't know stock (which you said you were on a while ago) was so horrible when it came to memory, your problems don't even exist on my phone. I'm curious, if you installed Cyanogen would your problems away. If my browser closed on me after having too many apps open, I would be irritated as well.
I can have about 50-60 applications idle, or whatever, and the browser would never close. I don't use Opera, or Skyfire, though.
Paul22000 said:
Here's an article posted at http://geekfor.me that is by far the best explanation I've ever seen...
Click to expand...
Click to collapse
Nice find, I got this article since a couple of weeks in my signature, in another forum and killed my taskkiller since then
I use a Task Manager that separates system tasks from app tasks. Anything I use on a regular basis, or even at all, including widgets I use and such, I add to the ignore list. I use it to kill background apps that try to run when they don't need to run. Why don't they need to run? Because I don't need stocks and twitter apps running because I don't use them and it won't let me uninstall them. Next best thing to do is to put them on an auto kill list, though it isn't quite aggressive enough. I really don't want to root just to uninstall the massive amount of bloat that comes from Telstra.
Paul22000 said:
You're in luck my friend!
Here you go:
http://www.downloadmoreram.com/index.html
Your phone will FLY!
Click to expand...
Click to collapse
O.M.G.!!!!! This totally worked for me. This link should be stickied. Easy to use and simple.
muncheese said:
Awesome, I left a little on the server for you guys.
Click to expand...
Click to collapse
There can never be too much.
Now, a question. How about a program that polls for a signal, like google maps? Will it not look for things like my location? Please educate me, I want to believe.
wow great info and its really starting to help out after a few days. Think i got a pretty good question though. I understand the killing of apps and all of that now but what do yall think of a startup manager and picking and choosing before or while the system is booting (ive been using startup manager i found in the market). Just wanted to see what everyone thought. thanks, veritas
Hey guys. I've been looking around all over for info on the problem with my app. Nothing I found was a concrete answer. here's the problem. I made an app that works really well except it force closes when I hit the back button to finish activity and then start another of the same activity as before. It force closes once in a while when I do this, throwing a log cat error that says out of memory, pointing to where I fill my bitmap cache. There's two reasons im thinking it would be doing this. 1) My bitmap factory is having a problem or 2) I have the context of my activity stored as a variable so I can close activity and that is too much memory. I'm using a panel, which also may add to the problem. Also, another phone can't even start the activity the first time. Any help would be greatly appreciated. This is only problem on app and this fix will make it market ready.
Sent from my SCH-I500 using XDA App
Did you try to explicitly clean up the bitmap references? you should call Recycle() on every bitmap in your activity's onDestroy or wherever you do your cleaning. Another issue I had was with the Bitmap.CreateScaledBitmap method - it leaks, apparently. I made a small static method that uses a transform matrix and then calls Bitmap.CreateBitmap (the overload that takes a matrix, obviously). That change alone solved half my memory issues.
The thing about not loading at all on another phone might be a heap issue. My game loaded just great on my customized SGS, but on the emulator with 24mb of heap it crashed. The reason was that I pre-load all the sprites at the beginning, and apparently 24mb isn't that much
Solution was downscaling and lowering resolution and color depth for the sprites, not much possibilities here - too many bitmaps take too much memory...
I'm guessing the phone you tested likely has a smaller heap than the phone that doesn't make your app crash.
Of course all of the above is mostly guess work, but that's what I can supply right now
i have the problem fc too, but after i upgraded to 2.2. the seem the problem fixed automatically.
Thanks so much! I made it recycle my bitmaps, along with a few minor changes, and it worked great! Thanks for your help!
Sent from my SCH-I500 using XDA App
I noticed certain background processes like 'Email' and 'Gallery' kept coming back.
Even after I killed them with 'Advanced Task Killer', they kept popping back up and I want to know how to stop them? I don't want them to run automatically unless I need them.
Why is 'Gallery' kept popping up? I haven't checked any pictures lately.
Good question bro. This should be put to Google's Android forum.
Sent from my GT-I9100 using XDA Premium App
MrRoberts69 said:
I noticed certain background processes like 'Email' and 'Gallery' kept coming back.
Even after I killed them with 'Advanced Task Killer', they kept popping back up and I want to know how to stop them? I don't want them to run automatically unless I need them.
Why is 'Gallery' kept popping up? I haven't checked any pictures lately.
Click to expand...
Click to collapse
Out of interest, why are you bothered about it?
MrRoberts69 said:
I noticed certain background processes like 'Email' and 'Gallery' kept coming back.
Even after I killed them with 'Advanced Task Killer', they kept popping back up and I want to know how to stop them? I don't want them to run automatically unless I need them.
Why is 'Gallery' kept popping up? I haven't checked any pictures lately.
Click to expand...
Click to collapse
Please spend some time to read up on how linux works, specifically how memory is used, and then you will understand how Android works and why these applications keep "coming back".
I cringe everytime I read people talking about taskkiller applications.
kitch9 said:
Out of interest, why are you bothered about it?
Click to expand...
Click to collapse
I like to know how things tick and there is a REASON why the 'Gallery' kept popping back up.
MrRoberts69 said:
I like to know how things tick and there is a REASON why the 'Gallery' kept popping back up.
Click to expand...
Click to collapse
Because this is how android OS works. It loads processes for faster use when needed. There is nothing you can do to stop it, its based on android and its process management method, etc. These apps should be frozen in an idle state using zero resources. Use system panel to confirm gallery is not using any CPU.
They should make the system clever by having it learn what each person uses/doesn't use and only load the processes accordingly . I just find it irritating that it loads stuff that I am never going to use... I don't care that it doesn't use resouces, I just find untidy
I agree, i dont like things to start without me using them first neither! This is just stupid. Also some things should never been shown to users in my opinion. If something is in the kernel and not for me to mess with it should be hidden.
ps. as a user i dont want to spend reading tons of pages on how the OS works in detail, it should be easy to use and dont make the user confused. this is one aspect i hope Android improves in the future.
vampyren said:
I agree, i dont like things to start without me using them first neither! This is just stupid. Also some things should never been shown to users in my opinion. If something is in the kernel and not for me to mess with it should be hidden.
ps. as a user i dont want to spend reading tons of pages on how the OS works in detail, it should be easy to use and dont make the user confused. this is one aspect i hope Android improves in the future.
Click to expand...
Click to collapse
Buy an iphone
Sent from my GT-I9100 using XDA App
First of all starting some processes also start others in anticipation of their use. What is happening is that apps you are using are calling for those to start for quicker launch and there are dependencies that are not immediately obvious that will sometimes start a seemingly unrelated process. Memory management on android is very good and typically with task killers you often work against the built in memory management. I'm going to do a cut an paste here with a few basics....
By default, every application runs in its own Linux process. Android starts the process when any of the application's code needs to be executed, and shuts down the process when it's no longer needed and system resources are required by other applications.
A content provider is active only while it's responding to a request from a ContentResolver. And a broadcast receiver is active only while it's responding to a broadcast message. So there's no need to explicitly shut down these components.
Activities, on the other hand, provide the user interface. They're in a long-running conversation with the user and may remain active, even when idle, as long as the conversation continues. Similarly, services may also remain running for a long time. So Android has methods to shut down activities and services in an orderly way:
An activity can be shut down by calling its finish() method. One activity can shut down another activity (one it started with startActivityForResult()) by calling finishActivity().
A service can be stopped by calling its stopSelf() method, or by calling Context.stopService().
Components might also be shut down by the system when they are no longer being used or when Android must reclaim memory for more active components.
If the user leaves a task for a long time, the system clears the task of all activities except the root activity. When the user returns to the task again, it's as the user left it, except that only the initial activity is present. The idea is that, after a time, users will likely have abandoned what they were doing before and are returning to the task to begin something new.
An activity has essentially three states:
It is active or running when it is in the foreground of the screen (at the top of the activity stack for the current task). This is the activity that is the focus for the user's actions.
It is paused if it has lost focus but is still visible to the user. That is, another activity lies on top of it and that activity either is transparent or doesn't cover the full screen, so some of the paused activity can show through. A paused activity is completely alive (it maintains all state and member information and remains attached to the window manager), but can be killed by the system in extreme low memory situations.
It is stopped if it is completely obscured by another activity. It still retains all state and member information. However, it is no longer visible to the user so its window is hidden and it will often be killed by the system when memory is needed elsewhere.
If an activity is paused or stopped, the system can drop it from memory either by asking it to finish (calling its finish() method), or simply killing its process. When it is displayed again to the user, it must be completely restarted and restored to its previous state.
The foreground lifetime of an activity happens between a call to onResume() until a corresponding call to onPause(). During this time, the activity is in front of all other activities on screen and is interacting with the user. An activity can frequently transition between the resumed and paused states - for example, onPause() is called when the device goes to sleep or when a new activity is started, onResume() is called when an activity result or a new intent is delivered. Therefore, the code in these two methods should be fairly lightweight.
A few conclusions.....
Android is hard coded to automatically kill a task when more memory is needed.
Android is hard coded to automatically kill a task when it's done doing what it needs to do.
Android is hard coded to automatically kill a task when you haven't returned to it in a long time.
Most services (while possibly running in the background) use very little memory when not actively doing something.
A content provider is only doing something when there is a notification for it to give. Otherwise it uses very little memory.
Killing a process when it isn't ready only causes it to have to reload itself and start from scratch when it's needed again.
Because a task is likely running in the background for a reason, killing it will only cause it to re-spawn as soon as the activity that was using it looks for it again. And it will just have to start over again.
Killing certain processes can have undesirable side effects. Not receiving text messages, alarms not going off, and force closes just to name a few.
The only true way to prevent something from running at all on your phone would be to uninstall the .apk.
Most applications will exit themselves if you get out of it by hitting "back" until it closes rather than hitting the "home" button. But even with hitting home, Android will eventually kill it once it's been in the background for a while.
krabman, thanks mate now your post really helped me a lot to understand these processes
Thought I would record my troubles with a game render loop and a logic engine given a particular bug has swallowed up about a week of my time. I am posting it incase anyone else happens to have the same problem/symptomns.
It originated when I wrote the LogicEngine which has an ArrayList of GameObjects and iterates through them deleting them as nessesary depending on the results of thier processStep.
The render thread would occasionally crash when something was deleted from the array while the list was being drawn but this happened quite rarely. No problem I thought, I'll just catch the out of bounds exception and it will get displayed on the next frame however many milliseconds later.
This all went well for 3 months of coding till I got to programming terrain where about 300 blocks were all displayed gradually scrolling down the screen. The blocks would flash intermittently but in sections not all at once.
At first I thought it was too many blocks for the LogicEngines collision detection so I doubled the size of the blocks. Then I thought it might be overhead allocating memory for the blocks and preloaded them in the constructor. Eventually in despair I disabled the deletion of blocks once they went offscreen and noticed the flashing stopped. This was the point I realised what was happening: The LogicEngine would delete a row of blocks because they went offscreen and the Renderer would be half way through drawing and instead of crashing it would just skip x blocks wherever it was in the for loop at the time that the LogicEngine removed them.
Wow I feel stupid, especially because of the lazy Exception catching solution I originally implemented which masked the problem for so long.
Code:
GameRender.java
//draw obstacles
theLogicEngine.objectsObstaclesLock.writeLock().lock();
for(int i=0 ; i<theLogicEngine.objectsObstacles.size();i++)
{
drawObject(theLogicEngine.objectsObstacles.get(i));
}
theLogicEngine.objectsObstaclesLock.writeLock().unlock();
LogicEngine.java
for(int i=0;i<objectsObstacles.size();i++)
if(objectsObstacles.get(i).processStep(this)) //we are to delete this object
{
objectsObstaclesLock.writeLock().lock();
//remove self if necessary
//move object returned true so delete object
GameObject toDelete = objectsObstacles.get(i);
objectsObstacles.remove(i);
toDelete.dispose();
i--;
objectsObstaclesLock.writeLock().unlock();
}
TLDR: If you have an ArrayList that can be edited by one thread, make sure you lock it rather than just catching the ArrayOutOfBoundsException
Glad you figured it out
I am still impressed that you can write Android games using these techniques. Is your game low-res or is Dalvik that powerful?
I mean, you are using Java, which is one thing, but then you use ArrayList and you delete objects as you go. I take this to mean that you do not recycle them in a pool.
Am I correct?
cyansmoker said:
Glad you figured it out
I am still impressed that you can write Android games using these techniques. Is your game low-res or is Dalvik that powerful?
I mean, you are using Java, which is one thing, but then you use ArrayList and you delete objects as you go. I take this to mean that you do not recycle them in a pool.
Am I correct?
Click to expand...
Click to collapse
ArrayList is self managing.
All of Java's garbage collection is done automatically. As a Java dev u can call System.gc but this only suggest the system attempt gc.
Dalvik is pretty good, but anything extensive I would go native...
Sent from my Galaxy Nexus using Tapatalk
jug6ernaut said:
ArrayList is self managing.
Click to expand...
Click to collapse
Right. But then there is the memory consumption issue. That's why I typically do things as described in this blog entry.
jug6ernaut said:
All of Java's garbage collection is done automatically. As a Java dev u can call System.gc but this only suggest the system attempt gc.
Click to expand...
Click to collapse
Although in System.gc()'s defense I've always observed that it was run immediately in Sun's ref. implementation. Not sure about Dalvik.
But overall I agree with your conclusion.
cyansmoker said:
I am still impressed that you can write Android games using these techniques. Is your game low-res or is Dalvik that powerful?
Click to expand...
Click to collapse
So far I have not been having any performance issues. The ArrayLists contain GameObjects which are quite lightweight memory wise as they do not contain Textures.
Textures are maintained in separate dictionary with a string key.
I did try recycling GameObjects in one location where I was spawning / destroying a lot but it didn't really seem to impact performance much.
I think my biggest area for optimisation at the moment is in collision direction. Currently there are about 5 different ArrayLists (Obstacles, Enemies, Players, Player Bullets, Enemy Bullets etc) only those that interact are tested for collision (Vector2d distance < objects collision radius). I think theres probably opportunity to split it further into quads.
I've yet to build in proper optimisation checking but it plays fine in 320x480 with ~100 enemies on screen and 4 player ships with maybe 20 bullets on screen at once with a turnover of 5/10 GameObjects a second. Even with this number though Texture memory usage is low with most enemies between 16x16 and 48x48.
I think libgdx and the behaviours library I use are pretty optimised.