Android性能优化第(二)篇---Memory Monitor检测内存泄露

版权声明:本文为LooperJing原创文章,转载请注明出处!

多练习多写代码.jpg

上篇说了一些性能优化的理论部分,主要是回顾一下,有了理论,小平同志又讲了,实践是检验真理的唯一标准,对于内存泄露的问题,现在通过Android Studio自带工具Memory Monitor 检测出来。性能优化的重要性不需要在强调,但是要强调一下,我并不是一个老司机,嘿嘿!没用过这个工具的,请睁大眼睛。如果你用过,那么就不用在看这篇博客了。

先看一段会发生内存泄露的代码

public class UserManger {

    private static UserManger instance;

    private Context context;

    private UserManger(Context context) {
        this.context = context;
    }

    public static UserManger getInstance(Context context) {
        if (instance == null) {
            instance = new UserManger(context);
        }
        return instance;
    }
}

public class MainActivity extends AppCompatActivity {

    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_main);
        UserManger userManger = UserManger.getInstance(this);
    }
}

代码很简单,就是一个单利模式泄露的场景,我们现在的关心的不是代码本身,而是如何将代码里面的内存泄露给找出来。但是对于上面的代码发生内存泄露的原因还是有必要提一下。

上篇博客说了,内存泄漏产生的原因是:当一个对象已经不需要再使用了,本该被回收时,而有另外一个正在使用的对象持有它的引用从而就导致,对象不能被回收。这种导致了本该被回收的对象不能被回收而停留在堆内存中,就产生了内存泄漏。

在上面的代码中,发生泄露的不是UserManger,而是MainActivity,UserManger中有一个静态成员instance,其生命周期和应用程序的生命周期一致,当退出应用时,才能被销毁,但是当GC准备回收MainActivity时,结果呢MainActivity的对象(this)在被UserManger所引用,UserManger本身又不能被干掉,所以就发生了内存泄露。

monitors.png

Memory Monitor是Android Monitors中的一种,Monitors主要包括四种,Memory Monitor ,CPU Monitor ,NetWork Monitor, GPU Monitor ,今天介绍的是Memory Monitor ,其他的Monitor,在后面也准备讲。

  • Memory Monitor界面
Memory Monitor.png
  • 图中水平方向是时间轴,竖直方向是内存的分配情况
  • 图中深蓝色的区域,表示当前正在使用中的内存总量,浅蓝色或者浅灰色区域,表示空闲内存或者叫作未分配内存。
  • 左上角工具栏三个圆圈按钮依次代表
    GC按钮 ,可以手动GC,回收程序垃圾
    内存快照(Dump Java Heap) ,点击可以生成一个文件(包名+日期+“.hprof”),可以记录摸一个时间点内,程序内存的情况
    Allocation Traking ,点击一次开始, 再次点击结束,也可以可以生成一个文件。

回到我们的程序,多点击几次GC,看一下这个应用的内存使用情况。

内存使用情况.jpg

可以看到现在已经分配的内存有19.68M,我把手机旋转一下,在看。


旋转后内存使用情况.png

可以看到现在的内存使用量是21.09M,还是一样的界面,却多了1.41M!!!这很关键。

接下来,我们找一下,哪里发生了泄露。点击Dump Java Heap,生成快照文件tool.test.memory.memoryleak_2016.11.13_21.38.hprof,Android Studio 自动弹出HPROF Viewer来分析它。

快照文件分析.png

现在介绍一下HPROF Viewer的用法

  • HPROF Viewer查看方式
    左上角两个红框,是可选列表, 分别是用来选择Heap区域, 和Class View的展示方式的.
    Heap类型分为:
    App Heap -- 当前App使用的Heap
    Image Heap -- 磁盘上当前App的内存映射拷贝
    Zygote Heap -- Zygote进程Heap(每个App进程都是从Zygote孵化出来的, 这部分基本是framework中的通用的类的Heap)
    Class List View -- 类列表方式
    Package Tree View -- 根据包结构的树状显示

我通常点击App heap下面的Classs Name把Heap中所有类按照字母顺序排序,然后按照字母顺序查找。

  • HPROF Viewer主要分ABC三大板块
    板块A:这个应用中所有类的名字
    版块B:左边类的所有实例
    板块C:在选择B中的实例后,这个实例的引用树
  • A板块左上角列名解释
列名 解释
Class Name 类名,Heap中的所有Class
Total Count 内存中该类这个对象总共的数量,有的在栈中,有的在堆中
Heap Count 堆内存中这个类 对象的个数
Sizeof 每个该实例占用的内存大小
Shallow Size 所有该类的实例占用的内存大小
Retained Size 所有该类对象被释放掉,会释放多少内存
  • B板块右上角上角列名解释
列名 解释
Instance 该类的实例
Depth 深度, 从任一GC Root点到该实例的最短跳数
Dominating Size 该实例可支配的内存大小

B板块右上角有个"的按钮, 点击会进入HPROF Analyzer的hprof的分析界面:


Analyzer Tasks.png

"
在这个界面中可以直接把内存泄露可能的类找出来。

下面分析一下MainActivity的泄露情况
MainActivity发生内存泄露.png
  • 一个Activity应该只有一个实例,但是从A区域来看 total count的值为2,heap count的值也为2,说明有一个是多余的。
  • 在B区域中可以看见两个MainActivity的实例,点击一个看他的引用树情况
  • 在C区域中可以看到MainActivity的实例Context被UserManger的 instance引用了,引用深度为1.
  • 在Analyzer Tasks 区域中,直接告诉你Leaked Activities,MainActivity包含其中

多方面的证据表明MainActivity发生了内存泄露

解决方案

public class UserManger {

    private static UserManger instance;

    private Context context;

    private UserManger(Context context) {
        this.context = context;
    }

    public static UserManger getInstance(Context context) {
        if (instance == null) {
            if(context!=null){
                instance = new UserManger(context.getApplicationContext());
            }
        }
        return instance;
    }
}

不要用Activity的Context,因为Activity随时可能被回收,我们用Application的Context,Application的Context的生命周期是整个应用,不回收也没有关系。

Memory Monitor获得内存的动态视图,Heap Viewer显示堆内存中存储了什么,可惜Heap Viewer不能显示你的数据具体分配在代码的何处,如果还不过瘾,想知道具体是哪些代码使用了内存,还有一个功能是Allocation Tracker,用来内存分配追踪。在内存图中点击途中标红的部分,启动追踪,再次点击就是停止追踪,随后自动生成一个alloc结尾的文件,这个文件就记录了这次追踪到的所有数据,然后会在右上角打开一个数据面板
Allocation Tracker启动追踪

Allocation Tracker启动追踪.png

Allocation Tracker查看方式

Allocation Tracker查看方式

有两种查看方式,默认是Group by Method方式

  • Group by Method:用方法来分类我们的内存分配
  • Group by Allocator:用内存分配器来分类我们的内存分配

从上图可以看出,首先以线程对象分类,Size是内存大小,Count是分配了多少次内存,点击一下线程就会查看每个线程里所有分配内存的方法

  • Group by Method方式

    每个线程里所有分配内存的方法.png

    OK,-Memory Monitor

  • ** Group by Allocator方式**


    EY%HY_B74%BUE22C6$G~CTP.png

    右键可以直接跳到源码

- 扇形统计图

AQFHT$@7TYP0S_1`DU@%S%6.png

点击统计图按钮,会生成上图,扇形统计图是以圆心为起点,最外层是其内存实际分配的对象,每一个同心圆可能被分割成多个部分,代表了其不同的子孙,每一个同心圆代表他的一个后代,每个分割的部分代表了某一带人有多人,你双击某个同心圆中某个分割的部分,会变成以你点击的那一代为圆心再向外展开。

除了扇形图,还有柱状图可选择,可以自己操作,OK,Memory Monitor到此结束,下一篇性能优化部分博客仍然是检测内存泄露,明天上班,晚安!

最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 159,015评论 4 362
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 67,262评论 1 292
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 108,727评论 0 243
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 43,986评论 0 205
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 52,363评论 3 287
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 40,610评论 1 219
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 31,871评论 2 312
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 30,582评论 0 198
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 34,297评论 1 242
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 30,551评论 2 246
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 32,053评论 1 260
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 28,385评论 2 253
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 33,035评论 3 236
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 26,079评论 0 8
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 26,841评论 0 195
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 35,648评论 2 274
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 35,550评论 2 270

推荐阅读更多精彩内容