将一个Android应用程序划分为两个进程，以便可以将一个进程用于位图操作，以避开OutOfMemoryErrors

Question

As far as I know we can optionally assign different processes for logically separated parts of our app in Android, and as far as I know, the new process will have a new part of the heap set aside for it.

So lets say our app utilizes 90-100 mb of the 128 mb heap and we need to carry out an operation with a 50mb bitmap.

There is no time to rewrite, refactor and optimize the code, so that the app uses significantly less RAM.

Can we assign a different process ID for the Activity that handles those heavyweight Bitmap operations, so we avoid an OutOfMemoryError and what are the cons of that, if it is possible?

I've already read this: What are pros and cons of using multiple processes within android application but it is not as specific as my question.

Here:

http://developer.android.com/training/articles/memory.html#MultipleProcesses

There is a mention that this might actually increase the RAM footprint, but they havent elaborated on it.

Answer 1

Can we assign a different process ID for the Activity that handles those heavyweight Bitmap operations

You can run that activity in a separate process, following the instructions from your second link , using the android:process attribute in the manifest.

so we avoid an OutOfMemoryError

That's not a guarantee. In fact, given the following quoted statement, it's not even likely.

So lets say our app utilizes 90-100 mb of the 128 mb heap

You have no guarantee of getting anything more than 16MB. Even with android:largeHeap="true" , you may not get any more heap space than you would have without that attribute. Do not assume that either process will necessarily have 50MB of heap space, unless you control the hardware.

what are the cons of that, if it is possible?

It may not help, unless nothing in your first process has need of the bitmap in question. So, for example, if your first process is taking a camera photo using the Camera API, you would have the whole bitmap in the first process anyway (or crash trying). OTOH, if the bitmap is only being downloaded by the first process, and you're doing that the right way (streaming the results to a file), then it may help with your issue.

However, it does mean that the bitmap-processing activity is going to be a bit slow to launch, as it will have to read the bitmap off of disk, or do the downloading itself, as deemed appropriate.

Any non-IPC communications that the activity would need (eg, event bus, singleton caches) will not be there.

Processes get terminated to free up system RAM when they are in the background. And, in your case, that could be either process. You will need to be able to handle the cases where the user leaves your app (eg, HOME button) and one or both of your processes had been terminated in the interim. It's also not out of the question that your first process will be terminated while your second process is in the foreground -- I haven't checked process importance values in this scenario, where both processes belong to the same Android app.

And, as noted previously, you have no assurance that a completely clean process is capable of loading a 50MB bitmap into the Dalvik/ART heap.

There is a mention that this might actually increase the RAM footprint, but they havent elaborated on it.

RAM footprint != heap space. RAM footprint means the total amount of system RAM associated with your app. While both processes are running, you will be using more system RAM than you would by doing the same work with just one process. That bitmap-processing process will be around while the activity is in the foreground and for a while after that, before Android eventually terminates it to free up system RAM.

There is no time to rewrite, refactor and optimize the code, so that the app uses significantly less RAM.

Unless you control the hardware, you don't really have a choice. The only way you can be fairly sure that you can process 50MB of data in RAM is via the NDK, as native allocations ( malloc() and friends) are from system RAM, not the Dalvik/ART heap, and therefore do not count against that heap limit.