「全面理解Android内存优化 1」-Android的内存机制与管理建议

林栩link
1,144 阅读23分钟

前言

本篇文章是《全面理解Android内存优化》系列文章的第一篇。系列的主要目的是希望将Android开发中涉及性能优化的部分做一次系统的归纳、总结和学习。本系列文章包含理论基础、工具使用、项目实践三个部分。

理论基础：「全面理解Android内存优化 1」-Android的内存机制与管理建议，主要讲解Android性能优化时涉及到的各种基础知识

工具使用：「全面理解Android内存优化 2」-内存优化工具的使用，主要讲解Android性能优化时各种常用工具的使用。

项目实践：「全面理解Android内存优化 3」-从理论到实践，以一个实际APP为例，总结在开发中会被忽视的内存问题。

本文中实战时使用的项目地址：github.com/linux-link/…，可以先阅读这篇文章了解这个项目一次组件化与Android Jetpack的实践

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

目录

  • Java的内存分配区域
  • Java的引用类型
  • Java的内存回收机制
  • 常见的内存泄漏场景
  • 内存管理的技巧与建议
  • 总结

正文

一、Java的内存分配区域

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

  1. 方法区：存储每个类的信息（包括类的名称、方法信息、字段信息）、静态变量、常量以及编译器编译后的代码等。这是所有线程都共享的区域。

  2. 虚拟机栈：用来存储方法中的局部变量（包括在方法中声明的非静态变量以及函数形参）。对于基本数据类型的变量，则直接存储它的值，对于引用类型的变量，则存的是指向对象的引用。局部变量表的大小在编译器就可以确定其大小了，因此在程序执行期间局部变量表的大小是不会改变的。每个线程都会有一个自己的栈。

  3. 本地方法栈：存储native方法的栈

  4. 堆：内存分配中最大的一块区域。Java中的堆是用来存储对象本身的以及数组（当然，数组引用是存放在虚拟机栈中的）。只不过和C语言中的不同是在Java中，程序员基本不用去关心空间释放的问题，Java的垃圾回收机制会自动进行处理。因此这部分空间也是Java垃圾收集器管理的主要区域，内存泄漏也是发生在这个区域的。另外，堆是被所有线程共享的，在JVM中只有一个堆。

  5. 程序计数器：多线程是通过线程轮流切换来获得CPU执行时间的，因此，在任一具体时刻，一个CPU的内核只会执行一条线程中的指令，为了能够使得每个线程都在线程切换后能够恢复在切换之前的程序执行位置，每个线程都需要有自己独立的程序计数器，并且不能互相被干扰，否则就会影响到程序的正常执行次序。因此，可以这么说，程序计数器是每个线程所私有的。如果你对这块区域有兴趣，请回看我以前写过的文章-深入了解Android多线程（一）Java线程基础

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

  1. 静态域：方法区的一部分。这里的“静态”是指“在固定的位置”。静态存储里存放程序运行时一直存在的数据。你可用关键字static来标识一个对象的特定元素是静态的，但JAVA对象本身从来不会存放在静态存储空间里。

  2. 常量池：方法区的一部分。常量值通常直接存放在程序代码内部，这样做是安全的，因为它们永远不会被改变。用于存放字符串常量和基本类型常量。

注意：在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对象

例如：

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

虽然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内存优化中常见工具的使用「Android内存优化 2」-内存优化工具的使用，感谢您的阅读！

avatar
文章
阅读
粉丝
相关推荐
「全面理解Android内存优化 3」-从理论到实践
1.0k阅读
 · 
1点赞
「全面理解Android内存优化 2」-内存优化工具的使用
2.5k阅读
 · 
2点赞
Android车载应用开发与分析（13）- 系统设置-蓝牙设置
1.2k阅读
 · 
6点赞
车载Android进阶篇（NDK其一） — CMake基础
681阅读
 · 
6点赞
「深入理解Android布局优化 1」-布局的加载流程与绘制原理
1.7k阅读
 · 
0点赞