Android内存泄漏终极解决篇（下）
转载 &更新时间：日 10:08:59 & 作者：Huang_Cai_Yuan
这篇文章主要为大家介绍了Android内存泄漏的相关资料，哪些写法容易造成内存泄漏，该如何解决？感兴趣的小伙伴们可以参考一下
在 中我们介绍了如何检查一个App是否存在内存泄漏的问题，本篇将总结典型的内存泄漏的代码，并给出对应的解决方案。内存泄漏的主要问题可以分为以下几种类型：
静态变量引起的内存泄漏
非静态内部类引起的内存泄漏
资源未关闭引起的内存泄漏
二、静态变量引起的内存泄漏
在java中静态变量的生命周期是在类加载时开始，类卸载时结束。换句话说，在android中其生命周期是在进程启动时开始，进程死亡时结束。所以在程序的运行期间，如果进程没有被杀死，静态变量就会一直存在，不会被回收掉。如果静态变量强引用了某个Activity中变量，那么这个Activity就同样也不会被释放,即便是该Activity执行了onDestroy(不要将执行onDestroy和被回收划等号)。这类问题的解决方案为：1.寻找与该静态变量生命周期差不多的替代对象。2.若找不到，将强引用方式改成弱引用。比较典型的例子如下:
单例引起的Context内存泄漏
public class IMManager {
private static IMManager mI
public static IMManager getInstance(Context context) {
if (mInstance == null) {
synchronized (IMManager.class) {
if (mInstance == null)
mInstance = new IMManager(context);
private IMManager(Context context) {
this.context =
当调用getInstance时，如果传入的context是Activity的context。只要这个单例没有被释放，这个Activity也不会被释放。
传入Application的context,因为Application的context的生命周期比Activity长，可以理解为Application的context与单例的生命周期一样长，传入它是最合适的。
public class IMManager {
private static IMManager mI
public static IMManager getInstance(Context context) {
if (mInstance == null) {
synchronized (IMManager.class) {
if (mInstance == null)
//将传入的context转换成Application的context
mInstance = new IMManager(context.getApplicationContext());
private IMManager(Context context) {
this.context =
三、非静态内部类引起的内存泄漏
在java中，创建一个非静态的内部类实例，就会引用它的外围实例。如果这个非静态内部类实例做了一些耗时的操作，就会造成外围对象不会被回收，从而导致内存泄漏。这类问题的解决方案为：1.将内部类变成静态内部类 2.如果有强引用Activity中的属性，则将该属性的引用方式改为弱引用。3.在业务允许的情况下，当Activity执行onDestory时，结束这些耗时任务。
内部线程造成的内存泄漏
public class LeakAty extends Activity {
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.aty_leak);
public void test() {
//匿名内部类会引用其外围实例LeakAty.this,所以会导致内存泄漏
new Thread(new Runnable() {
public void run() {
while (true) {
Thread.sleep(1000);
} catch (InterruptedException e) {
e.printStackTrace();
}).start();
将非静态匿名内部类修改为静态匿名内部类
public class LeakAty extends Activity {
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.aty_leak);
//加上static，变成静态匿名内部类
public static void test() {
new Thread(new Runnable() {
public void run() {
while (true) {
Thread.sleep(1000);
} catch (InterruptedException e) {
e.printStackTrace();
}).start();
Handler引起的内存泄漏
public class LeakAty extends Activity {
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.aty_leak);
fetchData();
private Handler mHandler = new Handler() {
public void handleMessage(android.os.Message msg) {
switch (msg.what) {
// 刷新数据
private void fetchData() {
//获取数据
mHandler.sendEmptyMessage(0);
mHandler 为匿名内部类实例，会引用外围对象LeakAty.this,如果该Handler在Activity退出时依然还有消息需要处理，那么这个Activity就不会被回收。
public class LeakAty extends Activity {
private TextView tvR
private MyH
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.aty_leak);
tvResult = (TextView) findViewById(R.id.tvResult);
handler = new MyHandler(this);
fetchData();
//第一步，将Handler改成静态内部类。
private static class MyHandler extends Handler {
//第二步，将需要引用Activity的地方，改成弱引用。
private WeakReference&LeakAty& atyI
public MyHandler(LeakAty aty) {
this.atyInstance = new WeakReference&LeakAty&(aty);
public void handleMessage(Message msg) {
super.handleMessage(msg);
LeakAty aty = atyInstance == null ? null : atyInstance.get();
//如果Activity被释放回收了，则不处理这些消息
if (aty == null||aty.isFinishing()) {
aty.tvResult.setText("fetch data success");
private void fetchData() {
// 获取数据
handler.sendEmptyMessage(0);
protected void onDestroy() {
//第三步，在Activity退出的时候移除回调
super.onDestroy();
handler.removeCallbacksAndMessages(null);
四、资源未关闭引起的内存泄漏
当使用了BraodcastReceiver、Cursor、Bitmap等资源时，当不需要使用时，需要及时释放掉，若没有释放，则会引起内存泄漏。
综上所述，内存泄漏的主要情况为上面的三大类型，最终归结为一点，就是资源在不需要的时候没有被释放掉。所以在编码的过程中要注意这些细节，提高程序的性能。
您可能感兴趣的文章:
大家感兴趣的内容
12345678910
最近更新的内容
常用在线小工具5个Android开发中比较常见的内存泄漏问题及解决办法
5个Android开发中比较常见的内存泄漏问题及解决办法
在Android开发中，内存泄漏是比较常见的问题，有过一些Android编程经历的童鞋应该都遇到过，但为什么会出现内存泄漏呢?内存泄漏又有什么影响呢?
在Android程序开发中，当一个对象已经不需要再使用了，本该被回收时，而另外一个正在使用的对象持有它的引用从而导致它不能被回收，这就导致本该被回收的对象不能被回收而停留在堆内存中，内存泄漏就产生了。
内存泄漏有什么影响呢?它是造成应用程序OOM的主要原因之一。由于Android系统为每个应用程序分配的内存有限，当一个应用中产生的内存泄漏比较多时，就难免会导致应用所需要的内存超过这个系统分配的内存限额，这就造成了内存溢出而导致应用Crash。
了解了内存泄漏的原因及影响后，我们需要做的就是掌握常见的内存泄漏，并在以后的Android程序开发中，尽量避免它。下面小编搜罗了5个Android开发中比较常见的内存泄漏问题及解决办法，分享给大家，一起来看看吧。
一、单例造成的内存泄漏
Android的单例模式非常受开发者的喜爱，不过使用的不恰当的话也会造成内存泄漏。因为单例的静态特性使得单例的生命周期和应用的生命周期一样长，这就说明了如果一个对象已经不需要使用了，而单例对象还持有该对象的引用，那么这个对象将不能被正常回收，这就导致了内存泄漏。
如下这个典例：
public&class&AppManager&{
&&&&private&static&AppManager&
&&&&private&Context&
&&&&private&AppManager(Context&context)&{
&&&&&&&&this.context&=&
&&&&public&static&AppManager&getInstance(Context&context)&{
&&&&&&&&if&(instance&==&null)&{
&&&&&&&&&&&&instance&=&new&AppManager(context);
&&&&&&&&return&
这是一个普通的单例模式，当创建这个单例的时候，由于需要传入一个Context，所以这个Context的生命周期的长短至关重要：
1、传入的是Application的Context：这将没有任何问题，因为单例的生命周期和Application的一样长 ;
2、传入的是Activity的Context：当这个Context所对应的Activity退出时，由于该Context和Activity的生命周期一样长(Activity间接继承于Context)，所以当前Activity退出时它的内存并不会被回收，因为单例对象持有该Activity的引用。
所以正确的单例应该修改为下面这种方式：
public&class&AppManager&{
&&&&private&static&AppManager&
&&&&private&Context&
&&&&private&AppManager(Context&context)&{
&&&&&&&&this.context&=&context.getApplicationContext();
&&&&public&static&AppManager&getInstance(Context&context)&{
&&&&&&&&if&(instance&!=&null)&{
&&&&&&&&&&&&instance&=&new&AppManager(context);
&&&&&&&&return&
这样不管传入什么Context最终将使用Application的Context，而单例的生命周期和应用的一样长，这样就防止了内存泄漏。
二、非静态内部类创建静态实例造成的内存泄漏
有的时候我们可能会在启动频繁的Activity中，为了避免重复创建相同的数据资源，会出现这种写法：
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内部创建了一个非静态内部类的单例，每次启动Activity时都会使用该单例的数据，这样虽然避免了资源的重复创建，不过这种写法却会造成内存泄漏，因为非静态内部类默认会持有外部类的引用，而又使用了该非静态内部类创建了一个静态的实例，该实例的生命周期和应用的一样长，这就导致了该静态实例一直会持有该Activity的引用，导致Activity的内存资源不能正常回收。正确的做法为：
将该内部类设为静态内部类或将该内部类抽取出来封装成一个单例，如果需要使用Context，请使用ApplicationContext 。
三、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(){
&&&&&&&&Message&message&=&Message.obtain();
&&&&&&&&mHandler.sendMessage(message);
这种创建Handler的方式会造成内存泄漏，由于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&&
&&&&&&&&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()&{
&&&&&&&&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&&
&&&&&&&&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()&{
&&&&&&&&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&&weakR
&&&&&&&&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编程中，常见的5大内存泄漏问题及相应的解决办法，如果大家在编程中遇到了上述泄漏问题，不妨可以试试对应的方法。如果大家还有什么疑问，可以去“学习问答”版块直接提出。
没有更多推荐了，Android常见的几种内存泄漏小结_百度知道
Android常见的几种内存泄漏小结
我有更好的答案
1：内存oom，比处理图片，加载图片过大撑爆内存2：对象引用持有，不能释放导致运行内存越来越大知道oom
为您推荐：
其他类似问题
您可能关注的内容
换一换
回答问题，赢新手礼包
个人、企业类
违法有害信息,请在下方选择后提交
色情、暴力
我们会通过消息、邮箱等方式尽快将举报结果通知您。Android开发过程中比较常见的内存泄漏现象及相应的解决办法
在Android开发中，内存泄漏是比较常见的问题，有过一些Android编程经历的童鞋应该都遇到过，但为什么会出现内存泄漏呢?内存泄漏又有什么影响呢?
在Android程序开发中，当一个对象已经不需要再使用了，本该被回收时，而另外一个正在使用的对象持有它的引用从而导致它不能被回收，这就导致本该被回收的对象不能被回收而停留在堆内存中，内存泄漏就产生了。
内存泄漏有什么影响呢?它是造成应用程序OOM的主要原因之一。由于Android系统为每个应用程序分配的内存有限，当一个应用中产生的内存泄漏比较多时，就难免会导致应用所需要的内存超过这个系统分配的内存限额，这就造成了内存溢出而导致应用Crash。
了解了内存泄漏的原因及影响后，我们需要做的就是掌握常见的内存泄漏，并在以后的Android程序开发中，尽量避免它。下面5个Android开发中比较常见的内存泄漏问题及解决办法，分享给大家，一起来看看吧。
一、单例造成的内存泄漏
Android的单例模式非常受开发者的喜爱，不过使用的不恰当的话也会造成内存泄漏。因为单例的静态特性使得单例的生命周期和应用的生命周期一样长，这就说明了如果一个对象已经不需要使用了，而单例对象还持有该对象的引用，那么这个对象将不能被正常回收，这就导致了内存泄漏。
如下这个典例：public class AppManager {
private static AppM
private AppManager(Context context) {
this.context =
public static AppManager getInstance(Context context) {
if (instance != null) {
instance = new AppManager(context);
这是一个普通的单例模式，当创建这个单例的时候，由于需要传入一个Context，所以这个Context的生命周期的长短至关重要：
1、传入的是Application的Context：这将没有任何问题，因为单例的生命周期和Application的一样长 ;
2、传入的是Activity的Context：当这个Context所对应的Activity退出时，由于该Context和Activity的生命周期一样长(Activity间接继承于Context)，所以当前Activity退出时它的内存并不会被回收，因为单例对象持有该Activity的引用。
所以正确的单例应该修改为下面这种方式：
public class AppManager {
private static AppM
private AppManager(Context context) {
this.context = context.getApplicationContext();
public static AppManager getInstance(Context context) {
if (instance != null) {
instance = new AppManager(context);
}这样不管传入什么Context最终将使用Application的Context，而单例的生命周期和应用的一样长，这样就防止了内存泄漏。
二、非静态内部类创建静态实例造成的内存泄漏
有的时候我们可能会在启动频繁的Activity中，为了避免重复创建相同的数据资源，会出现这种写法：
public class MainActivity extends AppCompatActivity {
private static TestResource mResource =
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_main);
if(mManager == null){
mManager = new TestResource();
class TestResource {
这样就在Activity内部创建了一个非静态内部类的单例，每次启动Activity时都会使用该单例的数据，这样虽然避免了资源的重复创建，不过这种写法却会造成内存泄漏，因为非静态内部类默认会持有外部类的引用，而又使用了该非静态内部类创建了一个静态的实例，该实例的生命周期和应用的一样长，这就导致了该静态实例一直会持有该Activity的引用，导致Activity的内存资源不能正常回收。正确的做法为：将该内部类设为静态内部类或将该内部类抽取出来封装成一个单例，如果需要使用Context，请使用ApplicationContext
三、Handler造成的内存泄漏
Handler的使用造成的内存泄漏问题应该说最为常见了，平时在处理网络任务或者封装一些请求回调等api都应该会借助Handler来处理，对于Handler的使用代码编写一不规范即有可能造成内存泄漏，如下示例：
public class MainActivity extends AppCompatActivity {
private Handler mHandler = new Handler() {
public void handleMessage(Message msg) {
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);
}这种创建Handler的方式会造成内存泄漏，由于mHandler是Handler的非静态匿名内部类的实例，所以它持有外部类Activity的引用，我们知道消息队列是在一个Looper线程中不断轮询处理消息，那么当这个Activity退出时消息队列中还有未处理的消息或者正在处理消息，而消息队列中的Message持有mHandler实例的引用，mHandler又持有Activity的引用，所以导致该Activity的内存资源无法及时回收，引发内存泄漏，所以另外一种做法为：
public class MainActivity extends AppCompatActivity {
private MyHandler mHandler = new MyHandler(this);
private TextView mTextV
private static class MyHandler extends Handler {
private WeakReference&Context&
public MyHandler(Context context) {
reference = new WeakReference&&(context);
public void handleMessage(Message msg) {
MainActivity activity = (MainActivity) reference.get();
if(activity != null){
activity.mTextView.setText("");
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 mTextV
private static class MyHandler extends Handler {
private WeakReference&Context&
public MyHandler(Context context) {
reference = new WeakReference&&(context);
public void handleMessage(Message msg) {
MainActivity activity = (MainActivity) reference.get();
if(activity != null){
activity.mTextView.setText("");
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);
protected void onDestroy() {
super.onDestroy();
mHandler.removeCallbacksAndMessages(null);
}使用mHandler.removeCallbacksAndMessages(null);是移除消息队列中所有消息和所有的Runnable。当然也可以使用mHandler.removeCallbacks();或mHandler.removeMessages()；来移除指定的Runnable和Message。
四、线程造成的内存泄漏
对于线程造成的内存泄漏，也是平时比较常见的，如下这两个示例可能每个人都这样写过：
//——————test1
new AsyncTask&Void, Void, Void&() {
protected Void doInBackground(Void... params) {
SystemClock.sleep(10000);
}.execute();
//——————test2
new Thread(new Runnable() {
public void run() {
SystemClock.sleep(10000);
}).start();上面的异步任务和Runnable都是一个匿名内部类，因此它们对当前Activity都有一个隐式引用。如果Activity在销毁之前，任务还未完成， 那么将导致Activity的内存资源无法回收，造成内存泄漏。正确的做法还是使用静态内部类的方式，如下：
static class MyAsyncTask extends AsyncTask&Void, Void, Void& {
private WeakReference&Context& weakR
public MyAsyncTask(Context context) {
weakReference = new WeakReference&&(context);
protected Void doInBackground(Void... params) {
SystemClock.sleep(10000);
protected void onPostExecute(Void aVoid) {
super.onPostExecute(aVoid);
MainActivity activity = (MainActivity) weakReference.get();
if (activity != null) {
static class MyRunnable implements Runnable{
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销毁时及时关闭或者注销，否则这些资源将不会被回收，造成内存泄漏。
没有更多推荐了，