一、Android内存基础
物理内存与进程内存
物理内存即移动设备上的RAM,当启动一个Android程序时,会启动一个Dalvik VM进程,系统会给它分配固定的内存空间(16M,32M不定),这块内存空间会映射到RAM上某个区域。然后这个Android程序就会运行在这块空间上。Java里会将这块空间分成Stack栈内存和Heap堆内存。stack里存放对象的引用,heap里存放实际对象数据。
在程序运行中会创建对象,如果未合理管理内存,比如不及时回收无效空间就会造成内存泄露,严重的话可能导致使用内存超过系统分配内存,即内存溢出OOM,导致程序卡顿甚至直接退出。
内存泄露(Memory Leak)
Java内存泄漏指的是进程中某些对象(垃圾对象)已经没有使用价值了,但是它们却可以直接或间接地引用到gc roots导致无法被GC回收。Dalvik VM具备的GC机制(垃圾回收机制)会在内存占用过多时自动回收,严重时会造成内存溢出OOM。
内存溢出OOM
当应用程序申请的java heap空间超过Dalvik VM HeapGrowthLimit时,溢出。
注意:OOM并不代表内存不足,只要申请的heap超过Dalvik VM HeapGrowthLimit时,即使内存充足也会溢出。效果是能让较多进程常驻内存。
如果RAM不足时系统会做什么?
Android的Memory Killer会杀死优先级较低的进程,让高优先级进程获取更多内存。
Android系统默认内存回收机制
进程优先级:Foreground进程、Visible进程、Service进程、Background进程、Empty进程;
如果用户按Home键返回桌面,那么该app成为Background进程;如果按Back返回,则成为Empty进程
ActivityManagerService直接管理所有进程的内存资源分配。所有进程要申请或释放内存都需要通过ActivityManagerService对象。
垃圾回收不定期执行。当内存不够时就会遍历heap空间,把垃圾对象删除。
堆内存越大,则GC的时间更长
二、优化
Bitmap优化
Bitmap非常消耗内存,而且在Android中,读取bitmap时, 一般分配给虚拟机的图片堆栈只有8M,所以经常造成OOM问题。所以有必要针对Bitmap的使用作出优化:
图片显示:加载合适尺寸的图片,比如显示缩略图的地方不要加载大图。
图片回收:使用完bitmap,及时使用Bitmap.recycle()回收。
问题:Android不是自身具备垃圾回收机制吗?此处为何要手动回收。
Bitmap对象不是new生成的,而是通过BitmapFactory生产的。而且通过源码可发现是通过调用JNI生成Bitmap对象(nativeDecodeStream()等方法)。所以,加载bitmap到内存里包括两部分,Dalvik内存和Linux kernel内存。前者会被虚拟机自动回收。而后者必须通过recycle()方法,内部调用nativeRecycle()让linux kernel回收。
捕获OOM异常:程序中设定如果发生OOM的应急处理方式。
图片缓存:内存缓存、硬盘缓存等
图片压缩:直接使用ImageView显示Bitmap时会占很多资源,尤其当图片较大时容易发生OOM。可以使用BitMapFactory.Options对图片进行压缩。
图片像素:android默认颜色模式为ARGB_8888,显示质量最高,占用内存最大。若要求不高时可采用RGB_565等模式。图片大小:图片长度*宽度*单位像素所占据字节数
ARGB_4444:每个像素占用2byte内存
ARGB_8888:每个像素占用4byte内存 (默认)
RGB_565:每个像素占用2byte内存
对象引用类型
强引用 strong:Object object=new Object()。当内存不足时,Java虚拟机宁愿抛出OOM内存溢出异常,也不会轻易回收强引用对象来解决内存不足问题;
软引用 soft:只有当内存达到某个阈值时才会去回收,常用于缓存;
弱引用 weak :只要被GC线程扫描到了就进行回收;
虚引用
如果想要避免OOM发生,则使用软引用对象,即当内存快不足时进行回收;如果想尽快回收某些占用内存较大的对象,例如bitmap,可以使用弱引用,能被快速回收。不过如果要对bitmap作缓存就不要使用弱引用,因为很快就会被GC回收,导致缓存失败。
关于java对象引用类型,具体可参加本人另一篇文章
池 pool
对象池:如果某个对象在创建时,需要较大的资源开销,那么可以将其放入对象池,即将对象保存起来,下次需要时直接取出使用,而不用再次创建对象。当然,维护对象池也需要一定开销,故要衡量。
线程池:与对象池差不多,将线程对象放在池中供反复使用,减少反复创建线程的开销。
三、Handler内存泄漏分析及解决
1、介绍
首先,请浏览下面这段handler代码:
public class SampleActivity extends Activity {
private final Handler mLeakyHandler = new Handler() {
@Override
public void handleMessage(Message msg) {
// ...
}
}
}
在使用handler时,这是一段很常见的代码。但是,它却会造成严重的内存泄漏问题。在实际编写中,我们往往会得到如下警告:
In Android, Handler classes should be static or leaks might occur.
那么,handler是如何造成内存泄漏的呢?
2、分析
(1)、Android角度
当Android应用程序启动时,framework会为该应用程序的主线程创建一个Looper对象。这个Looper对象包含一个简单的消息队列Message Queue,并且能够循环的处理队列中的消息。这些消息包括大多数应用程序framework事件,例如Activity生命周期方法调用、button点击等,这些消息都会被添加到消息队列中并被逐个处理。
另外,主线程的Looper对象会伴随该应用程序的整个生命周期。
然后,当主线程里,实例化一个Handler对象后,它就会自动与主线程Looper的消息队列关联起来。所有发送到消息队列的消息Message都会拥有一个对Handler的引用,所以当Looper来处理消息时,会据此回调[Handler#handleMessage(Message)](http://developer.android.com/reference/android/os/Handler.html#handleMessage(android.os.Message)方法来处理消息。
(2)、Java角度
在java里,非静态内部类 和 匿名类 都会潜在的引用它们所属的外部类。但是,静态内部类却不会。
(3)、泄漏来源
请浏览下面一段代码:
public class SampleActivity extends Activity {
private final Handler mLeakyHandler = new Handler() {
@Override
public void handleMessage(Message msg) {
// ...
}
}
@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
// Post a message and delay its execution for 10 minutes.
mLeakyHandler.postDelayed(new Runnable() {
@Override
public void run() { }
}, 1000 * 60 * 10);
// Go back to the previous Activity.
finish();
}
}
当activity结束(finish)时,里面的延时消息在得到处理前,会一直保存在主线程的消息队列里持续10分钟。而且,由上文可知,这条消息持有对handler的引用,而handler又持有对其外部类(在这里,即SampleActivity)的潜在引用。这条引用关系会一直保持直到消息得到处理,从而,这阻止了SampleActivity被垃圾回收器回收,同时造成应用程序的泄漏。
注意,上面代码中的Runnable类--非静态匿名类--同样持有对其外部类的引用。从而也导致泄漏。
3、泄漏解决方案
首先,上面已经明确了内存泄漏来源:
只要有未处理的消息,那么消息会引用handler,非静态的handler又会引用外部类,即Activity,导致Activity无法被回收,造成泄漏;
Runnable类属于非静态匿名类,同样会引用外部类。
为了解决遇到的问题,我们要明确一点:静态内部类不会持有对外部类的引用。所以,我们可以把handler类放在单独的类文件中,或者使用静态内部类便可以避免泄漏。
另外,如果想要在handler内部去调用所在的外部类Activity,那么可以在handler内部使用弱引用的方式指向所在Activity,这样统一不会导致内存泄漏。
对于匿名类Runnable,同样可以将其设置为静态类。因为静态的匿名类不会持有对外部类的引用。
public class SampleActivity extends Activity {
private static class MyHandler extends Handler {
private final WeakReference<SampleActivity> mActivity;
public MyHandler(SampleActivity activity) {
mActivity = new WeakReference<SampleActivity>(activity);
}
@Override
public void handleMessage(Message msg) {
SampleActivity activity = mActivity.get();
if (activity != null) {
// ...
}
}
}
private final MyHandler mHandler = new MyHandler(this);
private static final Runnable sRunnable = new Runnable() {
@Override
public void run() { }
};
@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
// Post a message and delay its execution for 10 minutes.
mHandler.postDelayed(sRunnable, 1000 * 60 * 10);
// Go back to the previous Activity.
finish();
}
}
4、小结
虽然静态类与非静态类之间的区别并不大,但是对于Android开发者而言却是必须理解的。至少我们要清楚,如果一个内部类实例的生命周期比Activity更长,那么我们千万不要使用非静态的内部类。最好的做法是,使用静态内部类,然后在该类里使用弱引用来指向所在的Activity。