周末去上海参加了安卓巴士组织的技术论坛,去了才发现自己基础很渣。。。。。

其中提到了android的内存泄漏的问题,回来马上度娘(虽说度娘很渣),整理如下:

一、单例造成的内存泄漏

因为单例的静态特性使得单例的生命周期和应用的生命周期一样长,如果一个对象已经不需要使用了,但是单例持有该对象的引用,就会导致无法回收该对象造成内存泄漏。。。

上代码:

public class AppManager {
private static AppManager instance;
private Context context;
private AppManager(Context context) {
this.context = context;
}
public static AppManager getInstance(Context context) {
if (instance != null) {
instance = new AppManager(context);
}
return instance;
}
}

当创建这个单例的时候,需要传入一个Context对象,如果是Application,没有任何的问题,因为单例和Application的生命周期是一样长的,但是如果传入的是一个Activity,当Activity退出的时候,将不会被回收。

所以正确的方式应该如下:

public class AppManager {
private static AppManager instance;
private Context context;
private AppManager(Context context) {
this.context = context.getApplicationContext();
}
public static AppManager getInstance(Context context) {
if (instance != null) {
instance = new AppManager(context);
}
return instance;
}
}

二、非静态内部类创建静态实例造成的内存泄漏

反正我是觉得很拗口。。。。

直接上代码:

public class MainActivity extends AppCompatActivity {
private static TestResource mResource = null;
@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_main);
if(mManager == null){
mManager = new TestResource();
}
//...
}
class TestResource {
//...
}
}

非静态内部类默认持有外部类的引用,又创建了个静态变量,该变量和应用具有相同的生命周期,又持有Activity的应用,所以会导致内存泄漏。

三、Handler造成的内存泄漏

Handler的使用造成的内存泄漏问题应该说最为常见了,平时在处理网络任务或者封装一些请求回调等api都应该会借助Handler来处理,对于Handler的使用代码编写一不规范即有可能造成内存泄漏

public class MainActivity extends AppCompatActivity {
private Handler mHandler = new Handler() {
@Override
public void handleMessage(Message msg) {
//...
}
};
@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_main);
loadData();
}
private void loadData(){
//...request
Message message = Message.obtain();
mHandler.sendMessage(message);
}
}

一看这个代码。。。。我去,我就不经常这么写的吗??????蒙圈了。。。。。有什么问题呢,分析看看

由于mHandler是Handler的非静态匿名内部类的实例,所以它持有外部类Activity的引用,我们知道消息队列是在一个Looper线程中不断轮询处理消息,那么当这个Activity退出时消息队列中还有未处理的消息或者正在处理消息,而消息队列中的Message持有mHandler实例的引用,mHandler又持有Activity的引用,所以导致该Activity的内存资源无法及时回收,引发内存泄漏。。。。。

正确写法:

public class MainActivity extends AppCompatActivity {
private MyHandler mHandler = new MyHandler(this);
private TextView mTextView ;
private static class MyHandler extends Handler {
private WeakReference<Context> reference;
public MyHandler(Context context) {
reference = new WeakReference<>(context);
}
@Override
public void handleMessage(Message msg) {
MainActivity activity = (MainActivity) reference.get();
if(activity != null){
activity.mTextView.setText("");
}
}
} @Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_main);
mTextView = (TextView)findViewById(R.id.textview);
loadData();
} private void loadData() {
//...request
Message message = Message.obtain();
mHandler.sendMessage(message);
}
}

创建一个静态Handler内部类,然后对Handler持有的对象使用弱引用,这样在回收时也可以回收Handler持有的对象,这样虽然避免了Activity泄漏,不过Looper线程的消息队列中还是可能会有待处理的消息,所以我们在Activity的Destroy时或者Stop时应该移除消息队列中的消息,更准确的做法如下:

public class MainActivity extends AppCompatActivity {
private MyHandler mHandler = new MyHandler(this);
private TextView mTextView ;
private static class MyHandler extends Handler {
private WeakReference<Context> reference;
public MyHandler(Context context) {
reference = new WeakReference<>(context);
}
@Override
public void handleMessage(Message msg) {
MainActivity activity = (MainActivity) reference.get();
if(activity != null){
activity.mTextView.setText("");
}
}
} @Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_main);
mTextView = (TextView)findViewById(R.id.textview);
loadData();
} private void loadData() {
//...request
Message message = Message.obtain();
mHandler.sendMessage(message);
} @Override
protected void onDestroy() {
super.onDestroy();
mHandler.removeCallbacksAndMessages(null);
}
}

使用mHandler.removeCallbacksAndMessages(null);是移除消息队列中所有消息和所有的Runnable。当然也可以使用mHandler.removeCallbacks();或mHandler.removeMessages();来移除指定的Runnable和Message。

四、线程造成的内存泄漏

new AsyncTask<Void, Void, Void>() {
@Override
protected Void doInBackground(Void... params) {
SystemClock.sleep(10000);
return null;
}
}.execute();
new Thread(new Runnable() {
@Override
public void run() {
SystemClock.sleep(10000);
}
}).start();

上面的异步任务和Runnable都是一个匿名内部类,因此它们对当前Activity都有一个隐式引用。如果Activity在销毁之前,任务还未完成, 那么将导致Activity的内存资源无法回收,造成内存泄漏。正确的做法还是使用静态内部类的方式,如下:

    static class MyAsyncTask extends AsyncTask<Void, Void, Void> {
private WeakReference<Context> weakReference; public MyAsyncTask(Context context) {
weakReference = new WeakReference<>(context);
} @Override
protected Void doInBackground(Void... params) {
SystemClock.sleep(10000);
return null;
} @Override
protected void onPostExecute(Void aVoid) {
super.onPostExecute(aVoid);
MainActivity activity = (MainActivity) weakReference.get();
if (activity != null) {
//...
}
}
}
static class MyRunnable implements Runnable{
@Override
public void run() {
SystemClock.sleep(10000);
}
}
//——————
new Thread(new MyRunnable()).start();
new MyAsyncTask(this).execute();

这样就避免了Activity的内存资源泄漏,当然在Activity销毁时候也应该取消相应的任务AsyncTask::cancel(),避免任务在后台执行浪费资源。

五、资源未关闭造成的内存泄漏

对于使用了BraodcastReceiver,ContentObserver,File,Cursor,Stream,Bitmap等资源的使用,应该在Activity销毁时及时关闭或者注销,否则这些资源将不会被回收,造成内存泄漏。

Android内存泄漏分析的更多相关文章

  1. Android 内存泄漏分析与解决方法

    在分析Android内存泄漏之前,先了解一下JAVA的一些知识 1. JAVA中的对象的创建 使用new指令生成对象时,堆内存将会为此开辟一份空间存放该对象 垃圾回收器回收非存活的对象,并释放对应的内 ...

  2. Android内存泄漏分析及调试

    尊重原创作者,转载请注明出处: http://blog.csdn.net/gemmem/article/details/13017999 此文承接我的另一篇文章:Android进程的内存管理分析 首先 ...

  3. Android内存泄漏分析实战

    内存泄漏简单介绍 java能够保证当没有引用指向对象的时候,对象会被垃圾回收器回收.与c语言自己申请的内存自己释放相比,java程序猿轻松了非常多.可是并不代表java程序猿不用操心内存泄漏.当jav ...

  4. (转)Android内存泄漏分析及调试

      http://blog.csdn.net/gemmem/article/details/13017999 此文承接我的另一篇文章:Android进程的内存管理分析  首先了解一下dalvik的Ga ...

  5. android 内存泄漏分析技巧

    java虚拟机执行一般都有一个内存界限,超过这个界限,就会报outofmemory.这个时候一般都是存在内存泄漏.解决内存泄漏问题,窃以为分为两个步骤:分析应用程序是否真的有内存泄漏,找到内存泄漏的地 ...

  6. Android 内存泄漏分析利器——leakcanary

    LeakCanary Android 和 Java 内存泄露检测. “A small leak will sink a great ship.” - Benjamin Franklin 千里之堤, 毁 ...

  7. Android 内存管理分析(四)

    尊重原创作者,转载请注明出处: http://blog.csdn.net/gemmem/article/details/8920039 最近在网上看了不少Android内存管理方面的博文,但是文章大多 ...

  8. Android内存泄漏的检测流程、捕捉以及分析

    https://blog.csdn.net/qq_20280683/article/details/77964208 Android内存泄漏的检测流程.捕捉以及分析 简述: 一个APP的性能,重度关乎 ...

  9. Android内存机制分析1——了解Android堆和栈

    //----------------------------------------------------------------------------------- Android内存机制分析1 ...

随机推荐

  1. 黄聪:主机宝安装wordpress注意事项

    1.web环境安装PHP使用5.4.21-nts-03版本 2.web环境安装Mysql使用5.5.45版本 3.创建好站点后,给站点的public_html目录添加IIS_xxx用户最高权限,添加N ...

  2. 黄聪:Xmind修改默认字体风格设置

    Xmind是一款非常好用的思维导图软件,但默认字体使用宋体不够好看,软件本身不支持设置默认字体,但通过修改配置文件达到配置默认字体的目的 默认控制风格的配置文件位置 XMind\plugins\org ...

  3. ScalaTour 2.函数

    /** * 1. case class与模式匹配 */ object TestFunction extends App{ def value(expr:Expr): Int = expr match ...

  4. Linux 下 MySQL 的彻底卸载和安装配置字符集

    前言: Linux环境下MySQL的安装和配置在网上已经有很多教程了.之所以写这篇文章是因为在配置字符集的时候找了网上的一些教程发现并不能用导致折腾了一阵子.下面的教程均是亲自实践. MySQL的彻底 ...

  5. Tomcat的ServletAPI与Jetty的不能混用,否则会出现Serlvt类无法编译

  6. CF109 C. Lucky Tree 并查集

    Petya loves lucky numbers. We all know that lucky numbers are the positive integers whose decimal re ...

  7. 深入分析ConcurrentHashMap(转)

    线程不安全的HashMap 因为多线程环境下,使用HashMap进行put操作会引起死循环,导致CPU利用率接近100%,所以在并发情况下不能使用HashMap,如以下代码 final HashMap ...

  8. 按钮/文本框 disabled

    需求:已登入的,将用户的信息回填,用户文本框内容不能更改. 按钮: <button type="button" id="btnSearch">< ...

  9. 如何给ubuntu虚拟机添加硬盘和快捷键(转载)

    From:http://os.51cto.com/art/201003/188721.htm 刚开始建立Ubuntu虚拟机时间,把容量设置为8Gb 了,然后没过几天就没有地方了,郁闷!查了一下,有几种 ...

  10. mysql中游标的使用

    BEGIN #遍历占领野地表还原军队 # and cityid=cityid) ,) ;#occupyWild表的TroopsId ,) ;#occupyWild表的CityId ,) ;#occup ...