Android开发经验谈Android开发Android开发

06 性能优化-内存优化-内存的分配和回收机制

2021-03-30  本文已影响0人  凤邪摩羯

1 Java内存分配机制和回收机制

1.1、Java的内存分配区域

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

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

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

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

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

  5. 程序计数器：多线程是通过线程轮流切换来获得CPU执行时间的，因此，在任一具体时刻，一个CPU的内核只会执行一条线程中的指令，为了能够使得每个线程都在线程切换后能够恢复在切换之前的程序执行位置，每个线程都需要有自己独立的程序计数器，并且不能互相被干扰，否则就会影响到程序的正常执行次序。因此，可以这么说，程序计数器是每个线程所私有的。

不同的文章中会有的不同的分配方式，但是大多数都是类似的，有的文章中还会提到静态域和常量池，这两个部分都属于方法区（在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写一行简单的代码，当执行这行代码时，会自动在堆里进行内存分配。为了这种灵活性，用堆进行存储分配比用栈进行内存分配需要更多的时间。

1.2、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开发中此类引用非常少见，故不做过多介绍。

1.3、Java的垃圾回收机制

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

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

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

1.垃圾回收算法

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

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

2.内存的分代回收

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

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

3.Android的内存管理机制

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

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

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

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

1.4、常见的内存泄漏场景

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中，因为代码编写不当，造成内存泄露的地方有很多，这里不再枚举，会在后续的文章中讲解如何监测内存泄露，并一步步还原出内存泄露的原因。

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

根据前面介绍的内存回收机制，下面给出几个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'};

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

  String s1 = "hello";
  s1 = s1 + " world";

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

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

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

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

例如：

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进行资源的清理。
但是，垃圾回收的工作已经很大了，尤其是在回收Young代的内存时，大都会引起程序的暂停。在垃圾回收已经制约程序的运行效率时，再使用finalize进行资源清理，将会是垃圾回收器的负担更大，导致程序运行效率更差。

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

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

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

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

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

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

2 Android内存分配与回收机制

想要优化Android内存，一些必备的基础知识是不能少的。所以在第一部分，我们先从Application Framework、Dalvik/Art、Linux内核三个部分由浅入深来讲解关于Androd内存相关的知识。

2.1. Application Framework

首先来看下进程的优先级：

image

前台进程：用户当前操作所必需的进程。

可见进程：没有任何前台组件、但仍会影响用户在屏幕上所见内容的进程。

服务进程：正在运行已使用 startService() 方法启动的服务。（后台播放音乐，网络下载数据）

后台进程：对用户不可见的 Activity 的进程（已调用 Activity 的 onStop() 方法）

空进程：不含任何活动应用组件的进程。保留这种进程的的唯一目的是用作缓存，以缩短下次在其中运行组件所需的启动时间

进程生命周期：Android 系统将尽量长时间地保持应用进程，但为了新建进程或运行更重要的进程，最终需要移除旧进程来回收内存。 为了确定保留或终止哪些进程，系统会根据进程中正在运行的组件以及这些组件的状态，将每个进程放入“重要性层次结构”中。 必要时，系统会首先消除重要性最低的进程，然后是重要性略高的进程，来回收系统资源。（一般情况下前台进程就是与用户交互的进程了,如果连前台进程都需要回收那么此时系统几乎不可用了）。由此也衍生了很多进程保活的方法（提高优先级，互相唤醒，native保活等等），出现各种杀不死的进程的APP。

最后我们需要知道：Android中由ActivityManagerService 类集中管理所有进程的内存资源分配，我们可以查看其源码来具体分析实现过程。

2.2 Dalvik/Art 虚拟机

2.2.1 Android Dalvik Heap

image

简介：Android Dalvik Heap与原生Java一样，将堆的内存空间分为三个区域，Young Generation新生代，Old Generation年老代， Permanent Generation持久代。

对象分配过程：最近分配的对象会存放在新生代区域，新生代区域分为eden区（伊甸园，圣经中指上帝为亚当夏娃创造的生活乐园）、so区和s1区，s1和s0区也被称为from区和to区（合称Survivor区），他们是两块大小相等并且可以互换角色的空间，绝大多数情况下,对象首先分配在eden区，在一次新生代回收后，如果对象还存活会进入s0或者s1区，之后每一次gc，存活的对象年龄都会相应增加，当达到一定年龄则会进入老年代，最后累积一定时间再移动到持久代区域。系统会根据内存中不同的内存数据类型分别执行不同的gc操作。

问题：GC发生的时候，所有的线程都是会被暂停的。执行GC所占用的时间和它发生在哪一个Generation也有关系，新生代中的每次GC操作时间是最短的，年老代其次，持久代最长。GC时会导致线程暂停、界面卡顿的问题在Android Art中得到了优化。

2.2.2 Dalvik虚拟机执行模式

image

Dalvik垃圾回收过程：GC会去标记和查找所有可访问到的活动对象，这个时候整个程序的线程就会挂起，并且虚拟机内部的所有线程也会同时挂起(左下图) 。之所以要挂起所有线程是确保：所有程序没有进行任何变更，与此同时GC会隐藏所有处理过的对象，最终确保标记了所有需要回收的对象后，GC才会恢复所有线程，并释放空间。

大内存对象分配：当发现需要给一个较大的对象(蓝色方块)分配空间时，发现可用空间还是够的，但没有这么大的连续空间供新对象使用，这个时候就不得不进行一次GC回收（红色方块，右下图），为大对象腾出较大并且连续的空间。这就是我们在分配一个较大对象的时候非常容易引起丢帧和卡顿的原因之一，所以Android5.0以前大家都认为Android卡顿是因为Darvik虚拟机的效率低下导致的。

总结：Dalvik虚拟机的三个问题

  1. GC时挂起所有线程
  2. 大而连续的空间紧张
  3. 内存碎片化严重

2.2.3 ART虚拟机的优化

image

GC过程：在ART中GC会要求程序在分配空间的时候标记自身的堆栈，这个过程非常短，不需要挂起所有程序的线程.这样就节约了很大一部分时间去查找活动对象。

大内存对象分配：ART里会有一个独立的LOS供Bitmap使用，从而提高了GC的管理效率和整体性能.

内存碎片化在ART里还会有一个moving collector来压缩活动对象(绿色方块)，使得内存空间更加紧凑。

总结 ：Google在ART里对GC做了非常大的优化(更高效的回收算法),使ART内存分配的效率提高了10倍，GC的效率提高了2-3倍（可见原来效率有多低），不过主要还是优化中断和阻塞的时间，频繁的GC还是会导致卡顿。

2.3 Linux内核

image

Lowmemorykiller：ActivityManagerService中trimApplications() 函数中会执行一个叫做 updateOomAdjLocked() 的函数，updateOomAdjLocked 将针对每一个进程更新一个名为 adj 的变量，（用来表示发生内存不足时杀死进程的优先级顺序）并将其告知 Linux 内核，内核同样维护一个包含 adj 的数据结构（即进程表），并通过 lowmemorykiller 检查系统内存的使用情况，在内存不足时，遍历所有进程，选出低优先级的进程杀死，最终由内核去完成真正的内存回收。

Oom_killer ：如果上述各种方法都无法释放出足够的内存空间，那么当为新的进程分配内存时将发生 Out of Memory 异常，OOM_killer 将尽最后的努力杀掉一些进程来释放空间。Android 中的oom_killer同样会遍历进程，并计算所有进程的 badness 值，选择 badness 最大的那个进程将其杀掉。

Oom的条件：只要allocated + 新分配的内存 >= dalvik heap(堆内存) 最大值的时候就会发生OOM（Art运行环境的统计规则还是和dalvik保持一致）

2.4 内存不优化会导致哪些问题？

image

上面介绍了Android内存分配从应用层到Linux层的一些知识，所以我总结出上图内存会导致的一些问题，但是上图只是列出了一些常见情况，前后并没有绝对的因果关系，最后来说下内存抖动。

内存抖动：Memory Churn，内存抖动是因为在短时间内大量的对象被创建又马上被释放。瞬间产生大量的对象会严重占用内存区域，当达到阀值，剩余空间不够的时候，会触发GC从而导致刚产生的对象又很快被回收。即使每次分配的对象占用了很少的内存，但是他们叠加在一起会增加Heap的压力，从而触发更多其他类型的GC。这个操作有可能会影响到帧率，并使得用户感知到性能问题。

上一篇下一篇

猜你喜欢

热点阅读