android3.0内存檢測,Android Profiler内存检测

Memory Profiler是Android Profiler中的一个组件,Android Profiler是Android3.0用来替换之前Android Monitor的观察工具,主要用来观察内存、网络、cpu温度。

Memory Profiler它能够让你识别出来内存泄露和内存抖动,导致应用卡顿,anr和crash,他可以给你展示一个内存使用的真实图表,让你知道当时内存使用情况,还能强制内存回收,和跟踪内存分配

打开方式

9df21ef70b5386ad946531d25903febe.png

fb150c782326b22f351eaa1da8b43f24.png

为什么去观察应用内存使用情况

Memory Profiler是用来解决内存分配中产生抖动,导致应用卡顿、anr和crash问题,在Android系统内存管理上,它是提供一套内存回收机制去回收无用的对象,

其实就是Dalvik虚拟机的垃圾回收器,当垃圾回收器启动回收机制的时候,其实会对应用的运行产生一点影响,但是这种影响来说一般是微乎其微的,觉察不到,但是如果你的内存分配比垃圾回收快很多,这种情况可能导致垃圾回收器回收内存不及时,从而导致应用出现卡顿的现象(其实是内存抖动所产生的影响),另外一个问题是内存泄露,内存的持续泄露可能导致内存溢出,从而app运行出现oom异常

Memory Profiler通过以下方面防止上面出现的问题:

1.观察不必要的内存分配(这种内存分配导致效率降低)

2.Dump the java heap去观察指定时间对象在内存中的分配情况,若干次Dump能够帮助你发现内存泄露

3.测试极端的用户交互情况下的内存分配(比如狂点某个请求按钮),看看内存使用情况如何,是否出现内存抖动

9b5fe75beb1450dff980954cfde62e4b.png

1:强制内存回收

2:Dump the java heap

3:开始/停止记录内存分配情况

4:放大/缩小时间线

5:实时播放内存分配情况

6:发生一些事件的记录(如Activity跳转,事件的输入、屏幕的旋转)

7:使用的内存时间线

关于顶部的几种内存类型介绍

Java:java代码分配的内存

Native:c/c++代码分配的内存(有时候其实并没有使用c/c++代码,但还是会有Native的内存分配,因为Android Framework会去通过java代码访问一些需要使用Native的资源,如图像资源的Bitmap)

Graphics:图像缓存等,包括GL surfaces,GL textures等

Stack:栈内存(包括java和c/c++)

Code:代码的内存分配(例如代码,资源,libs等等)

Other:这个是系统都不知道什么类型的内存

Allocated:java分配的对象个数

如何观察对象分配情况

9350f78e105f23e829cf43a276d8cda2.png

查看内存分配情况,也就是我们前面提到需要关注什么类型的对象被分配,分配了多大空间

1.在Class Name列看一下有没有异常分配的对象,个数很多,占用内存比较大,点击头部Class Name进行一个按字母排序操作,点击Class Name面板下面的类名可以看到instance View面板的详细对象信息

2.点击Instance View面板上的对象,可以看到调用栈信息和调用的线程

3.在Call Stack中点击可以跳转到实际的代码

以上是捕获一段时间的内存分配情况,如果想捕获一瞬间的内存分布需要用到heap dump

捕获一个heap dump

捕获一个heap dump观察某一个时间点的对象分配情况,注意之前介绍的是一个时间段,而这里是时间点。它有助于帮助我们分析内存泄露,比如当我们使用一段时间后

捕获了一个heap dump这个heap dump里面发现了并不应该存在的内存对象,这说明存在内存泄露了,通过一个 heap dump你可以看到以下内容

1.你的app分配了什么样的对象类型,每个类型分配了多少个和大小

2.使用了多少内存

3.每个对象在代码中的使用位置

4.对象分配的调用栈情况

捕获一个heap dump在工具栏中点击之前面板介绍中的按钮2,稍等一会变能够看到类似于之前内存分配的面板弹出

bbc512e483f2d961e14b56eb21a89457.png

在图片中可以看到如下列

Class Name:类名

Alloc Count:对象个数

Native Size:c/c++层内存大小(byte)

Shallow Size:java层内存大小(bytes)

Retained Size:这个是这个类中所引用到的对象的总大小*该类对象的个数

当点击app heap下拉列表会出现3个选项

Defaule heap:

App heap:app中的堆内存

Zygote heap:这个按照官方的解释是来自安卓系统fork进程的地方产生的写数据备份

当点击Arrange by class下拉列表会出现3个选项

Arrange by class:根据类名进行分组

Arrange by package:根据包名进行分组

Arrange by callstack:根据调用栈进行分配(这个目前也不是太理解)

当我们点击其中一个类的时候会弹出一个新的instance View面板,如下图:

分析heap,按照以下步骤:

1.浏览Class Name列表,看看有没有大量的对象存在,并且这些对象你认为是不应该存在的,可能存在内存泄露的情况,点击类名可以看到详细的对象信息

2.在这个Instance View面板中,点击一个实例References面板就会显示出来,里面都是使用该Instance的Reference,点击箭头可以看到引用它的所有区域,点击鼠标右键可以选择 go to instance去看到引用该引用的引用,或者jump to source去看调用的源代码

另外heap dump也是可以保存成为HPROF文件的,点击如下按钮可保存起来,用于以后分析,或用其他工具分析

763d45e4cc5e8b21617bb242e7d874ab.png

一般出现内存泄露的原因有:

1.长期引用到Activity,Context,View,Drawable的对象

2.非静态内部类,例如Runnable她可以引用到Activity的实例

3,一些长期的缓存

具体分析一下 如何使用Memory Profiler查找内存泄露

查找内存泄露有以下几个方式

1.一般排查内存泄露的方式是,启动应用,看一下当前内存使用多少,使用应用一段时间后,退回到应用首页,看看当前内存又是多少,进行一次heap dump看看结果,分析一下有没有可疑对象分配(比如说大量重复的Activity,同一类型的对象比较多,对象内存占用较大)

2.发现可疑点后,通过分析结果,可疑找到相应代码,找到代码当然也能找到使用代码的场景,例如Activity泄露,返回进行画面跳转(如果你的应用支持横竖屏切换的话,也可以反复旋转屏幕),然后强制gc回收,看看内存是否存在只增不减的情况

3.也可以使用allocation跟踪一段时间内存分配情况,拿出来分析

正式例子

启动一个类似内存泄露的app,然后跑一段时间,进行了一次heap dump,结果如下

ed863bf929dd8efca7ea587266cd7d3f.png

很明显发现一个可疑的类OutOfMemActivity,它存在多个实例,实际上在已知该app业务逻辑中是不应该会有这么多OutOfMemActivity实例的,于是点开他的Instance View

可疑点如红色箭头所指,因为外部类实例引用到Activity都是不正常的操作,这里Broadvast的实例引用到了Activity

e711c23932fde70131c3585cfbebea9d.png

点击跳转到源码,发现是内部类引用到外部类实例(Activity)的情况导致内存泄露

df69241fd120263be80b6be433c99152.png

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值