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

1. 进程的地址空间

在32位操作系统中，进程的地址空间为0到4GB,示意图如下：

这里主要说明一下Stack和Heap：

• Stack空间：（进栈和出栈）由操作系统控制，其中主要存储 函数地址、函数参数、局部变量 等等。

所以Stack空间不需要很大，一般为几MB大小。

• **Heap空间：**使用由程序员控制，程序员可以使用malloc、new、free、delete等函数调用来操作这片地址空间。

Heap为程序完成各种复杂任务提供内存空间，所以空间比较大，一般为几百MB到几GB。

正是因为Heap空间由程序员管理，所以容易出现使用不当导致严重问题。

2. 进程内存空间和RAM之间的关系

• 进程的内存空间只是 虚拟内存，而程序的运行需要的是实实在在的内存，即 物理内存（RAM）。

在必要时，操作系统会将程序运行中申请的内存（虚拟内存）映射到RAM，让进程能够使用物理内存。

• 另外，RAM的一部分被操作系统留作他用，比如显存 等等，内存映射和显存等都是由操作系统控制，我们也不必过多地关注它，进程所操作的空间都是虚拟地址空间，无法直接操作RAM 。

3. Android中的进程

1. **native进程：**采用C/C++实现，不包含dalvik实例的linux进程**，/system/bin/目录下面的程序文件运行后都是以native进程形式存在的。比如/system/bin/surfaceflinger、/system/bin/rild、procrank等就是native进程。

2. java进程：实例化了dalvik虚拟机实例的linux进程，进程的入口main函数为java函数。 dalvik虚拟机实例的宿主进程是fork()系统调用创建的linux进程，所以每一个**Android上的java进程实际上就是一个linux进程，只是进程中多了一个dalvik虚拟机实例。**因此，java进程的内存分配比native进程复杂。Android系统中的应用程序基本都是java进程，如桌面、电话、联系人、状态栏等等。

4. Android中进程的堆内存

• heap空间 完全由程序员控制，我们使用malloc、C++ new和java new所申请的空间都是heap空间， C/C++申请的内存空间在native heap中，而java申请的内存空间则在dalvik heap中。

5. Android的 java程序为什么容易出现OOM

• 因为Android系统对dalvik的vm heapsize作了硬性限制，当java进程申请的java空间超过阈值时，就会抛出OOM异常（这个阈值可以是48M、24M、16M等，视机型而定），可以通过adb shell getprop | grep dalvik.vm.heapgrowthlimit 查看此值。

• 也就是说，程序发生OMM并不表示RAM不足，而是因为程序申请的java heap对象超过了dalvik vm heapgrowthlimit。也就是说，在RAM充足的情况下，也可能发生OOM。

• 这样设计的 目的是为了让Android系统能同时让比较多的进程常驻内存，这样程序启动时就不用每次都重新加载到内存，能够给用户更快的响应 。

6. Android如何应对RAM不足

java程序发生OMM并不是表示RAM不足，如果RAM真的不足，会发生什么呢？ 这时Android的 memory killer 会起作用，当RAM所剩不多时，memory killer会杀死一些优先级比较低的进程来释放物理内存，让高优先级程序得到更多的内存。我们在分析log时，看到的进程被杀的log。

Process com.xxx.xxxx(pid xxxx) has died.

7. 应用程序如何绕过dalvikvm heapsize的限制

对于一些大型的应用程序（比如游戏），内存使用会比较多，很容易超超出vm heapsize的限制，这时怎么保证程序不会因为OOM而崩溃呢？

1. 创建子进程

• 创建一个新的进程，那么我们就可以把一些对象分配到新进程的heap上了，从而 达到一个应用程序使用更多的内存的目的，当然，创建子进程会增加系统开销，而且并不是所有应用程序都适合这样做，视需求而定。

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

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

• 因为 native heap 的增长并不受 dalvik vm heapsize 的限制。

• 只要RAM有剩余空间，程序员可以一直在native heap上申请空间，当然如果 RAM快耗尽，memory killer 会杀进程释放 RAM。

• 我们在使用一些软件时，有时候会闪退，就可能是软件在native层申请了比较多的内存导致的。比如 UC web 在浏览内容比较多的网页时可能闪退，原因就是其native heap增长到比较大的值，占用了大量的 RAM，被memory killer杀掉了。

3. 使用显存（操作系统预留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中：

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

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

2. 一旦内存分配给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时的内存问题

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

• Message发出之后是存储在MessageQueue中的，有些Message也不是马上就被处理的。

• 在Message中存在一个 target，是Handler的一个引用，如果Message在Queue中存在的时间越长，就会导致Handler无法被回收。

• 如果Handler是非静态的，则会导致Activity或者Service不会被回收。 所以正确处理Handler等之类的内部类，应该将自己的Handler定义为静态内部类。

2. HandlerThread的使用也需要注意：

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

public classMainActivity extends Activity

{

@Override

public void onCreate(BundlesavedInstanceState)

总结

最后为了帮助大家深刻理解Android相关知识点的原理以及面试相关知识，这里放上相关的我搜集整理的14套腾讯、字节跳动、阿里、百度等2021面试真题解析，我把技术点整理成了视频和PDF（实际上比预期多花了不少精力），包知识脉络 + 诸多细节。

网上学习 Android的资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。希望这份系统化的技术体系对大家有一个方向参考。

网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。

需要这份系统化学习资料的朋友，可以戳这里获取

一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！

…(img-xirAlazS-1714286655008)]

[外链图片转存中…(img-CxwCT1FA-1714286655008)]

[外链图片转存中…(img-1mlfRTVJ-1714286655008)]
网上学习 Android的资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。希望这份系统化的技术体系对大家有一个方向参考。

[外链图片转存中…(img-RpyIN0PD-1714286655008)]

网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。

需要这份系统化学习资料的朋友，可以戳这里获取

一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！