内存优化

studio

        使用android studio中的monitors可以获取内存变化的hprof文件，并且也可打开该文件。

FinalizerReference

        参考

        分析内存时，FinalizerReference对象占了很大的内存，它内部引用了重写了finalize()方法的对象。

其一部分代码为：

    // This queue contains those objects eligible for finalization.    public static final ReferenceQueue<Object> queue = new ReferenceQueue<Object>();    private static FinalizerReference<?> head = null;        private FinalizerReference<?> prev;    private FinalizerReference<?> next;    public FinalizerReference(T r, ReferenceQueue<? super T> q) {        super(r, q);    }    public static void add(Object referent) {        FinalizerReference<?> reference = new FinalizerReference<Object>(referent, queue);        synchronized (LIST_LOCK) {            reference.prev = null;            reference.next = head;            if (head != null) {                head.prev = reference;            }            head = reference;        }    }

        从中可以看出，以队列形式存储对象的引用，prev指向前驱元素，next为后继元素。

        每一个对象被回收时，会创建一个FinalizerReference对象，而FinalizerReference继承于Reference。在Reference中会将super(r,q)中的参数分别记为referent与queue。因此FinalizerReference中的referent与queue分别表示当前fr代表的将要被回收的对象，而queue为FR#queue。

        上图为从studio中打开hprof文件，点击class name视图中的FinalizerReference，在instance视图中的两个finalizerReference对象。

        从中可以发现queue是同一个。referent指的是具体的待回收的对象，而prev与next为链表中的前、后元素。

Analyzer Tasks

        打开hprof文件时，最右边有一个Analyzer Tasks按钮，点击一下即可启动该视图。如下：

        点击其中的绿色按钮，即可自动进行分析。其中duplicate strings指的是重复的字符串，leaked activities指的是有可能内存泄漏的activity，主要分析的也就是该选项。

        点开具体的内存泄漏的activity，可以在底部的reference tree中看到该activity的引用树。显示成蓝色的部分就是占内存比较大的对象。如下：

MAT

        studio生成hprof文件是无法直接使用mat打开，需要进行转换。转换方式有两种：

        1，需要使用sdk/platform-tools中的hprof-conv进行转换。一般使用命令行形式，输入的命令为：hprof-conv src.hprof dst.hprof。src指studio导出的hprof文件所在的位置，dst为转换成的hprof的位置（自己指定）。

        2，打开studio中的Captures视图，右键某个hprof文件，export to standard .hprof。

        具体的可参考mat使用及MAT - Memory Analyzer Tool 使用进阶。

shallow size与retained size

        参考

shallow size

        对象本身所占有的内存，不包含对象引用的对象所占有的内存。

        非数组的对象的Shallow size的大小取决于它的成员变量的个数与类型（成员变量为数组时，也只是占4个字节，而不是数组的shallow size）。

        数组的shallow size的大小取决于它的长度以及元素的类型（基本数据类型还是引用数据类型），它同样也不包含各个元素的Shallow Size。例如：

    private class Test{//12 不同环境下得到的值可能不一样，这里是在mac环境下的。        private View view;//4        private String str;//4        private int age;//4        private boolean a; //4        private View[] bytes = {new View(MainActivity.this),new View(MainActivity.this),new View(MainActivity.this),new View(MainActivity.this)};//4    }

其结果为：

        从上图可以看出，Test的shallow size为32，具体分布在代码注释中 。它并没有包含bytes数组的Shallow Size，只是取决于它的成员变量的个数与每一个变量的类型。同样，它也没有包含this$0的Shallow Size。

        this$0指的是内部类中的外部类实例。本例中，Test是MainActivity的一个内部类，所以this$0指的就是外部类MainActivity的实例。

        对于数组bytes，它的Shallow Size是16，因为它包含了4个View对象。它也没有包含每一个View的Shallow Size——每一个View的Shallow Size是452。

retained size

        当前对象自身的shallow size与当前对象被回收后，gc所回收的对象的内存之和。换句话说，retained size代表的是当前对象被回收时，gc所能回收的内存的总和。如果对象B必须经过A才可达，那么B的shallow size就会统计到A的retained size中。

        通常来说，查看内存时Shallow Size是没啥意义的，一般都是看Retained Size。