全面理解Android内存优化

最新推荐文章于 2024-09-12 17:14:36 发布

一叶飘舟

最新推荐文章于 2024-09-12 17:14:36 发布

阅读量125

点赞数

文章标签： android

原文链接：https://juejin.cn/post/6844903907668262926

版权

Android的内存机制与管理建议

本篇属于三个部分中的理论基础部分。

一、Java的内存分配区域

Java内存分配主要包括以下几个区域：

方法区：存储每个类的信息（包括类的名称、方法信息、字段信息）、静态变量、常量以及编译器编译后的代码等。这是所有线程都共享的区域。
虚拟机栈：用来存储方法中的局部变量（包括在方法中声明的非静态变量以及函数形参）。对于基本数据类型的变量，则直接存储它的值，对于引用类型的变量，则存的是指向对象的引用。局部变量表的大小在编译器就可以确定其大小了，因此在程序执行期间局部变量表的大小是不会改变的。每个线程都会有一个自己的栈。
本地方法栈：存储native方法的栈
堆：内存分配中最大的一块区域。Java中的堆是用来存储对象本身的以及数组（当然，数组引用是存放在虚拟机栈中的）。只不过和C语言中的不同是在Java中，程序员基本不用去关心空间释放的问题，Java的垃圾回收机制会自动进行处理。因此这部分空间也是Java垃圾收集器管理的主要区域，内存泄漏也是发生在这个区域的。另外，堆是被所有线程共享的，在JVM中只有一个堆。
程序计数器：多线程是通过线程轮流切换来获得CPU执行时间的，因此，在任一具体时刻，一个CPU的内核只会执行一条线程中的指令，为了能够使得每个线程都在线程切换后能够恢复在切换之前的程序执行位置，每个线程都需要有自己独立的程序计数器，并且不能互相被干扰，否则就会影响到程序的正常执行次序。因此，可以这么说，程序计数器是每个线程所私有的。如果你对这块区域有兴趣，请回看我以前写过的文章-深入了解Android多线程（一）Java线程基础

不同的文章中会有的不同的分配方式，但是大多数都是类似的，有的文章中还会提到静态域和常量池，这两个部分都属于方法区（在JDK1.6中是这样的。JDK1.7中字符串常量池，存放在堆内存中。在JDK1.8之后，字符串常量池是在本地内存当中。Android程序员其实并不需要关心它属于哪个区域）。

静态域：方法区的一部分。这里的“静态”是指“在固定的位置”。静态存储里存放程序运行时一直存在的数据。你可用关键字static来标识一个对象的特定元素是静态的，但JAVA对象本身从来不会存放在静态存储空间里。
常量池：方法区的一部分。常量值通常直接存放在程序代码内部，这样做是安全的，因为它们永远不会被改变。用于存放字符串常量和基本类型常量。

注意：在Java中字符串的内存分配比较特别，需要额外注意。字符串对象的引用都是存储在虚拟机栈中的。如果是编译期已经创建好(直接用双引号定义的)的就存储在常量池中，如果是运行期（new出来的）才能确定的就存储在堆中。对于equals相等的字符串，在常量池中永远只有一份，在堆中有多份。

上面讲述了Java运行时的内存分配区域，作为Android程序员，我们更多的需要关注栈和堆。不过我们可能会产生这样的疑问，栈和堆有什么区别呢？为什么要同时存在这两块区域？带这样的疑问，我们回过头来再来看看这两个区域。

栈（stack）

栈位于通用RAM中。Java中存在一个虚拟的“栈指针”，“栈指针”若向下移动，则分配新的内存；若向上移动，则释放那些内存。这是一种快速高效的内存分配方式，仅次于寄存器。

这种内存分配方式，决定了在创建程序时候，Java编译器必须知道存储在栈内所有数据的确切大小和生命周期，因为它必须生成相应的代码，以便上下移动“栈指针”。栈区为了快速分配内存，限制了程序的灵活性，所以该区域只存放java基本类型数据和对象、数组的引用，对象本身则存放在堆或常量池中

堆（heap）

堆也位在于通用RAM中，用于存放所有的Java对象。堆与栈的不同之处在于，编译器不需要知道要从堆里分配多少存储区域，也不必知道存储的数据在堆里存活多长时间。

因此，在堆里分配存储有很大的灵活性。当你需要创建一个对象的时候，只需要new写一行简单的代码，当执行这行代码时，会自动在堆里进行内存分配。为了这种灵活性，用堆进行存储分配比用栈进行内存分配需要更多的时间。

二、Java的引用类型

在程序编译完，Jvm虚拟机给每个对象分配完内存后，Java的垃圾回收机制会监控每一个对象在内存中的运行状态，包括对象的申请、引用、被引用、赋值等。当某个对象不再被引用变量所引用时，垃圾回收机制就会将其回收，并释放内存空间。

Java中一个对象可以被一个局部变量所引用，也可以被其他类的静态变量引用，或者被其他对象的实例变量引用。当对象被静态变量引用时，只有该类被销毁，该对象才会被销毁、回收。当对象被其他对象的实例变量引用时，只有当引用该对象的对象被销毁或不再被引用时，该对象才会被销毁、回收。

为了更好的管理对象的引用，JDK中提供了四种引用方式，分别是强引用、软引用、弱引用、虚引用。下面分别介绍这几种引用方式和适用场景

强引用

这是java默认的引用对象方式，例如：

复制代码

Object object=new Object();

这里的object就是以强引用的方式引用Object对象，被强引用所引用的java对象，即使内存不足时也绝对不会垃圾回收机制回收。

软引用

软引用需要通过SoftReference类实现，例如：

复制代码

SoftReference<Object> object=new SoftReference<>();

被弱引用所引用的java对象，在内存充足时，它与强引用相同是不会被jvm的垃圾回收机制回收的，但是当系统内存不足时，垃圾回收机制就会将其回收。

在Android中软引用非常常用，例如：从网络中获取的图片，会将其暂时缓存在内存中，当下次再用时就可以直接从内存中，一般为了防止造成内存泄露，会将其设为软引用。

弱引用

弱引用与软引用有些相似，区别在于弱引用所引用的的对象生命周期更短。弱引用通过WeakReference类实现，例如：

复制代码

Object object=new Object(); WeakReference<Object> wObject=new WeakReference<>(object);

对于弱引用的对象而言，当jvm的垃圾回收机制运行时，不管内存是否足够，总会回收该对象所占用的内存。

虚引用

软引用和弱引用可以单独使用，但是虚引用却不能单独使用，虚引用的主要作用是跟踪对象被垃圾回收的状态。被虚引用引用的对象本身并没的太大的意义，对象甚至感觉不到引用的存在，使用虚引用的get()方法也总是为空。在Android开发中此类引用非常少见，故不做过多介绍。

三、Java的垃圾回收机制

Java语言中一个显著的特点就是引入了垃圾回收机制，使c++程序员最头疼的内存管理的问题迎刃而解，它使得Java程序员在编写程序的时候不再需要考虑内存管理。由于有个垃圾回收机制，Java中的对象不再有“作用域”的概念，只有对象的引用才有“作用域”。垃圾回收可以有效的防止内存泄露，高效的使用空闲的内存。

垃圾回收机制在Java中主要有一下两个作用：

1.跟踪并监视每个java对象，当某个对象失去引用时，回收该对象所占的内存。
2.清理内存分配、回收过程中产生的内存碎片。

垃圾回收机制所需要完成的工作量都不算小，因此垃圾回收的算法就成了限制java程序运行效率的重要因素。而这也是Android App运行过程中卡顿的一个主要原因之一。

1.垃圾回收算法

为了高效的完成内存的回收工作，在Java中设计几种不同的垃圾回收算法：

标记清除算法

垃圾回收器先从根开始访问所有可达对象，将他们标记为可达状态，然后再遍历一次整个内存区域，把所有没有标记的对象进行回收整理。

优点：不需要大规模的复制操作，内存利用效率高

缺点：需要遍历两次堆空间，因此会造成应用程序暂停的时间会随着堆内存空间的增大而增大，而且垃圾回收回来的内存往往是不连续的，因此整理后的堆内存里碎片很多。
复制算法

将堆内存分成两块相同的空间，从根开始访问每一个关联的可达对象，将空间A的可达对象复制到空间B，然后回收整个空间A。

优点：对于复制算法而言，因为只需要访问所有存在引用的对象，将所有存在引用的对象复制走之后就可以回收整个内存空间，完全不用理会那些不存在引用的对象，所以遍历空间的时间成本比较小。

缺点：浪费了一半内存，复制对象需要额外的时间成本。
标记整理算法

标记整理算法充分利用上述两种的算法的优点，垃圾回收器先从根开始访问所有可达对象，将它们标记为可达状态。接下来垃圾回收器会将这些活动对象搬迁在一起，这一过程也被称之为内存压缩，然后垃圾回收机制再次回收那些不可达对象占用的内存空间，这样就避免了回收产生的内存碎片。

从上面叙述可以看出不论采用哪种内存回收算法，总是利弊参半，因此，实现垃圾回收时总会综合使用多种设计方式。也就是针对不同的情况采用不同的垃圾回收实现。

2.内存的分代回收

现行的垃圾回收器用分代的方式来采用不同回收设计。分代的基本思路是根据对象生存时间的长短，把堆内存分成3个代

Young（年轻代） 初次分配内存空间的对象（非静态）都会被划为Young代。Young代中的大多数对象很快就会失去引用变为垃圾对象，只有少部分对象会在垃圾回收时依然存在引用。而垃圾回收器只需要保留Young代中的存在引用的对象即可，少量的对象复制成本很小，可以充分发挥复制算法的优点。所以，对于Young代主要使用复制算法来回收对象。
Old（老年代）

如果Young代中的对象经过多次垃圾回收依然没有被回收掉，垃圾回收器会将这个对象移动到Old代。随着程序的持续运行，Old代中对象会越来越多，因此Old代的空间比Young代要大。 Old代垃圾回收有两个特征：Old代垃圾回收执行频率无需太高，因为很少有对象会死掉；每次对Old代执行垃圾回收需要更长的时间。

基于以上考虑，对于Old代主要使用标记整理算法。这种算可以避免复制Old代的大量对象，而且由于Old代的对象不会很快死亡，回收过程也不会产生大量的内存碎片
Permanent（永久代）

JDK1.8之后Permanent代被移除了，而且垃圾回收器通常不会回收Permanent代的对象，所以这里就不再介绍了。

总结来看，Young代的内存会先被回收，而且会使用专门的回收算法（复制算法）来回收Young代的内存；对于Old代的回收频率则要低得多，主要使用标记整理算法。

3.Android的内存管理机制

在Android系统中每个APP都有一个独立的主进程，系统给每个进程分配的内存是大小在出厂时就被固定了，不同品牌、内存、系统的手机都是不一样的。一般来说，手机的出厂内存越大，系统能分配给每个进程的内存上限就越大。

众所周知，Android 5.0之后，Google给Android系统更换了一个更高效的虚拟机-ART 。早期的Dalvik虚拟机仅有一种内存回收算法，对于内存的回收效率也很低。ART虚拟机则根据APP是运行时的不同情况，采用了多种不同的垃圾回收算法，用来高效的回收内存。

Android对于内存回收还存在一套Low Memory Killer的机制，当系统的可用内存出现紧张的时候，这套机制会全局检查所有正在运行的进程，并根据所需要的内存大小，杀死那些权重较低的进程，并回收它的内存。在Android中按进程的权重从高到低依次分为：前台进程（正在与用户交互），可见进程（不在与用户交互），服务进程，后台进程和空进程。

其实从Android6.0之后，对于内存的管理也是越发的严格，对于用户来说，手机会更加的流畅，不会因为内存不足，而产生各种停止运行。对于开发者来说，我们不必绞尽脑汁关心内存不足的问题，但是弊端就是开发中常用的各种进程保活措施大多数也都已经失效了。

四、常见的内存泄漏场景

1.什么是内存泄漏

内存泄露也是个Android开发、优化中绕不开的话题。在学习Java的程序开发的时候，我们不必像C\C++那样手动释放对象占据的内存，JVM的垃圾回收器会自动回收无用对象所占的内存空间，这会给人一种错觉，Java不会有内存泄露的问题，但实际上Java开发中使用不当，一样会存在内存泄露。

首先我们需要简单了解一下什么是内存泄漏。

在程序的运行过程中会不断地为对象、变量、数组等分配内存空间，当这些被分配出去的内存空间不再被使用时，垃圾回收器及时回收它们的内存，保证内存区域可以再次使用。但是当这些不再被使用的内存空间既不能被回收，新的对象也不能使用这块内存空间时，这就发生了内存泄露。久而久之系统的可用内存会越来越少，直到没有可用的内存，在Android中就会发生OutOfMemory的异常。

2.常见的内存泄漏场景

看到这里你是否有一个疑问，为什么这些不再被使用的内存空间不能被回收呢？原因我们在Java的垃圾回收机制中以及提到了，如果一个对象在垃圾回收时依然被一个外部引用持有，那么垃圾回收器就不能回收这个对象占据的内存空间，即使这外部引用永远都不会再使用了。

下面我们就来介绍几种在Android中常见的内存泄漏的案例：

需要回收的对象被静态变量持有

比较典型的例子就是单例中需要传入Context时，我们传入了当前Activity的Context

 class Example {
    private static volatile Example ourInstance;

    private Context mContext;

    static Example getInstance(Context context) {
        if (ourInstance == null) {
            synchronized (Example.class) {
                if (ourInstance == null) {
                    ourInstance = new Example(context);
                }
            }
        }
        return ourInstance;
    }

    private Example(Context context) {
        mContext = context;
    }
}

如果我们代码中如果我们传入Activity的Context的那么该Activity占用的内存在app运行周期将无法被回收，具体原因请继续往下看。

这里的Context我们可以用Application的Context替换，因为Application的生命周期就是App的运行周期。

private Example(Context context) {
        mContext = context.getApplicationContext();
}

非静态内部类持有外部类的引用

在java中内部类会隐式持有外部类的引用，一般情况下这并不会造成内存的泄露，但是如果内部类中执行了耗时操作，就有可能会产生内存泄露。

    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_welcome);
    
        Thread thread = new Thread(new Runnable() {
            @Override
            public void run() {
                try {
                    Thread.sleep(20000);
                } catch (InterruptedException e) {
                    e.printStackTrace();
                }
            }
        });
        thread.start();
    }

上面代码中，Thread隐式持有了Activity类的引用，当Activity退出时，thread依然在后台执行，那么Activity就会因为被后台线程持有而无法正常回收。

上述的例子只是用Thread举例耗时操作，像AsyncTask，Handler等都存在这样的问题，不过随着耗时操作的执行完毕，线程被正常释放，Activity是可以被正常回收的。这种在Activity中使用内部类执行耗时操作的做法本身就是错误的，也有可能导致其它异常情况的缠身，不提倡这种写法。

如果你一定要这么写，可以改成下面的做法：

  static class MyThread extends Thread {

        private SoftReference<Activity> mActivity;

        public MyThread(Activity activity) {
            mActivity = new SoftReference<>(activity);
        }

        @Override
        public void run() {
            super.run();
            try {
                Thread.sleep(20000);
            } catch (InterruptedException e) {
                e.printStackTrace();
            }
        }
    }

将内部类更改为静态内部类，静态内部类不会持有外部类的引用，需要我们自行传入，这时我们用外部类的引用设置为软引用，这个jvm在做垃圾回收时，就会回收掉内部类对于外部类（Activity）的引用，这样Activity就可以正常销毁了（需要注意一点的是，上述例子是一个在后台执行的线程，即使Activity被回收了，线程本身并不会被回收）。

资源对象未关闭

在使用IO、File流或者Sqlite、Cursor等资源时要及时关闭。这些资源在进行读写操作时通常都使用了缓冲，如果及时不关闭，这些缓冲对象就会一直被占用而得不到释放，以致发生内存泄露。因此我们在不需要使用它们的时候就及时关闭，以便缓冲能及时得到释放，从而避免内存泄露。

属性动画造成内存泄露

动画同样是一个耗时任务，比如在Activity中启动了属性动画（ObjectAnimator），但是在销毁的时候，没有调用cancle方法，虽然我们看不到动画了，但是这个动画依然会不断地播放下去，动画引用所在的控件，所在的控件引用Activity，这就造成Activity无法正常释放。因此同样要在Activity销毁的时候cancel掉属性动画，避免发生内存泄漏

在Android中甚至是Java中，因为代码编写不当，造成内存泄露的地方有很多，这里不再枚举，会在后续的文章中讲解如何监测内存泄露，并一步步还原出内存泄露的原因。

五、内存管理的技巧与建议

根据前面介绍的内存回收机制，下面给出几个Java内存管理方面的小技巧。

尽量使用直接量

当使用字符串和Byte、Short、Integer、Long、Float、Double、Boolean、Character包装类的实例时，不应该使用new的方式创建对象，而是采用直接量来创建他们

例如：使用

String str=“hello”

而不是

String str=new String（“hello”）;

使用直接量时Jvm的字符串缓存池会缓存这个字符串，但如果使用new去创建，Jvm不仅需要去进行缓存，而且str所引用的String对象底层还包含一个char类型数组，造成了不必要的内存浪费。

char[] c={‘h’,‘e’,‘l’,'l','o'};

使用StringBuider和StringBuffer进字符串的拼接

学习String时我们都知道String是长度不可变的，但是这样一段程序并不会报错

String s1 = "hello";

s1 = s1 + " world";

这是因为java在使用String对象进行字符串拼接时会生成大量的临时字符串，这些字符串都会占用相应的内存。而是用StringBuider和StringBuffer作为长度可变字符串对象则不存在这样的问题。

尽早释放无用的对象引用

一般来说方法内的局部变量所引用的对象生命周期很短，一般不需要将对象显式的设为null，但是有些情况除外例如

复制代码

BeanNews news = new BeanNews(); //一些常规操作 …… news = null; //耗时，耗内存的操作 ……

当局部对象之后存在耗时或耗内存的操作时，将局部对象置为null就有可能尽早释放该对象所占用的内存。为什么是有可能？因为垃圾回收是由Jvm决定，开发者无法决定何时进行回收。

避免在循环或频繁调用的方法中创建java对象

例如：

BeanNews news = new BeanNews();
//一些常规操作
……
news = null;
//耗时，耗内存的操作
……

虽然news是局部变量，会在循环结束后回收它所占的内存，但是在循环时也需要频繁的给news这个引用变量分配内存空间执行初始化操作，在这种不断分配、回收的操作过程中，也会影响程序的性能。

可以做如下的优化：

BeanNews news；
for (int i = 0; i <100 ; i++) {
  news=new BeanNews();
  ……
 }

这样就不需要为news这个引用类型的变量频繁分配内存，执行初始化。

缓存经常使用的对象

经常使用的对象，我们可以考虑将该对象用缓存池保存起来，下次需要时可以直接使用，不必在此进行创建和初始化操作。 Android开发过程中我们经常使用各种集合类做为缓存容器，

……
List<BeanNews> news = new ArrayList<>();
BeanNews beanNews = new BeanNews();
……
news.add(beanNews);
……
BeanNews beanNews1 = news.get(0);

需要注意的是，缓存是一种典型的牺牲空间换时间，我们在使用时要注意不能让缓存的容器占据过大的内存空间。大型的数据缓存，一般会使用一系列淘汰算法控制缓存器占据的内存在一个合理区间。

尽量不要使用finalize方法

当一个对象在使用引用之后，在垃圾回收器回收该对象之前，垃圾回收机制会先调用finalize方法进行资源清理。

所以有的开发者会考虑使用finalize进行资源的清理。但是，垃圾回收的工作已经很大了，尤其是在回收Young代的内存时，大都会引起程序的暂停。在垃圾回收已经制约程序的运行效率时，再使用finalize进行资源清理，将会是垃圾回收器的负担更大，导致程序运行效率更差。

使用软引用（SoftReference）

当创建长度很大的的数组或创建一个占用内存很大但是并不是十分重要的对象时，都应该考虑使用软引用。使用软引用的对象，会在内存紧张时，主动“牺牲”自己，释放内存空间，给之后的对象腾出宝贵的空间。

不过因为软引用的不确定性，在取出软引用所引用的对象时，要判断一下它是否是null的。如果是null，需要尝试重建它。

慎重使用静态变量

被static修饰的变量，生命周期会与它所在的类保持一致。在类不被卸载的情况下，那么该静态变量本身也不会被销毁。

class BeanNews{
    static Object obj=new Object();
}

上面这个例子中，Object对象会一直被静态变量obj引用，它在堆中占据的内存永远无法被回收，直到程序运行结束。

上面我们提到了Java的内存分配区域中有一个方法区，静态变量和类的信息就存储在这里。

六、总结

到这里，对于Android内存优化中需要了解的理论基础就简略的介绍完了，掌握理论基础，一方面开发中，我们可以避免犯一些低级错误，提高代码的质量，另一方面在日后做内存优化时会变得更加游刃有余，或许就不会产生“卧槽，这样为什么又会内存泄漏”的疑问了。

内存优化工具的使用

一、工具集

Android的内存分析工具随着时代的进步，一直在不停的推陈出新，这里只挑选了三个常用、易上手且能覆盖大多场景的工具。

工具	目标	能力	上手难度
Memory Profiler	内存泄漏、内存抖动、应用卡顿等	定位+实时追踪	中
Memory Analyzer	内存泄漏、内存占比	定位+发现	高
Leak Canary	Activity内存泄漏	定位+自动发现	低

下面就来分别介绍如果使用这些工具。

二、Memory Profiler

在Android Studio3.0之后Google使用全新的Android Profiler取代了原本的Android Monitor，全新的分析工具能够提供关于应用 CPU、内存和网络的实时数据。本文介绍的Memory Profiler就是Android Profiler的一部分。

Memory Profiler使用步骤：

1.在Android Studio工具栏点击下图红圈中的图标

2.选择程序运行的设备，这里我们选择实机

3.程序运行成功后，我们可以看如下界面，其中MEMORY一栏就是Memory profiler。点击Memoey的时间线图表，进入Memory Profiler。

4.Memory Profiler界面总览

如果需要要启用高级分析，请按以下步骤操作（当运行在Android 8.0及以上设备上时，会自动开启高级分析）：

1.选择 Run > Edit Configurations。
2.在左侧窗格中选择您的应用模块。
3.点击 Profiling 标签，然后勾选 Enable advanced profiling。

关于怎么打开memory profiler介绍完了，更多更详细的资料可以参考官方的中文资料，使用 Memory Profiler 查看 Java 堆和内存分配。Memory Profiler是在Android内存调试时最常用的分析工具，如果你还没有掌握Memory Profiler的使用，请务必仔细阅读，官方的中文文档非常的详细！

三、Memory Analyzer

上面介绍的Memory Profiler在做内存分析时，只能给出相对简单的分析，有的时并不一定能立即定位或确认内存泄漏的地方，这时候就需要结合Memory Analyzer来做进一步的分析了。

说起Memory Analyzer（内存分析器）你可能没有听说过，但是你一定听过它的简称MAT。MAT是IBM Eclipse的顶级开源项目，它的设计初衷是分析J2SE或J2ME下的Java类型的应用程序的内存问题。

MAT功能强大，操作也相对复杂，它本身是一个独立的工具，需要在Eclipse官方网站下载，下载地址：www.eclipse.org/mat/downloa…

MAT使用步骤：

1.在Android Studio中打开Memory profiler，dump一段时间内的内存，并保存内存快照（Hprof）

接下来将Android Studio的内存快照转换为MAT支持的格式

2.打开终端，切换到Android SDK的platform-tools目录下

3.执行转换命令：hprof-conv 内存快照的地址转换后写入内存快照地址

4.打开MAT，点击workbench进入MAT工作界面

5.点击File->open file,打开转换后的hprof文件。

怎么打开MAT就介绍完了，MAT工具十分的强大，操作也相对比较复杂，本文无法全面的介绍MAT全部功能，我们根据下图的标识，来着重介绍一些MAT中常用的功能，请仔细对号阅读。

1.Histogram

查看当前内存中每一个class具体产生了多少实例，以及这些实例的Shallow Heap和Retained Heap。例如：一个activity，在内存中产生一个以上的实例，那么这个activity就非常有可能发生内存泄漏。

在选中对象上右击选择List objetcts。

with outgoing references：当前类引用了哪些类。

with incoming references：当前类被哪些类引用。

这两个属性在内存泄漏的调试中经常使用，我们可以根据当前类的引用链一直追溯到真正导致内存泄漏的类，从而排除内存泄漏。

2.Dominator Tree

以百分比的形式展示出在当前内存中占据内存最多的对象实例。它也是我们在减少APP内存占用时需要重点要观察的地方之一。

3.Top Consumers

通过图形的形式列出来比较占用内存的对象。它的下面还有一个Biggest Objects，从名字上就能看出，它里面包含了在内存中占据内存最多的几个对象的信息。

Top Consumers和上面介绍的Dominator Tree都是我们在考虑减少APP内存占用时需要重点观察的地方。找到最占内存的对象实例，并尽可能的减小它占据的内存，如果是内存泄漏则应该直接回收它。

4.Leak Suspects

在Leak Suspects中会直接给出MAT对于内存中存在问题的分析，点击Details就能查看导致当前内存问题类的的引用链，MAT会自动化的帮助我们找到内存泄漏的具体原因，这也是MAT中查找内存泄漏最快的方法。

不过有时候，手机系统的内存问题也会在这里面给出反馈。对于手机系统的bug，可以不必理会。

5.OQL

OQL一种数据查询语言，使用它我们就可以一种类似SQL语句形式，查询出我们需要的类的信息。

6.thread_overview

产看当前内存中存在的线程信息。

7.unreachable Objects Histogram

内存中可被回收的对象，但是现在未被回收的对象，这些未被回收对象可以作为参考，并不一定是导致APP内存泄漏的原因。

MAT的大致使用，就介绍完毕了，下面我们来介绍一个Android开发中几乎一定会用到的一个第三方的内存泄漏检测框架——Leak Canary。

四、Leak Canary

Leak Canary是大名鼎鼎的Square公司专门为检测Android内存泄漏而开发一个第三方框架。需要注意的是，LeakCanary只能用来监控内存泄漏，它并不支持监控其他的内存问题。

github地址：github.com/square/leak…

英文帮助文档：square.github.io/leakcanary/

LeakCanary的使用

最新版的LeakCanary在使用时，不需要做任何初始化操作，只需要在项目的build.gradle中添加以下依赖即可。

dependencies  { 
  // debugImplementation，因为LeakCanary应该只在调试版本中运行。
  debugImplementation'com.squareup.leakcanary:leakcanary-android:2.0-beta-2' 
}

运行APP后会在手机生成一个Leaks的APP，当在我们在调试集成了LeakCanary的APP时（仅在debug模式下使用），如果检测到内存泄漏时，LeakCanary将自动在手机上显示通知，并将内存泄漏的信息保存在LeaksAPP中。

排查内存泄漏

当产生内存泄漏后，LeakCanary会给出如下图所示的内存泄漏的引用链。

泄漏跟踪中的每个节点都是Java对象，可以是类，对象数组或实例。每个节点都有一个对下一个节点的引用。在UI中，该引用为紫色。

在LeakCanary给出报告中，每一个节点都标识了是否正在发生泄漏，在它后面的括号中还给出相应的解释。

Leaking：YES 正在发生泄漏，
Leaking：NO 没有发生泄漏，
Leaking：UNKNOWN 未知。

大致观察LeakCanary的报告后，我们就需要开始缩小观察范围来确定内存泄漏的原因。

在LeakCanary有这样一条规则，如果一个节点没有泄漏，那么指向它的任何先前引用都不是泄漏源，也不会泄漏。同样，如果一个节点泄漏，那么泄漏跟踪下的任何节点也会泄漏。由此，我们可以推断出内存泄漏原因出现在最后一次Leaking：NO和第一次Leaking：YES之间类中。

在本例中就对应下图的这四个部分，泄漏的原因往往就出这里面。在报告中用红色下波浪线标出来的部分，是LeakCanary认为导致内存泄漏的原因，也是我们接下来要重点排查的地方。

我们直接查看Application中的leakedViews，会发现正是在Application中保存View的代码导致了内存泄漏的发生，接下来就是尝试如何修复这段代码了。

val leakedViews = mutableListOf <View>（）

示例只是给出，如何根据LeakCanary的报告，缩小排查范围，并一步步找到内存泄漏的原因，请不要去关注示例中的这段代码是如何会导致内存泄漏的。

实际开发中，通过引入LeakCanary基本就可以找到绝大多数的内存泄漏。通过定制LeakCanary，我们甚至有能力在APP发布后依然能够保证获取开发时遗漏的内存泄漏点，关于定制请参考LeakCanary的官方文档：square.github.io/leakcanary/…

五、实际应用场景

上面介绍了三种各具特点内存分析与检测工具，在实际的开发中，我们应该根据项目组对于内存关注度的不同，组合使用不同的工具。

小团队

这类型团队是当前国内占比较多的一部分，Android开发组长期只有一两个人，APP的日活跃用户也比较少，却有着大量的需求亟待完成，甚至于需求本身可能都十分模糊。对于这样的团队关注的重心要集中在业务和功能上，如何保证APP不出bug才是重点。

建议：在APP中集成LeakCanary，整理、收集内存泄漏的报告，在空闲时尝试调试内存问题。调试之后一定要做充分测试，防止出现其他bug。

中等规模团队

这类型的团队基本长期都有三个人以上，APP的日活跃用户数比较多。这种团队的leader要适时关注一下APP的使用流畅度，着手解决APP中的内存泄漏、卡顿等问题，并定期发布相关的团队报告，让团队中其他人引以为戒。

建议：在APP中集成LeakCanary，每个开发人员在完成自己开发任务的同时，也要保证自己开发的功能不会出现被LeakCanary捕获的内存泄漏。如果不能根据LeakCanary定位内存泄漏的点，需要进一步使用MAT来排查。

团队的leader在版本发布前，要使用Memory Profiler监测每个新功能的内存时间线，图像的时间线相对平滑则是合格的。如果出现了剧烈波动的锯齿图像，表明出现了内存抖动，要着手修复，保持这样的节奏基本可以避免绝大多数内存方面的性能问题。监测的任务也可以交给团队内的测试人员。

六、总结

到这里，对于Android内存优化中常用的三种工具就介绍完了。熟练掌握各种分析工具的使用，能够帮助我们快速定位、解决开发中遇到的各种内存问题。既能帮助程序员提升自我，也能给用户一个良好的使用体验。

从理论到实践

一、关闭无用的Service

《饭fan》是一个单Activity多Fragment的APP，在App的入口Activity同时启动了两个Service，TinkerService用于检查热修复补丁，UpdateService用于检查是否有更新。

在操作APP一段时间后，使用Memory Profiler检查内存，得到下图

可以看到内存中依然存在TinkerService和UpdateService。没有特殊指定的service是运行在主线程中的，这些已经无用的Service会拖慢主线程并占据主进程的可用内存。

解决方案

调用stopService或stopSelf关闭这些service

关闭service后再次使用Memory Profiler检查内存，可以看到，APP占用的总内存已经减少了

二、多进程WebView的优化

从1.0.3版开始《饭fan》中集成了一个简单的商城系统，商城系统的制作参考了慕课网的一个课程—《混合开发入门主流开发方案实战京东移动端APP》。

商城系统集成完毕后，调试过程中，LeakCanary提示，ShoppingActivity发生了内存泄漏，如下图所示

WebView应该是Android中最容易发生内存泄漏的系统组件，往往都是Activity退出时，WebView依然持有activity的引用，导致Activity发生泄漏。网络上有很多如何防止WebView产生泄漏，但是效果都不好，有的甚至根本没有效果。

解决方案

让持有webview的Activity独立运行在一个进程，在activity的onDestroy中关闭这个进程

让Activity独立运行在一个进程中，可以彻底清除掉webview以及Activity ，但是让持有webview的Activity独立在一个进程中，会产生另一个问题——长时间的白屏。 webview本身初始化以及载入Html页面都需要一定的时间，这段时间会产白屏。如果在启动Activity时需要额外再创建一个进程，那么白屏的时间就会进一步拉长，有时甚至长达4-5秒。

《饭fan》中针对长时间这个问题，又做了进一步优化。

1.在app启动时，同时启动一个ShoppingService。ShoppingService运行在与WebViewActivity相同的进程中，退出WebViewActivity后当前进程会被关闭，在适当时候再重启ShoppingService。
2.引入腾讯的x5WebView和VasSonic，加快webview初始化速度，同时也提高了WebView在各个系统上兼容性。
3.在webview初始化的同时，使用APP内网络框架来请求Html页面中所需的数据。通过并行的方式，节省webview的加载数据的时间。

优化步骤大致就是以上这些，具体实现的代码请参考《饭fan》中Component_shopping组件。

三、Bitmap造成的内存泄漏

在Android内存优化中有“一图毁十优”的说法，一般普通的内存泄漏浪费的内存都在几十KB到几MB之间，但是一个bitmap泄漏就有可能浪费几十MB的内存空间，所以bitmap的优化一直是Android内存优化的重中之重。所以我们接下来的就重点介绍Bitmap的优化方案。

1.使用RGB_565解码图片

在开发中大多数的图片加载框架的默认解码方案是ARGB_8888，这种解码方案，每个像素占4个字节，其实还有一种图片解码方案是RGB_565,这种解码方案，每个像素占2个字节，但是在视觉效果上与ARGB_8888差距并不明显。

所以一些页面的缩略图、背景图片以及一些用户感官上认为它就是缩略图的地方可以使用RGB_565来解码，在减小内存占用上，有立竿见影的效果，强烈推荐使用。

2.不要乱放图片

在开发中我们往往会要求美工一张图标切3到5套不同尺寸的，然后分别放置在res下不同的资源目录里面

目录	对应的dpi
res/drawable	0
res/mipmap-lidp	120
res/mipmap-mdpi	160
res/mipmap-hdpi	240
res/mipmap-xhdpi	320
res/mipmap-xxhdpi	480
res/mipmap-xxxhdpi	640

Android有一套特殊的适配策略，对放在mipmap目录的图标会忽略屏幕密度，会去尽量匹配大一点的，然后系统自动对图片进行缩放，从而优化显示和节省资源。图片的缩放比率=手机的dpi / mipmap目录的dpi。

放在drawable目录下的会根据ROM的不同得到一个默认的dpi，但是这个dpi并一定是手机屏幕的实际dpi。

例如：如果我们将一张500X500的图标仅放在ldpi（120）下，那么在在480dpi的手机上实际的显示尺寸是2000X2000。

当我们分不清图标应该放在哪个目录下时，应该尽量将高品质的图片放在高密度目录下，这样能控制图片的缩放比率小于1，保证画质的前提，内存也是可控的。

3.控制那些不可控的图片

这是什么意思呢，举一个我曾经实际遇到的例子，我们的APP有一个课件的功能，允许教师上传课件，服务器会把这些课件转成图片返回给APP显示，有个老师上传了一篇PDF格式的论文，服务器转换后每个图片足足有4000X8000这么大，加载每张图片需要消耗内存4000X8000X4/1024/1204=122MB，直接导致了OOM。

在这个例子中教师上传的课件转换后的图片就属于不可控图片，如果服务器不做过滤，那么APP就需要对这些用户上传的图片特殊处理。

处理步骤如下：