由android:process引發的記憶體限制的問題

android:process

定義activity運行所在的進程名稱。一般情況下，應用的所有組件都運行在為應用建立的預設的進程中，該預設進程的名稱應用程式套件名稱一致。通過定義<application>元素的“process”屬性可以為所有組件指定一個不同的預設進程。但是任意組件都可以重寫預設進程，以便實現多進程操作。

如果該屬性指定名稱以“：”開頭，則一個新的專屬於該應用的進程將會被建立。如果該進程名以小寫字母開頭，則為該activity提供許可權以讓其在一個全域的進程中運行。這樣會允許多個應用的不同組件共用一個進程，以便節省資源。

 

Android是支援多進程的，每個進程的記憶體使用量限制一般為24MB的記憶體，所以當完成一些很耗費記憶體的操作如處理高解析度圖片時，需要單獨開一個進程來執行該操作（上面的配置可以用來實現該操作）。即便如此，開發人員還是不要隨意多開進程來耗費使用者的資源。（記憶體限制，有16MB，24MB，
32MB，很老的機型的記憶體限制會是16MB，這個具體還要再搜尋下資料。。）

 

另外一些還有一些其他的方式來繞過記憶體限制，使用更多的資源來完成自己的任務，如下文（有待實踐）：

                                
How to work around Android’s 24 MB memory limit

The Android framework enforces a per-process 24 MB memory limit. On some older devices, such as the G1, the limit is even lower at 16 MB.

What’s more, the memory used by Bitmaps is included in the limit. For an application manipulating images it is pretty easy to reach this limit and get the process killed with
an OOM exception:

E/dalvikvm-heap(12517): 1048576-byte external allocation too large for this process.
E/GraphicsJNI(12517): VM won't let us allocate 1048576 bytes
D/AndroidRuntime(12517): Shutting down VM
W/dalvikvm(12517): threadid=1: thread exiting with uncaught exception (group=0x4001d7f0)
E/AndroidRuntime(12517): FATAL EXCEPTION: main
E/AndroidRuntime(12517): java.lang.OutOfMemoryError: bitmap size exceeds VM budget

This limit is ridiculously low. For a device, like the Nexus One, with 512MB of physical RAM, setting the per-process memory limit for the foreground activity to only 5% of the RAM is a silly mistake.
But anyway, that’s how things are and we have to live with it
— i.e. find how to work around it.

There are two ways to allocate much more memory than the limit:

One way is to allocate memory from native code. Using the NDK (native development kit) and JNI, it’s possible to allocate memory from the C level (e.g. malloc/free or new/delete),
and such allocations are not counted towards the 24 MB limit. It’s true, allocating memory from native code is not as convenient as from Java, but it can be used to store some large amounts of data in RAM (even image data).

Another way, which works well for images, is to use OpenGL textures
— the texture memory is not counted towards the limit.

To see how much memory your app has really allocated you can use android.os.Debug.getNativeHeapAllocatedSize().

Using either of the two techniques presented above, on a Nexus One, I could easily allocate 300MB for a single foreground process
— more than 10 times the default 24 MB limit.