android out of memory(OOM)

http://my.oschina.net/kangchunhui/blog/67613(转载)
1.什么是 OutOfMemoryError：

官方引用： Thrown when a request for memory is made that can not be satisfied using the available platform resources. Such a request may be made by both the running application or by an internal function of the VM.
通俗的讲：就是在请求一块内存的时候，当前可用资源不够用来请求时抛出的一种错误。我们知道，每个 android 程序就是一个独立 dalvik vm 实例，每个实例限制了最大内存占用，如果超过了这个限制，系统就会抛出这个错误。所以跟整个设备的剩余内存没太大关系，当然如果设备剩余内存都不足以再运行一个程序时，系统就会选择 kill 部分程序以确保有足够内存运行其他程序。


2.android 内存组成：

android 内存由 dalvik 和 native 2部分组成，dalvik 也就是 java 堆，创建的对象就是在这里分配的，而 native 是通过 c/c++ 方式申请的内存，Bitmap 就是以一种方式分配的（android3.0 以后，系统默认是通过 dalvik 分配的）。当然无论以何种方式分配，2部分加起来不能超过 android 对单个程序的内存限制。


3.内存限制大小：

1 ActivityManager activityManager = (ActivityManager) context.getSystemService(Context.ACTIVITY_SERVICE);2 activityManager.getMemoryClass();
以上方法会返回以 M 为单位的数字，可能在不同的平台或者设备上值都不太一样，比如：HTC G7 默认 24M，Galaxy 36M，emulator-2.3 24M，等等。

4.程序实际占用：

以一个简单的 android 程序为例，该程序是用 eclipse adt 自动生成的最简单的一个 android 项目，只有1个 activity 和 adt 自动生成的 res 目录，测试环境：emulator-2.3.3
启动该程序，命令行运行：

adb shell dumpsys meminfo com.mem.demo
执行结果：


Applications Memory Usage (kB):

Uptime: 1195344 Realtime: 1195344 ** MEMINFO in pid 333 [com.mem.demo] **

                    native   dalvik    other    total
    --------------------------------------------------------
    |       size:     3968     5379      N/A     9347      |
    |                                                      |
    |   allocated:    3964     2649      N/A     6613      |
    --------------------------------------------------------
            free:        3     2730      N/A     2733

           (Pss):      553      449     2516     3518

  (shared dirty):     2272     1868     6648    10788

    (priv dirty):      420       32     1140     1592 

Objects

           Views:        0        ViewRoots:        0      AppContexts:        0       Activities:        0           Assets:        2    AssetManagers:        2    Local Binders:        5    Proxy Binders:       10 Death Recipients:        0  OpenSSL Sockets:        0 

SQL

               heap:        0         MEMORY_USED:        0  PAGECACHE_OVERFLOW:        0         MALLOC_SIZE:        0 



Asset Allocations

    zip:/data/app/com.mem.demo-1.apk:/resources.arsc: 1K

从上面被框出来的部分可以看出，一个最简单的 android 程序在启动后都有 6m 左右内存的占用（上面是 6613kb）。那这 6m 的内存除了该 android 自己的资源和类之外，其他的还有什么呢：

简单说：在初始化的时候会 preload 一些东西，这些就包括 classes 和系统资源，就是系统的一些布局啊，图片啊，等等，在 android 完成启动以后，这部分就通过内存共享的方式共享给其他程序，可以让其他程序可以调用这部分资源，代码可以参考：http://goo.gl/EKvCV，android 整个启动流程可以参考：http://goo.gl/K36Lr 。

5.发生 OOM ：

为了制造 OOM，我们对上面最简单的程序进行了改写：

?
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
package com.mem.demo;
import android.app.Activity;
import android.graphics.Bitmap;
import android.graphics.BitmapFactory;
import android.os.Bundle;
public class DemoActivity extends Activity {
Bitmap map1, map2, map3, map4;
/** Called when the activity is first created. */
@Override
public void onCreate(Bundle savedInstanceState) {
super .onCreate(savedInstanceState);
setContentView(R.layout.main);
map1 = BitmapFactory.decodeResource(getResources(), R.drawable.big1);
map2 = BitmapFactory.decodeResource(getResources(), R.drawable.big2);
map3 = BitmapFactory.decodeResource(getResources(), R.drawable.big3);
map4 = BitmapFactory.decodeResource(getResources(), R.drawable.big4);
}
}
其中：big1 到 big4 都是 1600*900 分辨率的图片，放在 drawbable-hdpi 文件夹下面，启动程序，发生了 OOM：


05-08 07:44:44.372: E/dalvikvm-heap(386): 5760000-byte external allocation too large for this process.05-08 07:44:44.412: I/dalvikvm-heap(386): Clamp target GC heap from 25.099MB to 24.000MB05-08 07:44:44.412: E/GraphicsJNI(386): VM won't let us allocate 5760000 bytes 05-08 07:44:44.412: D/dalvikvm(386): GC_FOR_MALLOC freed 0K, 53% free 2548K/5379K, external 18500K/20548K, paused 36ms05-08 07:44:44.422: D/skia(386): --- decoder->decode returned false 05-08 07:44:44.422: D/AndroidRuntime(386): Shutting down VM05-08 07:44:44.432: W/dalvikvm(386): threadid=1: thread exiting with uncaught exception (group=0x40015560)05-08 07:44:44.442: E/AndroidRuntime(386): FATAL EXCEPTION: main05-08 07:44:44.442: E/AndroidRuntime(386): java.lang.OutOfMemoryError: bitmap size exceeds VM budget05-08 07:44:44.442: E/AndroidRuntime(386):     at android.graphics.BitmapFactory.nativeDecodeAsset(Native Method)05-08 07:44:44.442: E/AndroidRuntime(386):     at android.graphics.BitmapFactory.decodeStream(BitmapFactory.java:460)05-08 07:44:44.442: E/AndroidRuntime(386):     at android.graphics.BitmapFactory.decodeResourceStream(BitmapFactory.java:336)05-08 07:44:44.442: E/AndroidRuntime(386):     at android.graphics.BitmapFactory.decodeResource(BitmapFactory.java:359)05-08 07:44:44.442: E/AndroidRuntime(386):     at android.graphics.BitmapFactory.decodeResource(BitmapFactory.java:385)05-08 07:44:44.442: E/AndroidRuntime(386):     at com.mem.demo.DemoActivity.onCreate(DemoActivity.java:20)05-08 07:44:44.442: E/AndroidRuntime(386):     at android.app.Instrumentation.callActivityOnCreate(Instrumentation.java:1047)05-08 07:44:44.442: E/AndroidRuntime(386):     at android.app.ActivityThread.performLaunchActivity(ActivityThread.java:1611)05-08 07:44:44.442: E/AndroidRuntime(386):     at android.app.ActivityThread.handleLaunchActivity(ActivityThread.java:1663)05-08 07:44:44.442: E/AndroidRuntime(386):     at android.app.ActivityThread.access$1500(ActivityThread.java:117)05-08 07:44:44.442: E/AndroidRuntime(386):     at android.app.ActivityThread$H.handleMessage(ActivityThread.java:931)05-08 07:44:44.442: E/AndroidRuntime(386):     at android.os.Handler.dispatchMessage(Handler.java:99)05-08 07:44:44.442: E/AndroidRuntime(386):     at android.os.Looper.loop(Looper.java:123)05-08 07:44:44.442: E/AndroidRuntime(386):     at android.app.ActivityThread.main(ActivityThread.java:3683)05-08 07:44:44.442: E/AndroidRuntime(386):     at java.lang.reflect.Method.invokeNative(Native Method)05-08 07:44:44.442: E/AndroidRuntime(386):     at java.lang.reflect.Method.invoke(Method.java:507)05-08 07:44:44.442: E/AndroidRuntime(386):     at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:839)05-08 07:44:44.442: E/AndroidRuntime(386):     at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:597)05-08 07:44:44.442: E/AndroidRuntime(386):     at dalvik.system.NativeStart.main(Native Method)

从日志上看，内存不足发生在 decode big4 这个图片的时候，我们对内存情况进行打印：


Applications Memory Usage (kB):
Uptime: 958383 Realtime: 958383 ** MEMINFO in pid 386 [com.mem.demo] **                     native   dalvik    other    total
            size:    25144     5379      N/A    30523        allocated:    20799     2614      N/A    23413             free:       60     2765      N/A     2825            (Pss):      494      426    18494    19414   (shared dirty):     2288     1876     5292     9456     (priv dirty):      360       28    17836    18224

从内存打印情况看出，当前已经分配了 23m 左右内存，同时结合 logcat 错误日志，big4 这个图片需要申请 5760000byte，即:5.76m 的内存，加起来就是 29m 左右内存，我们测试环境是 emulator2.3.3 默认是
24m，内存不足以申请这么多，所以抛出了OOM。

那为什么区区3，4张图片就会让 android 程序内存不足？
设备限制是一方面，像上面第3点说的，每个 android 设备的内存限制不一样，这个程序在模拟器上会有问题，在其他设备上，比如：galaxy 就不会有问题。最主要的还是跟图片所占内存有关系，那么一张图片到底
占用多少内存呢，java 没有 c 的 sizeof() 函数，无法准确去量化这个数值，但是可以有粗略的计算方法：

宽 * 高 * 每个像素所占的 bytes
宽度和高度这个很容易获得，那每个像素所占的 bytes 呢，这个主要取决于 decode 图片的方式：

Bitmap.Config     ALPHA_8        Each pixel is stored as a single translucency (alpha) channel.
Bitmap.Config     ARGB_4444      This field is deprecated. Because of the poor quality of this configuration, it is advised to use ARGB_8888 instead. 
Bitmap.Config     ARGB_8888      Each pixel is stored on 4 bytes.
Bitmap.Config     RGB_565        Each pixel is stored on 2 bytes and only the RGB channels are encoded: red is stored with 5 bits of precision (32 possible values), green is store                                 d with 6 bits of precision (64 possible values) and blue is stored with 5 bits of precision.

以上是官方文档对 Bitmap.Config 类的描述，所以，如果以 ARGB_8888 的方式 decode，那个每个像素占用4个 bytes，而如果用 RGB_565 就占用2个 bytes。
我们计算一下，在 2.3 以后，程序自带的图片资源，都默认以 ARGB_8888 的方式，而在此以之前是以 RGB_565 的方式（不确定，待验证），所以颜色会有损耗，典型的就是如果有渐变色的话，会出现光圈。
所以，计算如下：

1600 * 900 * 4 = 5760000
这个 5760000 也就是上面 logcat 错误日志里面所提到的申请数字，当然在实际用命令打印出的内存情况上看，比这个数字要大，是因为这只是图片像素的内存，还有一些属性，变量和类本身没有计算在内。

二.基于Android开发多媒体和游戏应用时，可能会挺经常出现Out Of Memory 异常 ，顾名思义这个异常是说你的内存不够用或者耗尽了。
在Android中，一个Process 只能使用16M内存，如果超过了这个限制就会跳出这个异常。这样就要求我们要时刻想着释放资源。Java的回收工作是交给GC的，如何让GC能及时的回收已经不是用的对象，这个里面有很多技巧，大家可以google一下。
因为总内存的使用超过16M而导致OOM的情况，非常简单，我就不继续展开说。值得注意的是Bitmap在不用时，一定要recycle，不然OOM是非常容易出现的。
本文想跟大家一起讨论的是另一种情况：明明还有很多内存，但是发生OOM了。
这种情况经常出现在生成Bitmap的时候。有兴趣的可以试一下，在一个函数里生成一个13m 的int数组。
再该函数结束后，按理说这个int数组应该已经被释放了，或者说可以释放，这个13M的空间应该可以空出来，
这个时候如果你继续生成一个10M的int数组是没有问题的，反而生成一个4M的Bitmap就会跳出OOM。这个就奇怪了，为什么10M的int够空间，反而4M的Bitmap不够呢？
这个问题困扰很久，在网上，国外各大论坛搜索了很久，一般关于OOM的解释和解决方法都是，如何让GC尽快回收的代码风格之类，并没有实际的支出上述情况的根源。
直到昨天在一个老外的blog上终于看到了这方面的解释，我理解后归纳如下：
在Android中：
1.一个进程的内存可以由2个部分组成：java 使用内存 ，C 使用内存 ，这两个内存的和必须小于16M，不然就会出现大家熟悉的OOM，这个就是第一种OOM的情况。
2.更加奇怪的是这个：一旦内存分配给Java后，以后这块内存即使释放后，也只能给Java的使用，这个估计跟java虚拟机里把内存分成好几块进行缓存的原因有关，反正C就别想用到这块的内存了，所以如果Java突然占用了一个大块内存，即使很快释放了：
C能使用的内存 = 16M - Java某一瞬间占用的最大内存。
而Bitmap的生成是通过malloc进行内存分配的，占用的是C的内存，这个也就说明了，上述的4MBitmap无法生成的原因，因为在13M被Java用过后，剩下C能用的只有3M了。