Android OOM：内存管理分析和内存泄露原因总结，网易架构师深入讲解 Android 开发
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(p); //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<Callback> (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.
在我们的程序退出时一定要确保我们的资源性对象已经关闭。
8. 一些不良代码成内存压力
有些代码并不造成内存泄露，但是它们或是 对不使用的内存没进行有效及时的释放，或是没有有效的利用已有的对象而是频繁的申请新内存，对内存的回收和分配造成很大影响的。
1) Bitmap 使用不当
及时的销毁
在用完 Bitmap 时，要及时的 bitmap.recycle( )掉。
注意，recycle( )并不能确定立即就会将 Bitmap 释放掉，但是会给虚拟机一个暗示：“该图片可以释放了”。
设置采样率
有时候，我们要显示的区域很小，没有必要将整个图片都加载出来，而只需要记载一个缩小过的图片，这时候可以设置一定的采样率，那么就可以大大减小占用的内存。如下面的代码：
private ImageView preview;
BitmapFactory.Options options = newBitmapFactory.Options();
// 图片宽高都为原来的二分之一，即图片为原来的四分之一
options.inSampleSize = 2;
Bitmap bitmap = BitmapFactory.decodeStream(cr.openInputStream(uri),
null, options); preview.setImageBitmap(bitmap);
巧妙的运用软引用（SoftRefrence）
有些时候，我们使用 Bitmap 后没有保留对它的引用，因此就无法调用 Recycle 函数。这时候巧妙的运用软引用，可以使 Bitmap 在内存快不足时得到有效的释放。如下：
SoftReference<Bitmap> bitmap_ref = new SoftReference<Bitmap>(
BitmapFactory.decodeStream(inputstream));
...
...
if (bitmap_ref .get() != null) {
bitmap_ref.get().recycle();
}
2) 构造 Adapter 时，没有使用缓存的 convertView
初始时 ListView 会从 BaseAdapter 中根据当前的屏幕布局实例化一定数量的 view 对象，同时 ListView 会将这些 view 对象缓存起来。
当向上滚动 ListView 时，原先位于最上面的 list item 的 view 对象会被回收，然后被用来构造新出现的最下面的 list item。这个构造过程就是由
getView()方法完成的，getView()的第二个形参View convertView就是被缓存起来的 list item 的 view 对象 ( 初始化时缓存中没有 view 对象,则 convertView 是 null )。
由此可以看出，如果我们不去使用 convertView，而是每次都在 getView()中重新实例化一个 View 对象的话，即浪费时间，也造成内存垃圾，给垃圾回收增加压力，如果垃圾回收来不及的话，虚拟机将不得不给该应用进程分配更多的内存，造成不必要的内存开支。
3) 不要在经常调用的方法中创建对象，尤其是忌讳在循环中创建对象。
可以适当的使用 hashtable ， vector 创建一组对象容器，然后从容器中去取那些对象，而不用每次 new 之后又丢弃。
9. 查询数据库而没有关闭 Cursor
在 Android 中，Cursor 是很常用的一个对象，但在写代码时，经常会有人忘记调用 close, 或者因为代码逻辑问题状况导致 close 未被调用。
通常，在 Activity 中，我们可以调用 startManagingCursor 或直接使用 managedQuery 让 Activity 自动管理 Cursor 对象。
但需要注意的是，当 Activity 结束后，Cursor 将不再可用！
若操作 Cursor 的代码和 UI 不同步（如后台线程），需要先判断 Activity 是否已经结束，或者在调用 OnDestroy 前，先等待后台线程结束。
除此之外，以下也是比较常见的 Cursor 不会被关闭的情况：
try {
Cursor c = queryCursor();
int a = c.getInt(1);
......
c.close();
} catch (Exception e) {
}
// 虽然表面看起来，Cursor.close()已经被调用
// 但若出现异常，将会跳过 close()，从而导致内存泄露。
// 所以，我们的代码应该以如下的方式编写：
评论