Question

如何突破24M内存的限制，为Android程序分配到更多内存

Answer 1

一个Android的应用最多使用16M的内存,如果要突破这个限制,则要使用c/c++编写JNI,即直接调用底层的函数来处理.linux也是用c/c++来编写的,因此有非常非常多的函数库可以调用.

Answer 2

上面那个老哥的英文翻译

如何解决Android的24 MB内存限制
Android框架强制每进程24 MB的内存限制。在一些较旧的设备上，例如G1，极限值更低至16 MB。
此外，Bitmap使用的内存也包含在限制内。对于处理图像的应用程序来说，达到这个极限非常容易，并且可以通过OOM异常来杀死进程：
E / dalvikvm-heap（12517）：1048576字节的外部分配对于此进程来说太大。
E / GraphicsJNI（12517）：VM不会让我们分配1048576字节
D / AndroidRuntime（12517）：关闭虚拟机
W / dalvikvm（12517）：threadid = 1：线程退出时带有未捕获的异常（group = 0x4001d7f0）
E / AndroidRuntime（12517）：致命例外：主
E / AndroidRuntime（12517）：java.lang.OutOfMemoryError：位图大小超过虚拟机预算
这个限制是非常低的。对于像Nexus One这样的具有512MB物理RAM的设备，将前台活动的每进程内存限制设置为RAM的5％是一个愚蠢的错误。但无论如何，这就是事情的方式，我们必须忍受它 - 即。找到如何解决它。
有两种方法可以分配比限制更多的内存：
一种方法是从本机代码分配内存。使用NDK（本地开发工具包）和JNI，可以从C级别分配内存（例如，malloc / free或new / delete），并且这些分配不会计入24 MB限制。确实，从本地代码分配内存并不像从Java那样方便，但它可以用来在RAM中存储大量数据（甚至是图像数据）。
另一种适用于图像的方法是使用OpenGL纹理 - 纹理内存不计入极限。
要查看您的应用真正分配了多少内存，可以使用android.os.Debug.getNativeHeapAllocatedSize（）。
使用上面介绍的两种技术中的任何一种，在Nexus One上，我可以轻松地为单个前台进程分配300MB--超过默认24MB限制的10倍。

Answer 3

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.