最多见的Android内存优化方式及防止泄漏形成OOM总结篇

文章来源：安卓巴士

前言

内存优化目的就是让咱们在开发中怎么有效的避免咱们的应用出现内存泄漏的问题。内存泄漏你们都不陌生了，简单粗俗的讲，就是该被释放的对象没有释放，一直被某个或某些实例所持有却再也不被使用致使 GC 不能回收。既然说到内存泄漏和优化，就不得不先简单了解一下内存分配策略，而后再举常见泄漏例子和解决方法，最后作一下总结，这样更直观全面了解Android内存方面处理。

内存分配

内存分配策略有三种，分别是静态、栈式和堆式。对应的的内存空间主要分别是静态存储区（也称方法区）、栈区和堆区。以下：

• 静态存储区：主要存放静态数据、全局 static 数据和常量。这块内存在程序编译时就已经分配好，而且在程序整个运行期间都存在。
• 栈区 ：当方法被执行时，方法体内的局部变量都在栈上建立，并在方法执行结束时这些局部变量所持有的内存将会自动被释放。由于栈内存分配运算内置于处理器的指令集中，效率很高，可是分配的内存容量有限。
• 堆区 ： 又称动态内存分配，一般就是指在程序运行时直接 new 出来的内存。这部份内存在不使用时将会由 Java 垃圾回收器来负责回收。

栈与堆 区别：

在方法体内定义的（局部变量）一些基本类型的变量和对象的引用变量都是在方法的栈内存中分配的。当在一段方法块中定义一个变量时，Java 就会在栈中为该变量分配内存空间，当超过该变量的做用域后，该变量也就无效了，分配给它的内存空间也将被释放掉，该内存空间能够被从新使用。堆内存用来存放全部由 new 建立的对象（包括该对象其中的全部成员变量）和数组。在堆中分配的内存，将由 Java 垃圾回收器来自动管理。在堆中产生了一个数组或者对象后，还能够在栈中定义一个特殊的变量，这个变量的取值等于数组或者对象在堆内存中的首地址，这个特殊的变量就是咱们上面说的引用变量。咱们能够经过这个引用变量来访问堆中的对象或者数组。

举个例子:

public class Sample() {  int s1 = 0; Sample mSample1 = new Sample(); public void method() { int s2 = 1; Sample mSample2 = new Sample(); }}复制代码

Sample mSample3 = new Sample();

Sample 类的局部变量 s2 和引用变量 mSample2 都是存在于栈中，但 mSample2 指向的对象是存在于堆上的。

mSample3 指向的对象实体存放在堆上，包括这个对象的全部成员变量 s1 和 mSample1，而它本身存在于栈中。

小结

局部变量的基本数据类型和引用存储于栈中，引用的对象实体存储于堆中：由于它们属于方法中的变量，生命周期随方法而结束。 成员变量所有存储与堆中（包括基本数据类型，引用和引用的对象实体）：由于它们属于类，类对象终究是要被new出来使用的。

0基础教你开发探探类社交软件tinder

管理内存

内存管理就是对象的分配和释放问题。

在 Java 中，程序员须要经过关键字 new 为每一个对象申请内存空间 (基本类型除外)，全部的对象都在堆 (Heap)中分配空间。另外，对象的释放是由 GC 决定和执行的。在 Java 中，内存的分配是由程序完成的，而内存的释放是由 GC 完成的，这种收支两条线的方法确实简化了程序员的工做。但同时，它也加剧了JVM的工做。这也是 Java 程序运行速度较慢的缘由之一。由于，GC 为了可以正确释放对象，GC 必须监控每个对象的运行状态，包括对象的申请、引用、被引用、赋值等，GC 都须要进行监控。监视对象状态是为了更加准确地、及时地释放对象，而释放对象的根本原则就是该对象再也不被引用。

内存泄漏

内存泄漏就是存在一些被分配的对象，这些对象有下面两个特色，首先，这些对象是可达的，即在有向图中，存在通路能够与其相连；其次，这些对象是无用的，即程序之后不会再使用这些对象。若是对象知足这两个条件，这些对象就能够断定为Java中的内存泄漏，这些对象不会被GC所回收，然而它却占用内存。

在C++中，内存泄漏的范围更大一些。有些对象被分配了内存空间，而后却不可达，因为C++中没有GC，这些内存将永远收不回来。在Java中，这些不可达的对象都由GC负责回收，所以程序员不须要考虑这部分的内存泄露。

经过分析，咱们得知，对于C++，程序员须要本身管理边和顶点，而对于Java程序员只须要管理边就能够了(不须要管理顶点的释放)。经过这种方式，Java提升了编程的效率。

所以，经过以上分析，咱们知道在Java中也有内存泄漏，但范围比C++要小一些。由于Java从语言上保证，任何对象都是可达的，全部的不可达对象都由GC管理。

对于程序员来讲，GC基本是透明的，不可见的。虽然，咱们只有几个函数能够访问GC，例如运行GC的函数System.gc()，可是根据Java语言规范定义， 该函数不保证JVM的垃圾收集器必定会执行。由于，不一样的JVM实现者可能使用不一样的算法管理GC。一般，GC的线程的优先级别较低。JVM调用GC的策略也有不少种，有的是内存使用到达必定程度时，GC才开始工做，也有定时执行的，有的是平缓执行GC，有的是中断式执行GC。但一般来讲，咱们不须要关心这些。除非在一些特定的场合，GC的执行影响应用程序的性能，例如对于基于Web的实时系统，如网络游戏等，用户不但愿GC忽然中断应用程序执行而进行垃圾回收，那么咱们须要调整GC的参数，让GC可以经过平缓的方式释放内存，例如将垃圾回收分解为一系列的小步骤执行，Sun提供的HotSpot JVM就支持这一特性。

Java 内存泄漏的典型例子：

Vector v = new Vector(10);for (int i = 1; i < 100; i++) { Object o = new Object(); v.add(o); o = null; }复制代码

在这个例子中，咱们循环申请Object对象，并将所申请的对象放入一个 Vector 中，若是咱们仅仅释放引用自己，那么 Vector 仍然引用该对象，因此这个对象对 GC 来讲是不可回收的。所以，若是对象加入到Vector 后，还必须从 Vector 中删除，最简单的方法就是将 Vector 对象设置为 null。

常见内存泄漏

（本篇重点）

一、集合类泄漏

若是一个集合类是全局性变量（好比类中的静态变量或全局性map即有静态引用又或者final指向它）只有添加元素的方法，而没有相应的清除机制，就会占用内存只增不减，形成内存泄漏。好比咱们一般用HashMap作一些缓存之类的事，这种状况就多留点心，作好相应删除机制。

二、单例形成泄漏

因为单例的静态性使得生命周期跟应用的生命周期同样长，很容易形成内存泄漏。

典型的例子

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中，为了不重复建立相同的数据资源，可能会出现这种写法：

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内部建立了一个非静态内部类的单例TestResource，每次启动Activity时都会使用该单例的数据，这样虽然避免了资源的重复建立，不过这种写法却会形成内存泄漏，由于非静态内部类默认会持有外部类的引用，而该非静态内部类又建立了一个静态的实例，该实例的生命周期和应用的同样长，这就致使了该静态实例一直会持有该Activity的引用，致使Activity的内存资源不能正常回收。

正确的作法为：将该内部类设为静态内部类或将该内部类抽取出来封装成一个单例，若是须要使用Context，请按照上面推荐的使用Application 的Context。固然，Application 的 context 不是万能的，因此也不能随便乱用，对于有些地方则必须使用 Activity 的 Context，对于Application，Service，Activity三者的Context的应用场景以下：Application 和 Service 能够启动一个 Activity，不过须要建立一个新的 task 任务队列。而对于 Dialog 而言，只有在 Activity 中才能建立。

四、匿名内部类线程异步致使泄漏

在继承实现Activity/Fragment/View时，此时若是你使用了匿名类，并被异步线程持有了，那要当心了，没有任何措施必定会致使泄露。

举个栗子：

public class MainActivity extends Activity {  ...{ Runnable re1 = new MyRunable();  Runnable re2 = new Runnable() {  @Override  public void run() {  }  }; }复制代码

re1和re2的区别是，re2使用了匿名内部类。运行时这两个引用的内存能够看到，re1没什么特别的。

但ref2这个匿名类的实现对象里面多了一个引用：this$0这个引用指向MainActivity.this。

也就是说当前的MainActivity实例会被re2持有，若是将这个引用再传入一个异步线程，此线程和此Acitivity生命周期不一致的时候，就形成了Activity的泄露。

五、Handler 形成的内存泄漏

handler为了不ANR而不在主线程进行耗时操做，去处理网络任务或者封装一些请求回调等api等。咱们知道 Handler、Message 和 MessageQueue 都是相互关联在一块儿的，万一 Handler 发送的 Message 还没有被处理，则该 Message 及发送它的 Handler 对象将被线程 MessageQueue 一直持有形成内存泄漏。

因为 Handler 属于 TLS(Thread Local Storage) 变量, 生命周期和 Activity 是不一致的。所以这种实现方式通常很难保证跟 View 或者 Activity 的生命周期保持一致，故很容易致使没法正确释放。

知识点：在java里 ，非静态内部类 和匿名类都会潜在的引用它们所属的外部类。可是静态内部类却不会。

接下里看个案例：

public class SampleActivity extends Activity {  private final Handler mHandler = 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. mHandler.postDelayed(new Runnable() { @Override public void run() { ... }}, 1000 * 60 * 10);  // Go back to the previous Activity. finish(); }}复制代码

分析：

当activity结束(finish)时，里面的延时消息在获得处理前，会一直保存在主线程的消息队列里持续10分钟。并且，由上文可知这个message持有handler引用，而handler又持有对其外部类（activity）的潜引用。这条引用关系会一直保持直到消息获得处理，从而阻止了acitivty被垃圾回收器回收，形成应用程序的泄漏。另外非静态匿名类Runnable一样持有外部类，致使泄漏。总结2条缘由：

小结：

• 只要有未处理的消息，那么消息会引用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(); }}复制代码

若是一个内部类实例的生命周期比Activity更长，那么咱们千万不要使用非静态的内部类。最好的作法是，使用静态内部类，而后在该类里使用弱引用来指向所在的Activity。综述，推荐使用静态内部类 + WeakReference 这种方式。每次使用前注意判空。

知识点：

前面提到了 WeakReference，因此这里就简单的说一下 Java 对象的几种引用类型。

Java对引用的分类有强(Strong reference),软(SoftReference),弱 (WeakReference),虚 PhatomReference 四种。

在Android应用的开发中，为了防止内存溢出，在处理一些占用内存大并且声明周期较长的对象时候，能够尽可能应用软引用和弱引用技术。

软/弱引用能够和一个引用队列（ReferenceQueue）联合使用，若是软引用所引用的对象被垃圾回收器回收，Java虚拟机就会把这个软引用加入到与之关联的引用队列中。利用这个队列能够得知被回收的软/弱引用的对象列表，从而为缓冲器清除已失效的软/弱引用。

假设咱们的应用会用到大量的默认图片，好比应用中有默认的头像，默认游戏图标等等，这些图片不少地方会用到。若是每次都去读取图片，因为读取文件须要硬件操做，速度较慢，会致使性能较低。因此咱们考虑将图片缓存起来，须要的时候直接从内存中读取。可是，因为图片占用内存空间比较大，缓存不少图片须要不少的内存，就可能比较容易发生OutOfMemory异常。这时，咱们能够考虑使用软/弱引用技术来避免这个问题发生。如下就是高速缓冲器的雏形：首先定义一个HashMap，保存软引用对象——private Map。

六、尽可能避免使用 static 成员变量

若是成员变量被声明为 static，那咱们都知道其生命周期将与整个app进程生命周期同样。

这会致使一系列问题，若是你的app进程设计上是长驻内存的，那即便app切到后台，这部份内存也不会被释放。按照如今手机app内存管理机制，占内存较大的后台进程将优先回收，若是此app作过进程互保保活，那会形成app在后台频繁重启。当手机安装了你参与开发的app之后一晚上时间手机被消耗空了电量、流量，你的app不得不被用户卸载或者静默。

修复的方法：

• 不要在类初始时初始化静态成员。能够考虑lazy初始化。

七、AsyncTask对象形成的泄漏

AsyncTask确实须要额外注意一下。它的泄露原理和前面Handler，Thread泄露的原理差很少，它的生命周期和Activity不必定一致。

解决方案：在activity退出的时候，终止AsyncTask中的后台任务。

可是，问题是如何终止？

AsyncTask提供了对应的API：public final boolean cancel (boolean mayInterruptIfRunning)。

它的说明有这么一句话：

// Attempts to cancel execution of this task. This attempt will fail if the task has already completed, already been cancelled, or could not be cancelled for some other reason.// If successful, and this task has not started when cancel is called, this task should never run. If the task has already started, then the mayInterruptIfRunning parameter determines whether the thread executing this task should be interrupted in an attempt to stop the task.复制代码

cancel是不必定成功的，若是正在运行，它可能会中断后台任务。怎么感受这话说的这么不靠谱呢？

是的，就是不靠谱。

那么，怎么才能靠谱点呢？咱们看看官方的示例：

private class DownloadFilesTask extends AsyncTask<URL, Integer, Long> { protected Long doInBackground(URL... urls) { int count = urls.length; long totalSize = 0; for (int i = 0; i < count; i++) { totalSize += Downloader.downloadFile(urls[i]); publishProgress((int) ((i / (float) count) * 100)); // Escape early if cancel() is called // 注意下面这行，若是检测到cancel，则及时退出 if (isCancelled()) break; } return totalSize; }  protected void onProgressUpdate(Integer... progress) { setProgressPercent(progress[0]); }  protected void onPostExecute(Long result) { showDialog("Downloaded " + result + " bytes"); } }复制代码

官方的例子是很好的，在后台循环中时刻监听cancel状态，防止没有及时退出。

为了提醒你们，google特地在AsyncTask的说明中撂下了一大段英文：

// AsyncTask is designed to be a helper class around Thread and Handler and does not constitute a generic threading framework. AsyncTasks should ideally be used for short operations (a few seconds at the most.) If you need to keep threads running for long periods of time, it is highly recommended you use the various APIs provided by the java.util.concurrent pacakge such as Executor, ThreadPoolExecutor and FutureTask.复制代码

可怜我神州大陆幅员辽阔，地大物博，什么都不缺，就是缺对英语阅读的敏感。

AsyncTask适用于短耗时操做，最多几秒钟。若是你想长时间耗时操做，请使用其余java.util.concurrent包下的API，好比Executor, ThreadPoolExecutor 和 FutureTask.

学好英语，避免踩坑！

八、 BroadcastReceiver对象

种种缘由没有调用到unregister()方法。

解决方法很简单，就是确保调用到unregister()方法。

顺带说一下，我在工做中碰到一种相反的状况，receiver对象没有registerReceiver()成功(没有调用到)，因而unregister的时候提示出错：

// java.lang.IllegalArgumentException: Receiver not registered ...复制代码

解决方案：

方案一：在registerReceiver()后设置一个FLAG，根据FLAG判断是否unregister()。网上搜到的文章几乎都这么写，我之前碰到这种bug，也是一直都这么解。可是不能否认，这种代码看上去确实有点丑陋。

方案二：我后来无心中听到某大牛提醒，在Android源码中看到一种更通用的写法：

// just sample, 能够写入工具类// 第一眼我看到这段代码，靠，太粗暴了，可是回头一想，要的就是这么简单粗暴，不要把一些简单的东西搞的那么复杂。private void unregisterReceiverSafe(BroadcastReceiver receiver) { try { getContext().unregisterReceiver(receiver); } catch (IllegalArgumentException e) { // ignore }}复制代码

九、BitMap对象形成的泄漏

Bitmap 对象不用的时候最好调用一下recycle 方法再赋值null，清空资源的直接或间接引用，可是有人要问，android源码里面好多地方也没有调用啊？

是的，我这里说的是最好，若是不调用的话，只能依赖于Java GC 执行的时候，调用Bitmap 的 finalize方法，

这里面会执行navtive的方法 nativeDestructor() 去释放资源，其实查看一下那个函数，就是一句 delete bitmap。

总结

1.对 Activity 等组件的引用应该控制在 Activity 的生命周期以内； 若是不能就考虑使用 getApplicationContext 或者 getApplication，以免 Activity 被外部长生命周期的对象引用而泄露。

2.尽可能不要在静态变量或者静态内部类中使用非静态外部成员变量（包括context )，即便要使用，也要考虑适时把外部成员变量置空；也能够在内部类中使用弱引用来引用外部类的变量。

3.对于生命周期比Activity长的内部类对象，而且内部类中使用了外部类的成员变量，能够将内部类改成静态内部类、静态内部类中使用弱引用来引用外部类的成员变量 。

4.Handler 的持有的引用对象最好使用弱引用，资源释放时也能够清空 Handler 里面的消息。好比在 Activity onStop 或者 onDestroy 的时候，取消掉该 Handler 对象的 Message和 Runnable。

5.在 Java 的实现过程当中，也要考虑其对象释放，最好的方法是在不使用某对象时，显式地将此对象赋值为 null，好比使用完Bitmap 后先调用 recycle()，再赋为null,清空对图片等资源有直接引用或者间接引用的数组（使用 array.clear() ; array = null）等，最好遵循谁建立谁释放的原则。

6.正确关闭资源，对于使用了BraodcastReceiver，ContentObserver，File，游标 Cursor，Stream，Bitmap等资源的使用，应该在Activity销毁时及时关闭或者注销。

7.保持对对象生命周期的敏感，特别注意单例、静态对象、全局性集合等的生命周期。

更多文章

• Android线程与线程池的这些你知道吗？

在Android中，线程分为主线程和子线程，主界面用于与用户交互，进行UI的相关操做，而子线程则负责耗时操做。若是在主线程中进行耗时操做，就会使程序没法及时的响应。所以耗时操做必须放在子线程中进行…… 阅读全文

• Flutter技术概览

前言

目前hybrid开发模式：

1.经过WebView来进行原生和web交互

2.为了解决WebView性能差的问题，以React Native为表明的一类框架将最终渲染工做交还给了系统，虽然一样使用类HTML+JS的UI构建逻辑，可是最终会生成对应的自定义原生控件，以充分利用原生控件相对于WebView的较高的绘制效率……阅读全文