Android优化———内存优化

Java虚拟机

Java内存模型

• 虚拟机栈（ 线程私有 ）：局部变量表、操作数栈、动态链接、方法出口等信息
• 堆（ 线程共享 ）：实例对象
• 方法区（ 线程共享 ）：类信息，常量，即时编译器编译后的代码
• 程序计数器（ 线程私有 ）：字节码行号指示器，记录当前线程执行到多少行
• 本地方法栈（ 线程私有 ）：和虚拟机栈类似，两者的区别就是虚拟机栈是为虚拟机执行java方法服务，本地方法栈为虚拟机执行native方法服务 。

程序计数器

如果是Native方法，计数器记录为空

堆

堆内存 = 新生代(1) + 老年代(2)

• 新生代：复制算法
• 老年代：标记整理算法

方法区

也叫“永久代”，1.8以后将方法区去除了，将方法区移动到直接内存

内存回收主要考虑 堆区 和 方法区 的回收，其他部分会根据线程的产生和消亡

个版本区别

• 1.6：运行常量池在方法区
• 1.7：运行常量池在堆中
• 1.8：删除方法区，引入直接内存，元空间概念，方法区中的静态变量被转移到堆中，只有class元数据在元空间。

堆中的老年代和方法区（永久代）是绑定的，无论哪一方满了，都会触发双方的GC回收

问题：

GC垃圾回收

判断对象是否存活

1. 引用计数算法（缺点：循环引用，技数永远不为0）
2. 可达性算法（二叉树中向下搜索，不存在引用链则对象不可用）

回收算法

1. 标记清除算法：标记完后对对象进行回收，使用在 老年代

   缺点：

   1. 效率不高，标记和清除效率不高
   2. 差生大量碎片空间，导致空间浪费

2. 复制算法：将可用对象复制到新的连续空间，删除之前的空间

   缺点：

   1. 浪费50%的内存，复制长生存期的对象效率低下，所以该算法使用在 新生代

3. 标记整理算法：前期使用标记清除算法，后续使用整理算法，使对象排列称联系空间，使用在 老年代

4. 分代收集算法：对数据进行分代，每一代执行不同的回收算法

年轻代分为eden、s0、s1区，分别为8：1：1，年轻代和老年代为1：2

5. 元空间的gc：元空间中的类加载器存活，则元空间中元数据也存活

四大引用介绍

简述

• 强引用：Strong Reference，通常使用的对象方式，gc不会回收
• 软引用：SoftReference，当内存不足时进行回收
• 弱引用：WeakReference，下一次gc时回收
• 虚引用：PhantomReference，任何时候可回收

在内存泄露问题处理上，使用最多的是弱引用，许多源码、框架都是用

eg：

1. ThreadLocalMap中存储以ThreadLocal的弱引用为键，具体内容为value
2. Glide中缓存使用activeResource，存储的是图片的弱引用
3. 解决Handler的内存泄漏使用弱引用

Reference理解

所有的引用都是继承自Reference，以下以WeakReference为例：

public class WeakReference<T> extends Reference<T> {

    /**
     * Creates a new weak reference that refers to the given object.  The new
     * reference is not registered with any queue.
     *
     * @param referent object the new weak reference will refer to
     */
    public WeakReference(T referent) {
        super(referent);
    }

    /**
     * Creates a new weak reference that refers to the given object and is
     * registered with the given queue.
     *
     * @param referent object the new weak reference will refer to
     * @param q the queue with which the reference is to be registered,
     *          or <tt>null</tt> if registration is not required
     */
    public WeakReference(T referent, ReferenceQueue<? super T> q) {
        super(referent, q);
    }

}

其中存在两种构造方法，区别在于是否传入引用队列，如果不传入引用队列，说明只存在一种引用，不需要引用队列成链存储

public abstract class Reference<T> {
    private static boolean disableIntrinsic = false;
    private static boolean slowPathEnabled = false;

    //引用的对象，由垃圾回收器控制其引用
    volatile T referent;         /* Treated specially by GC */
    final ReferenceQueue<? super T> queue;
    Reference queueNext;
    Reference<?> pendingNext;

    public T get() {
        return getReferent();
    }

    @FastNative
    private final native T getReferent();

    public void clear() {
        clearReferent();
    }

    @FastNative
    native void clearReferent();

    public boolean isEnqueued() {
        // Contrary to what the documentation says, this method returns false
        // after this reference object has been removed from its queue
        // (b/267823). ReferenceQueue.isEnqueued preserves this historically
        // incorrect behavior.
        return queue != null && queue.isEnqueued(this);
    }

    public boolean enqueue() {
       return queue != null && queue.enqueue(this);
    }

    /* -- Constructors -- */

    Reference(T referent) {
        this(referent, null);
    }

    Reference(T referent, ReferenceQueue<? super T> queue) {
        this.referent = referent;
        this.queue = queue;
    }
}

抽象类很简短，可以看出一个关键点，Reference是一个节点，保存next的引用，方法调用都是使用ReferenceQueue方法，直接进入：

private Reference<? extends T> head = null;
  private Reference<? extends T> tail = null;

 boolean enqueue(Reference<? extends T> reference) {
        synchronized (lock) {
            if (enqueueLocked(reference)) {
                lock.notifyAll();
                return true;
            }
            return false;
        }
    }

  private boolean enqueueLocked(Reference<? extends T> r) {
        ...

         if (r instanceof Cleaner) {
            Cleaner cl = (sun.misc.Cleaner) r;
            cl.clean();
            r.queueNext = sQueueNextUnenqueued;
            return true;
        }

        if (tail == null) {
            head = r;
        } else {
            tail.queueNext = r;
        }
        tail = r;
        tail.queueNext = r;
        return true;
    }

入队方法中，

1. 使用synchronized添加锁，入队结束后释放锁，在ReferenceQueue中并不是标准的队列，使用的是Reference节点成链，行成单链表，类似于MessageQueue.
2. 如果是Cleaner类，创建一个虚引用节点，即不如队。Cleaner是用来释放非堆内存，所以做特殊处理

SoftReference

>public class SoftReference<T> extends Reference<T> {
    //时间戳，由gc更新
    static private long clock;
    private long timestamp;

    public SoftReference(T referent) {
        super(referent);
        this.timestamp = clock;
    }

    /**
     * Creates a new soft reference that refers to the given object and is
     * registered with the given queue.
     *
     * @param referent object the new soft reference will refer to
     * @param q the queue with which the reference is to be registered,
     *          or <tt>null</tt> if registration is not required
     *
     */
    public SoftReference(T referent, ReferenceQueue<? super T> q) {
        super(referent, q);
        this.timestamp = clock;
    }

    public T get() {
        T o = super.get();
        if (o != null && this.timestamp != clock)
            this.timestamp = clock;
        return o;
    }

}

由gc管理时间戳

• clock：上一次gc时间
• timestamp：访问get时最近一次的gc时间

回收条件为：clock - timestamp <= free_heap * ms_per_mb

• free_heep为堆空间空闲大小
• ms_per_mb是保留软引用时间/MB

PhantomReference

public class PhantomReference<T> extends Reference<T> {

    public T get() {
        return null;
    }

    public PhantomReference(T referent, ReferenceQueue<? super T> q) {
        super(referent, q);
    }

}

虚引用的get方法返回null，不做gc保留

虚引用通过构造方法可以查看是 持有对象引用 的

总结：所有引用都是继承自Reference基类的，该类是一个链表节点，ReferenceQueue通过这点形成单链表，称之为队列，进行引用管理，所有引用都可以通过Reference的isEnqueue方法判断引用是否存在。

FinalizerReference理解

java堆中创建对象时，如果java类定义了finalize方法，就会新建一个FinalizerReference类，指向这个新建的对象

内存问题

• 内存泄漏：内存没有按照预期在gc时回收
• 内存溢出：内存大小超出指定大小，导致OOM
• 内存抖动：短时间创建大量内存对象，然后回收，导致内存发生锯齿形抖动，内存空间不连续加上碎片会导致更大的空间，最终OOM

内存优化意义

• 减少OOM，提高系统稳定性
• 减少卡顿，提高流畅度
• 减少内存占用，提高应用存活率
• 减少异常发生和代码逻辑隐患

Android内存泄漏

常见内存泄漏

1. 匿名内部类持有外部类引用，导致外部类内存泄漏（Handler）
2. 单例传入Context导致调用单例方无法被回收。
3. 非静态内部类创建静态实例
4. 注册与反注册
5. 资源对象关闭
6. 集和及时清理

内存泄漏检测

1. Profiler,Memory Analyzer(MAT)

Android studio自带内存、cpu、网络的变化，可以根据内存变化做具体分析

2. LeakCanary

框架集成，自动检测内存泄漏，生成app，提供内存泄漏栈堆情况

原理：绑定生命周期，对Activity和Fragment来说，在onDestory时将对象放入弱引用队列进行存储，触发gc后，如果还存在，则发生内存泄漏

3. StrictMode（很少用）

一款比较老的工具，ThreadPolicy可以检测主线程是否网络访问，是否读写。VMPolicy检测内存，Activity，Fragment是否泄漏，资源是否正确关闭

内存优化空间

1. 不必要的自动装箱

自动装箱就是将基础数据类型转化为对应的复杂类型，在HashMap的增删改查中充满了自动装箱问题，所以尽量避免这中问题，如将HashMap替换为SparseArray和ArrayMap

2. 内存复用

• 资源复用：通用字符串，颜色，布局
• 视图复用：类似于RecyclerView的优化复用
• 对象池：创建对象池，不用重复创建对象，类似于线程池，messae享元模式
• Bitmap对象复用：使用inBitmap属性可以告知Bitmap解码器尝试使用已经存在的内存区域，新解码的bitmap会尝试使用之前那张bitmap在heap中占据的pixel data内存区域。

3. 在App可用内存过低时主动释放内存

   在App退到后台内存紧张即将被Kill掉时选择重写Application中 onTrimMemory/onLowMemory 方法去释放掉图片缓存、静态缓存来自保。

4. 其他场景优化

   1. item被回收不可见时释放掉对图片的引用
      • ListView ：因此每次item被回收后再次利用都会重新绑定数据，只需在ImageView onDetachFromWindow的时候释放掉图片引用即可。
      • RecyclerView ：因为被回收不可见时第一选择是放进mCacheView中，这里item被复用并不会只需bindViewHolder来重新绑定数据，只有被回收进mRecyclePool中后拿出来复用才会重新绑定数据，因此重写Recycler.Adapter中的onViewRecycled()方法来使item被回收进RecyclePool的时候去释放图片引用。
   2. 如果使用字符串拼接，尽量使用StringBuilder、StringBuffer（内存抖动）
   3. 自定义view减少onDraw的耗时和执行次数
   4. 尽量使用静态内部类
   5. 尽量使用基础数据类型
   6. 合适的时候使用软/弱引用

线上监控方案

1. 常规监测

   1. 当内存使用超过80%，使用 Debug.dumpHprofData(String fileName)
      获取dump文件回传至服务器，而后手动分析
   2. LeakCanary集成并带到线上

2. Probe线上监测工具

3. LeakInspector

4. ResourceCanary

##最后
小编在网上收集了一些Android 开发相关的学习文档、面试题、Android 核心笔记等等文档，希望能帮助到大家学习提升，如有需要参考的可以直接