I've read some posts stating that using this method is "not good", shouldn't be used, it's not the right way to "close" the application and it's not how Android works...
I understand and accept the fact that the Android OS knows better than me when it's the right time to terminate the process, but I haven't yet heard a good explanation on why it's wrong to use the killProcess()
method. After all - it's part of the Android API.
What I do know is that calling this method while other threads are doing potentially important work (operations on files, writing to DB, HTTP requests, running services..) results in the threads being terminated and it's clearly not good. Also, I know I can benefit from the fact that "re-opening" the application will be faster because the system stills "holds" in memory state from the last time the app was used, and killProcess()
prevents that.
Besides this reason, assuming I don't have such operations, and I don't care my application whether my app will start from scratch every time it is opened, are there other reasons why I should not use the killProcess()
method?
I know about the finish()
method to close an Activity
, so please don't include that in your answer.
finish()
is only for Activity
, not for all applications, and I think I know exactly why and when to use it.
And another thing - I'm developing games with the Unity3D framework and exporting the project to Android. When I decompiled the generated apk, I was very surprised to find out that the java source code created from unity - implementing Unity's - Application.quit()
method, with Process.killProcess(Process.myPid())
.
Application.quit()
is supposed to be the right way to close the game according to the Unity3D docs (Is it really? Maybe I'm wrong and missed something), so why did the Unity's framework developers implement this in native Android?
<rant>
In a perfect world, with perfect code and libraries, you shouldn't need to call Process.killProcess(Process.myPid())
and the OS will correctly kill your application as appropriate. Also there will be peace in the Middle East, pigs will fly, and the halting problem will be solved.
Because all of these things haven't happened yet there are times when you need to execute such 'forbidden' code.
Most recently for an Android game I made, the free version used an Ad library which would keep the application alive and also leak memory. The paid version didn't have this problem as there were no ad libraries linked. My solution was to add a Quit button on the main menu that executed such code. My hopes were that the majority of people would hit this button when done and I don't have to worry about it eating up memory. The paid version I just executed finish()
and was done. (This was before In-app purchases for Google were available, so I had to make a paid and free version, also they may have fixed the issue by now and I could update said game but it really didn't do too well and I doubt any time spent on it would be worth it)
Its kind of like in elementary/middle school they tell you that you can't take the square root of a negative number. Then later in a higher level algebra class they say... well you can take the square root of a negative number but you get weird results but it's consistent and solves the problem.
In other words, don't execute the 'forbidden' code unless you know what you're doing.
</rant>
Who said calling Process.killProcess(Process.myPid()) is a bad idea?
Yes, letting the OS manage its own memory is the best practice for both you and the user using your application (faster to open again, less chances for force closes, etc...).
However, assuming you know for sure that you're not interrupting threads or other background operations and you use this call in onDestroy()
- I see no reason why you shouldn't use it. Especially when it's an API call and not a workaround, and Google didn't mention it's better not to use it in the API documentation.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With