androidcontext内存泄露

‘壹’ 如何定位和解决android的内存溢出问题（大总

一、定位内存泄漏：
可以用LeakCanary:检测所有的内存泄漏
http://www.jcodecraeer.com/a/anzhuokaifa/androidkaifa/2015/0509/2854.html
二、解决：
1.对各种流，文件资源这些比如：InputStream/OutputStream，SQLiteOpenHelper，SQLiteDatabase，Cursor，文件，I/O，Bitmap图片等操作等都应该记得显示关闭。

2.尽量避免static成员变量引用资源耗费过多的实例,比如Context。因为Context的引用超过它本身的生命周期，会导致Context泄漏。所以尽量使用Application这种Context类型。
3.使用线程池，不要newthread
4.UI视图检查，减少视图层级（hierarchyviewer）。
5.图片优化
6. 重用系统资源：系统定义id，系统图片，系统布局，系统style，系统字符串，系统颜色定义

‘贰’ 使用ConnectivityManager的内存泄漏隐患

Android里面内存泄漏问题最突出的就是Activity的泄漏，而泄漏的根源大多在于单例的使用，也就是一个静态实例持有了Activity的引用。静态变量的生命周期与应用（Application）是相同的，而键启Activity生命周期通常比它短，也就会造成在Activity生命周期结束后，还被引用导致无法被系统回收释放。

生成静态引用内存泄漏可能有两种情况：

这个主要讲下系统级的情况，这样的情况可能也有很多，举个最近发现的问题ConnectivityManager。

通常我们获取系统服务时采用如下方式：

在Android6.0系统上，如果这里的Context如果是Activity的实例，那么即使你什么也不干也会造成内存泄漏。

用LeakCanary可以直接看到内存泄漏：

一步一步来分析下。

先从Context的getSystemService方法开始，我们知道Activity是从ContextWrapper继承而来的，ContextWrapper中持有一个mBase实例，这个实例指向一个ContextImpl对象，同时ContextImpl对象持有一个OuterContext对象，对于Activity来说，这个OuterContext就是Activity对象。所以调用getSystemService最终会调用到ContextImpl的getSystemService方法。

在6.0上 ContextImpl 的getSystemService方法调用 SystemServiceRegistry 来完成。

SystemServiceRegistry提供ConnectivityManager的实例。

在6.0上， ConnectivityManager 实现为单例：

精彩的部分来了，ConnectivityManager 持庆亮贺有了一个Context的引用：

这个Context在ConnectivityManager 创建时传入，这个Context在中由ContextImpl对象转换为OuterContext，与就是Activity对象，所以最终ConnectivityManager的单实例持有了Activity的实例引用。这样即使Activity退出后仍然无法释放，导致誉派内存泄漏。

这个问题仅在6.0上出现，在5.1上ConnectivityManager实现为单例但不持有Context的引用，在5.0有以下版本ConnectivityManager既不为单例，也不持有Context的引用。

其他服务没认真研究，不确定有没有这个问题。不过为了避免类似的情况发生，最好的解决办法就是：

‘叁’ android 内存泄露 会导致什么问题

1. 查询数据库而没有关闭Cursor
在Android中，Cursor是很常用的一个对象，但在写代码是，经常会有人忘记调用close, 或者因为代码逻辑问题状况导致close未被调用。
通常，在Activity中，我们可以调用startManagingCursor或直接使用managedQuery让Activity自动管理Cursor对象。
但需要注意的是，当Activity介绍后，Cursor将不再可用！
若操作Cursor的代码和UI不同步（如后台线程），那没需要先判断Activity是否已经结束，或者在调用OnDestroy前，先等待后台线程结束。
除此之外，以下也是比较常见的Cursor不会被关闭的情况：
虽然表面看起来，Cursor.close()已经被调用，但若出现异常，将会跳过close()，从而导致内存泄露。
所以，我们的代码应该以如下的方式编写：
Cursor c = queryCursor();
try {
int a = c.getInt(1);
......
} catch (Exception e) {
} finally {
c.close(); //在finally中调用close(), 保证其一定会被调用
}
try {
Cursor c = queryCursor();
int a = c.getInt(1);
......
c.close();
} catch (Exception e) {
}
2. 调用registerReceiver后未调用unregisterReceiver().
在调用registerReceiver后，若未调用unregisterReceiver，其所占的内存是相当大的。
而我们经常可以看到类似于如下的代码：
这是个很严重的错误，因为它会导致BroadcastReceiver不会被unregister而导致内存泄露。
registerReceiver(new BroadcastReceiver() {
...
}, filter); ...

3. 未关闭InputStream/OutputStream

在使用文件或者访问网络资源时，使用了InputStream/OutputStream也会导致内存泄露
4. Bitmap使用后未调用recycle()
根据SDK的描述，调用recycle并不是必须的。但在实际使用时，Bitmap占用的内存是很大的，所以当我们不再使用时，尽量调用recycle()以释放资源。
5. Context泄露
这是一个很隐晦的内存泄露的情况。
先让我们看一下以下代码：
在这段代码中，我们使用了一个static的Drawable对象。
这通常发生在我们需要经常调用一个Drawable，而其加载又比较耗时，不希望每次加载Activity都去创建这个Drawable的情况。
此时，使用static无疑是最快的代码编写方式，但是其也非常的糟糕。
当一个Drawable被附加到View时，这个View会被设置为这个Drawable的callback (通过调用Drawable.setCallback()实现)。
这就意味着，这个Drawable拥有一个TextView的引用，而TextView又拥有一个Activity的引用。
这就会导致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);
}

‘肆’ Android线程泄漏场景以及解决办法

1.非静态内部类的静态实例

非静态内部类会持有外部类的引用，如果非静态内部类的实例是静态的，就会长期的维持着外部类的引用，组织被系统回收，解决办法是使用静态内部类

2.多线程相关的匿名内部类和非静态内部类

匿名内部类同样会持有外部类的引用，如果在线程中执行耗时操作就有可能发生内存泄漏，导致外部类无法被回收，直到耗时任务结束，解决办法是在页面退出时结束线程中的任务

3.Handler内存泄漏

Handler导致的内存泄漏也可以被归纳为非静态内部类导致的，Handler内部message是被存储在MessageQueue中的，有些message不能马上被处理，存在的时间会很长，导致handler无法被回收，如果handler是非静态的，就会导致它的外部类无法被回收，解决办法是1.使用静态handler，外部类引用使用弱引用处理2.在退出页面时移除消息队列中的消息

4.Context导致内存泄漏

根据场景确定使用Activity的Context还是Application的Context,因为二者生命周期不同，对于不必须使用Activity的Context的场景（Dialog）,一律采用Application的Context,单例模式是最常见的发生此泄漏的场景，比如传入一个Activity的Context被静态类引用，导致无法回收

5.静态View导致泄漏

使用静态View可以避免每次启动Activity都去读取并渲染View，但是静态View会持有Activity的引用，导致无法回收，解决办法是在Activity销毁的时候将静态View设置为null（View一旦被加载到界面中将会持有一个Context对象的引用，在这个例子中，这个context对象是我们的Activity，声明一个静态变量引用这个View，也就引用了activity）

6.WebView导致的内存泄漏

WebView只要使用一次，内存就不会被释放，所以WebView都存在内存泄漏的问题，通常的解决办法是为WebView单开一个进程，使用AIDL进行通信，根据业务需求在合适的时机释放掉

7.资源对象未关闭导致

如Cursor，File，Broadcast等，内部往往都使用了缓冲，会造成内存泄漏，一定要确保关闭它并将引用置为null

8.集合中的对象未清理

集合用扮行团于保存对象，如果集合越来越大，不进行合理的清理，尤其是入股集合是静态的

9.Bitmap导致内存泄漏

bitmap是比较占内存的，所以一定要在不使用的时候及时进行清理，避免静态变量持有大的bitmap对象

10.监听器未关闭

很多需要register和unregister的系统服务要在合适的时候进行unregister,手动添加的listener也厅橘需要带颤及时移除

‘伍’ 如何使用MAT分析Android应用内存泄露

使用Android Studio，Android Device Monitor 配合Eclipse的MAT(

Memory Analyzer)工具来分析android内存泄露。

1、新建一个Android 测试应用。填写好应用的名称，以及保存位置后，直接下一步到最后点击“Finish”。

‘陆’ 关于Android EditText导致的内存泄漏的问题

泄露信息如下：

====================================

    HEAP ANALYSIS RESULT

    ====================================

    1 APPLICATION LEAKS

    References underlined with "~~~" are likely causes.

    Learn more at https://squ.re/leaks.

    Displaying only 1 leak trace out of 4 with the same signature

    Signature:

    ┬───

    │ GC Root: System class

    │

    ├─ android.os.AsyncTask class

    │    Leaking: NO (a class is never leaking)

    │    ↓ static AsyncTask.SERIAL_EXECUTOR

    │                      ~~~~~~~~~~~~~~~

    ├─ android.os.AsyncTask$SerialExecutor instance

    │    Leaking: UNKNOWN

    │    ↓ AsyncTask$SerialExecutor.mTasks

    │                              ~~~~~~

    ├─ java.util.ArrayDeque instance

    │    Leaking: UNKNOWN

    │    ↓ ArrayDeque.elements

    │                ~~~~~~~~

    ├─ java.lang.Object[] array

    │    Leaking: UNKNOWN

    │    ↓ Object[].[0]

    │              ~~~

    ├─ android.os.AsyncTask$SerialExecutor$1 instance

    │    Leaking: UNKNOWN

    │    Anonymous class implementing java.lang.Runnable

    │    ↓ AsyncTask$SerialExecutor$1.val$r

    │                                ~~~~~

    ├─ android.widget.TextView$3 instance

    │    Leaking: UNKNOWN

    │    Anonymous class implementing java.lang.Runnable

    │    ↓ TextView$3.this$0

    │                ~~~~~~

    ├─ androidx.appcompat.widget.AppCompatEditText instance

    │    Leaking: YES (View.mContext references a destroyed activity)

    │    View not part of a window view hierarchy

    │    View.mAttachInfo is null (view detached)

    │    View.mID = R.id.input_edit

    │    View.mWindowAttachCount = 1

    │    mContext instance of RoomMainActivity with mDestroyed = true

    │    ↓ View.mContext

    ╰→ RoomMainActivity instance

        Leaking: YES (ObjectWatcher was watching this because RoomMainActivity

        received Activity#onDestroy() callback and Activity#mDestroyed is true)

        key = cb388a5c-0ff2-452f-a9b0-6ea7d03a5105

        watchDurationMillis = 37631

        retainedDurationMillis = 32630

        mApplication instance of ChatApplication

        mBase instance of androidx.appcompat.view.ContextThemeWrapper

    ====================================

原因分析：

1、引用链结构：AsyncTask的SerialExecutor执行器引用了EditText对象，而EditText对象中的mContext引用到了RoomMainActivity中context，导致RoomMainActivity 无法销毁。

查看源码得知在TextView中有updateTextServicesLocaleAsync()方法，调用了AsyncTask.execute(）向其中传入了匿名内部类Runnable，而持有了控件对象。

2、解决方法：因为在源码层面无法修改源码，在引用端切断引用链。

给EditText使用Application的上下文，在EditText使用的页面退出销毁时移除EditText控件，包括置空它的监听器、清除它的焦点。

import android.content.Context;

import android.os.Build;

import android.text.TextWatcher;

import android.util.AttributeSet;

import android.view.ViewGroup;

import androidx.appcompat.widget.AppCompatEditText;

/**

* 关于Android EditText导致的内存泄漏的问题

*/

public class NoMemoryLeakEditTextextends AppCompatEditText {

public NoMemoryLeakEditText(Context context) {

super(context.getApplicationContext());

    }

public NoMemoryLeakEditText(Context context, AttributeSet attrs) {

super(context.getApplicationContext(), attrs);

    }

public NoMemoryLeakEditText(Context context, AttributeSet attrs, int defStyleAttr) {

super(context.getApplicationContext(), attrs, defStyleAttr);

    }

public void clearMemoryLeak(TextWatcher watcher, ViewGroup container) {

clearFocus();

        setOnTouchListener(null);

        setOnClickListener(null);

        setOnDragListener(null);

        setOnKeyListener(null);

        setOnLongClickListener(null);

        setOnEditorActionListener(null);

        if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.KITKAT_WATCH) {

(null);

        }

if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.M) {

setOnScrollChangeListener(null);

        }

setOnFocusChangeListener(null);

        removeTextChangedListener(watcher);

        container.removeView(this);

    }

}

最后在页面销毁的地方调用clearMemoryLeak方法

‘柒’ android开发什么叫内存泄露

下面图片是解决内存泄露的例子。例子来自android学习手册，android学习手册，里面有源码。android学习手册包含9个章节，108个例子，源码文档随便看，例子都是可交互，可运行，源码采用android studio目录结构，高亮显示代码，文档都采用文档结构图显示，可以快速定位。360手机助手中下载,图标上有贝壳

在android程序开发中，当一个对象已经不需要再使用了，本该被回收时，而另外一个正在使用的对象持有它的引用从而导致它不能被回收，这就导致本该被回收的对象不能被回收而停留在堆内存中，内存泄漏就产生了。

内存泄漏有什么影响呢？它是造成应用程序OOM的主要原因之一。由于android系统为每个应用程序分配的内存有限，当一个应用中产生的内存泄漏比较多时，就难免会导致应用所需要的内存超过这个系统分配的内存限额，这就造成了内存溢出而导致应用Crash。

了解了内存泄漏的原因及影响后，我们需要做的就是掌握常见的内存泄漏，并在以后的android程序开发中，尽量避免它。下面小编搜罗了5个android开发中比较常见的内存泄漏问题及解决办法，分享给大家，一起来看看吧。

一、单例造成的内存泄漏

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，所以这个Context的生命周期的长短至关重要：

1、传入的是Application的Context：这将没有任何问题，因为单例的生命周期和Application的一样长 ；

2、传入的是Activity的Context：当这个Context所对应的Activity退出时，由于该Context和Activity的生命周期一样长（Activity间接继承于Context），所以当前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;

}

}

这样不管传入什么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(){

//...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 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。

四、线程造成的内存泄漏

对于线程造成的内存泄漏，也是平时比较常见的，如下这两个示例可能每个人都这样写过：

//——————test1

new AsyncTask<Void, Void, Void>() {

@Override

protected Void doInBackground(Void... params) {

SystemClock.sleep(10000);

return null;

}

}.execute();

//——————test2

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技术分享｜Android 中部分内存泄漏示例及解决方案

内存泄漏：

举例：

请注意以下的例子是虚构的

内存抖动

源自Android文档中的 Memory churn 一词，中文翻译为内存抖动。

指快速频繁的创建对象从而产生的性能问题。

引用Android文档原文：

Java内存泄漏的根本原因是 长生命周期 的对象持有 短生命周期 对象的引用就很可能发生内存泄漏。

尽管短生命周期对象已经不再需要，但因为长生命周期依旧持有它的引用，故不能被回收而导致内存泄漏。

静态集合类引起的内存泄漏

如果仅仅释放引用本身(tO = null)， ArrayList 依然在引用该对象，GC无法回收。

监听器

在Java应用中，通常会用到很多监听器，一般通过 addXXXXListener() 实现。但释放对象时通常会忘记删除监听器，从而增加内存泄漏的风险。

各种连接

如数据库连接、网络连接（Socket）和I/O连接。忘记显式调用 close() 方法引起的内存泄漏。

内部类和外部模块的引用

内部类的引用是很容易被遗忘的一种，一旦没有释放可能会导致一系列后续对象无法释放。此外还要小心外部模块不经意的引用，内部类是否提供相应的操作去除外部引用。

单例模式

由于单例的静态特性，使其生命周期与应用的生命周期一样长，一旦使用不恰当极易造成内存泄漏。如果单利持有外部引用，需要注意提供释放方式，否则当外部对象无法被正常回收时，会进而导致内存泄漏。

集合类泄漏

如集合的使用范围超过逻辑代码的范围，需要格外注意删除机制是否完善可靠。比如由静态属性 static 指向的集合。

单利泄漏

以下为简单逻辑代码，只为举例说明内存泄漏问题，不保证单利模式的可靠性。

AppManager 创建时需要传入一个 Context ，这个 Context 的生命周期长短至关重要。

1. 如果传入的是 Application 的 Context ，因为 Application 的生命周期等同于应用的生命周期，所以没有任何问题。

2. 如果传入的是 Activity 的 Context ，则需要考虑这个 Activity 是否在整个生命周期都不会被回收了，如果不是，则会造成内存泄漏。

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

应该将该内部类单独封装为一个单例来使用。

匿名内部类/异步线程

Runnable都使用了匿名内部类，将持有MyActivity的引用。如果任务在Activity销毁前未完成，将导致Activity的内存无法被回收，从而造成内存泄漏。

解决方法：将Runnable独立出来或使用静态内部类，可以避免因持有外部对象导致的内存泄漏。

Handler造成的内存泄漏

Handler属于TLS(Thread Local Storage)变量，生命周期与Activity是不一致的，容易导致持有的对象无法正确被释放

当Android应用程序启动时，该应用程序的主线程会自动创建一个Looper对象和与之关联的MessageQueue。

当主线程中实例化一个Handler对象后，它就会自动与主线程Looper的MessageQueue关联起来。所有发送到MessageQueue的Messag都会持有Handler的引用，所以Looper会据此回调Handle的handleMessage()方法来处理消息。只要MessageQueue中有未处理的Message，Looper就会不断的从中取出并交给Handler处理。

另外，主线程的Looper对象会伴随该应用程序的整个生命周期。

在Java中，非静态内部类和匿名类内部类都会潜在持有它们所属的外部类的引用，但是静态内部类却不会。

当该 Activity 被 finish() 掉时，延迟执行任务的 Message 还会继续存在于主线程中，它持有该 Activity 的 Handler 引用，所以此时 finish() 掉的 Activity 就不会被回收了从而造成内存泄漏（因 Handler 为非静态内部类，它会持有外部类的引用，在这里就是指 SampleActivity）。

避免不必要的静态成员变量

对于BroadcastReceiver、ContentObserver、File、Cursor、Stream、Bitmap等资源的使用，应在Activity销毁前及时关闭或注销。

不使用WebView对象时，应调用`destroy()`方法销毁。