Android OOM：内存管理分析和内存泄露原因总结

最新推荐文章于 2025-02-21 16:40:04 发布

2401_84149824

最新推荐文章于 2025-02-21 16:40:04 发布

阅读量1.1k

点赞数 12

分类专栏：程序员文章标签： android

本文链接：https://blog.csdn.net/2401_84149824/article/details/137533222

版权

程序员专栏收录该内容

119 篇文章

订阅专栏

本文介绍了在Android应用开发中创建子进程的方法，使用JNI在nativeheap上动态申请内存，以及内存泄漏的常见情况，如Bitmap和Java/C内存分配、DalvikGC机制、内存泄漏的几种形式，包括静态内部类、Context泄漏和Handler内存问题。作者强调了正确处理内存释放和资源管理的重要性。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

创建子进程的方法：使用android:process标签

使用jni在 native heap 上申请空间（推荐使用）

因为 native heap 的增长并不受 dalvik vm heapsize 的限制。
只要RAM有剩余空间，程序员可以一直在native heap上申请空间，当然如果 RAM快耗尽，memory killer 会杀进程释放 RAM。
我们在使用一些软件时，有时候会闪退，就可能是软件在native层申请了比较多的内存导致的。比如 UC web 在浏览内容比较多的网页时可能闪退，原因就是其native heap增长到比较大的值，占用了大量的 RAM，被memory killer杀掉了。

使用显存（操作系统预留RAM的一部分作为显存）

使用OpenGL textures等API，texture memory不受dalvik vm heapsize限制，这个没实践过。
再比如Android中的GraphicBufferAllocator申请的内存就是显存。

8. java程序如何才能创建native对象

必须使用 jni，而且应该用C语言的malloc或者C++的new关键字。

实例代码如下：

JNIEXPORT void JNICALLJava_com_example_demo_TestMemory_nativeMalloc(JNIEnv *, jobject)

{

void p= malloc(10241024*);

SLOGD(“allocate 50M Bytes memory”);

if (p !=NULL)

{

//memorywill not used without calling memset()

memset(p,0, 1024102450);

} else SLOGE(“mallocfailure.”);

…

free§; // free memory

}

或者：

JNIEXPORT voidJNICALL Java_com_example_demo_TestMemory_nativeMalloc(JNIEnv *, jobject)

{

SLOGD(“allocate 50M Bytesmemory”);

char *p = new char[1024 * 1024 * 50];

if (p != NULL)

{

//memory will not usedwithout calling memset()

memset(p, 1, 1024102450);

} else SLOGE(“newobject failure.”);

…

free§; //free memory

}

malloc或者new申请的内存是虚拟内存，申请之后不会立即映射到物理内存，即不会占用RAM。只有调用memset使用内存后，虚拟内存才会真正映射到RAM。

9. 明明还有很多内存，但是发生OOM了。。

这种情况经常出现在生成Bitmap的时候。
在一个函数里生成一个13m 的int数组，再该函数结束后，按理说这个int数组应该已经被释放了，或者说可以释放，这个13M的空间应该可以空出来。
这个时候如果你继续生成一个10M的int数组是没有问题的，反而生成一个4M的Bitmap就会跳出OOM。这个就奇怪了，为什么10M的int够空间，反而4M的Bitmap不够呢？

在Android中：

一个进程的内存可以由2个部分组成：java 使用内存，C 使用内存

这两个内存的和必须小于16M，不然就会出现大家熟悉的OOM，这个就是第一种OOM的情况。

一旦内存分配给Java后，以后这块内存即使释放后，也只能给Java的使用

这个估计跟java虚拟机里把内存分成好几块进行缓存的原因有关，反正C就别想用到这块的内存了，所以如果Java突然占用了一个大块内存，即使很快释放了：

C 能使用的内存 = 16M - Java某一瞬间占用的最大内存
而 Bitmap的生成是通过malloc进行内存分配的，占用的是C的内存，这个也就说明了，上述的4MBitmap无法生成的原因，因为在13M被Java用过后，剩下C能用的只有3M了。

二、了解dalvik的Garbage Collection

如图所示：

这里写图片描述

GC会选择一些它了解 还存活的对象 作为 内存遍历的根节点（GC Roots），比方说thread stack中的变量，JNI中的全局变量，zygote中的对象（class loader加载）等，然后开始对heap进行遍历。到最后，部分没有直接或者间接引用到GC Roots的就是需要回收的垃圾，会被GC回收掉。

如下图蓝色部分。

这里写图片描述

三、常见的内存泄漏

1. 非静态内部类的静态实例容易造成内存泄漏

public class MainActivity extends Activity

{

// 非静态内部类的静态实例

static Demo sInstance = null;

@Override

public void onCreate(BundlesavedInstanceState)

{

super.onCreate(savedInstanceState);

setContentView(R.layout.activity_main);

if (sInstance == null) {

sInstance= new Demo();

}

class Demo

{

void doSomething()

{

System.out.print(“dosth.”);

}

上面的代码中的 sInstance 实例 类型为静态实例，在第一个MainActivity act1实例创建时，sInstance会获得并一直持有act1的引用。
当MainAcitivity销毁后重建，因为sInstance持有act1的引用，所以act1是无法被GC回收的，进程中会存在2个MainActivity实例（act1和重建后的MainActivity实例），这个act1对象就是一个无用的但一直占用内存的对象，即无法回收的垃圾对象。
所以，对于lauchMode不是singleInstance的Activity，应该避免在activity里面实例化其非静态内部类的静态实例。

2. Activity使用静态成员

private static Drawable sBackground;

@Override

protected void onCreate(Bundle state) {

super.onCreate(state);

TextView label = new TextView(this);

label.setText(“Leaks are bad”);

if (sBackground == null) {

sBackground = getDrawable(R.drawable.large_bitmap);

}

label.setBackgroundDrawable(sBackground);

setContentView(label);

}

由于用 静态成员sBackground 缓存了drawable对象，所以activity加载速度会加快，但是这样做是错误的。因为在android 2.3系统上，它会导致activity销毁后无法被系统回收。

label .setBackgroundDrawable()调用会将label赋值给sBackground的成员变量 mCallback。

上面代码意味着：sBackground（GC Root）会持有TextView对象，而TextView持有Activity对象。所以导致Activity对象无法被系统回收。

下面看看android4.0为了避免上述问题所做的改进。

先看看android 2.3的Drawable.Java对setCallback的实现：

public final void setCallback(Callback cb){

mCallback = cb;

}

// 在android 2.3中要避免内存泄漏也是可以做到的,

// 在activity的onDestroy时调用

// sBackgroundDrawable.setCallback(null)。

再看看android 4.0的Drawable.Java对setCallback的实现：

public final void setCallback(Callback cb){

mCallback = newWeakReference (cb);

}

以上2个例子的内存泄漏都是因为 Activity的 引用的生命周期 超越了Activity 对象的生命周期。也就是常说的 Context泄漏，因为activity就是context。

3. 避免context相关的内存泄漏，需要注意以下几点

不要对activity的context长期引用

( 一个activity的引用的生存周期应该和activity的生命周期相同 )

如果可以的话，尽量使用关于application的context来替代和activity相关的context
如果一个acitivity的非静态内部类的生命周期不受控制，那么避免使用它；正确的方法是 使用一个静态的内部类，并且对它的外部类有一WeakReference，就像在ViewRootImpl中内部类W所做的那样。

4. 使用handler时的内存问题

我们知道，Handler通过发送Message与主线程交互。

Message发出之后是存储在MessageQueue中的，有些Message也不是马上就被处理的。
在Message中存在一个 target，是Handler的一个引用，如果Message在Queue中存在的时间越长，就会导致Handler无法被回收。
如果Handler是非静态的，则会导致Activity或者Service不会被回收。所以正确处理Handler等之类的内部类，应该将自己的Handler定义为静态内部类。

HandlerThread的使用也需要注意：

当我们在activity里面创建了一个HandlerThread，代码如下：

public classMainActivity extends Activity

{

@Override

public void onCreate(BundlesavedInstanceState)

{

super.onCreate(savedInstanceState);

setContentView(R.layout.activity_main);

Thread mThread = newHandlerThread(“demo”, Process.THREAD_PRIORITY_BACKGROUND);

mThread.start();

MyHandler mHandler = new MyHandler( mThread.getLooper( ) );

…

}

@Override

public void onDestroy()

{

super.onDestroy();

// mThread.getLooper().quit();

}

这个代码存在泄漏问题，因为 HandlerThread的run方法是一个死循环，它不会自己结束，线程的生命周期超过了activity生命周期，当横竖屏切换，HandlerThread线程的数量会随着activity重建次数的增加而增加。
应该在onDestroy时将线程停止掉：mThread.getLooper().quit();

另外，对于不是HandlerThread的线程，也应该确保activity消耗后，线程已经终止，可以这样做：在onDestroy时调用 mThread.join();

join( ) 的作用是：“等待该线程终止”，这里需要理解的就是该线程是指的主线程等待子线程的终止。也就是：在子线程调用了join()方法后面的代码，只有等到子线程结束了才能执行。

5. 注册某个对象后未反注册

比如 注册广播接收器、注册观察者 等等。

假设我们希望在锁屏界面(LockScreen)中，监听系统中的电话服务以获取一些信息(如信号强度等)，则可以在LockScreen中定义一个PhoneStateListener的对象，同时将它注册到TelephonyManager服务中。对于LockScreen对象，当需要显示锁屏界面的时候就会创建一个LockScreen对象，而当锁屏界面消失的时候LockScreen对象就会被释放掉。
但是如果 在释放LockScreen对象的时候忘记取消我们之前注册的PhoneStateListener对象，则会导致LockScreen无法被GC回收。如果不断的使锁屏界面显示和消失，则最终会由于大量的LockScreen对象没有办法被回收而引起OutOfMemory,使得system_process进程挂掉。

虽然有些系统程序，它本身好像是可以自动取消注册的(当然不及时)，但是我们还是 应该在我们的程序中明确的取消注册，程序结束时应该把所有的注册都取消掉。

6. 集合中对象没清理造成的内存泄露

我们通常把一些对象的引用加入到了集合中，当我们不需要该对象时，如果没有把它的引用从集合中清理掉，这样这个集合就会越来越大。如果这个集合是static的话，那情况就更严重了。

比如某公司的ROM的锁屏曾经就存在内存泄漏问题：
这个泄漏是因为LockScreen**每次显示时会注册几个callback**，它们保存在

KeyguardUpdateMonitor的ArrayList<InfoCallback>、

ArrayList<SimStateCallback>

等ArrayList实例中。但是在LockScreen**解锁后，这些callback没有被remove掉**，导致ArrayList不断增大， callback对象不断增多。这些callback对象的size并不大，heap增长比较缓慢，需要长时间地使用手机才能出现OOM，由于锁屏是驻留在system_server进程里，所以导致结果是手机重启。

7. 资源对象没关闭造成的内存泄露

资源性对象 比如(Cursor，File文件等) 往往都用了一些缓冲，我们在不使用的时候，应该及时关闭它们，以便它们的缓冲及时回收内存。它们的缓冲不仅存在于Java虚拟机内，还存在于Java虚拟机外。
如果我们仅仅是把它的引用设置为null,而不关闭它们，往往会造成内存泄露。因为有些资源性对象，比如SQLiteCursor(在析构函数finalize(),如果我们没有关闭它，它自己会调close()关闭)，如果我们没有关闭它，系统在回收它时也会关闭它，但是这样的效率太低了。因此对于资源性对象在不使用的时候，应该立即调用它的close()函数，将其关闭掉，然后再置为null.
在我们的程序退出时一定要确保我们的资源性对象已经关闭。