android内存性能优化（Android内存优化）

Java虚拟机Java内存模型

Android内存优化

Java虚拟机

Java内存模型

程序计数器

线程计数器中如果正在执行java方法，计数器记录的是当前指令的地址，

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

堆

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

方法区

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

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

个版本区别

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

问题：

1. 堆和栈的区别：栈：基本数据类型变量（int、short、long、byte、float、double、boolean、char）以及对象的引用变量堆：存储java对象堆中的对象对所有线程可见，栈内存只属于一个线程堆的内存空间远远大于栈
2. 为什么删除方法区？启动大小固定，很难调优，容易发生OOM元空间在本地内存中分配，本地内存足够就不会溢出

GC垃圾回收

判断对象是否存活

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

回收算法

1. 标记清除算法：标记完后对对象进行回收，使用在 老年代缺点：效率不高，标记和清除效率不高差生大量碎片空间，导致空间浪费
2. 复制算法：将可用对象复制到新的连续空间，删除之前的空间缺点：浪费50%的内存，复制长生存期的对象效率低下，所以该算法使用在 新生代
3. 标记整理算法：前期使用标记清除算法，后续使用整理算法，使对象排列称联系空间，使用在 老年代
4. 分代收集算法：对数据进行分代，每一代执行不同的回收算法

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

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

Minor GC ： 清理年轻代Major GC ： 清理老年代Full GC ： 清理整个堆空间，包括年轻代和永久代

四大引用介绍

简述

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

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/26647823). 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 - timestamp <= free_heap * ms_per_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类，指向这个新建的对象

内存问题

内存优化意义

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. 内存复用

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

线上监控方案

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

上面就是小居数码小编今天给大家介绍的关于（Android内存优化）的全部内容，希望可以帮助到你，想了解更多关于数码知识的问题，欢迎关注我们，并收藏，转发，分享。

94%的朋友还想知道的：

• ps软件总是说内存教你一招解决（ps软件内存不足怎么回事）
• 微信清理内存的正确方法（微信老是占内存怎么办）
• ps内存不足无法保存怎么办（ps存储不足怎么办）
• 软件测试常用的性能测试指标有哪些（软件性能测试有哪些性能指标）

（396）个朋友认为回复得到帮助。