备注:Android Studio 的Enable ADB Integration
勾选 (Tools/Android 下)。
首先执行adb devices
来确保设备可用,然后启动Android Studio
,选择一个 Android 项目或者新建一个项目进入主面板,如果你有你的待测 App 的源码,那么最好进入你自己的 App 项目中,这样方便调试和定位问题。进入项目后,可以看到 Android Studio 的主面板左下角有一个Android
标签:
点击该标签打开Android
面板,如下图所示:
A:设备选择
B:可监控的 App 选择
C:内存的实时数据
重点来看 C 区域,横坐标记录从采集开始点到目前已经过去的时间,纵坐标是分配给 App 使用的内存总量 [Allocated+Free],蓝色区域表示已分配 [Allocated] 使用的的,灰色区域表示空闲 [Free] 未使用的。在坐标轴的右边可以看见具体数值。
GC 就是垃圾回收的意思,我们可以从 Memory monitor 看到何时发生了 GC event,当一个内存短时间内发生掉落,我们可以认为发生了 GC 操作。你也可以手动触发 GC,下图中的小车子就是触发 GC 的按钮,一旦按下就会回收那些没被引用的对象 (这个地方不能说没用的对象,因为没用的对象有可能是内存泄漏时的对象,后期会来研究):
Memory Monitor 工具为监控工具,是一种发现型或者说监控性质的工具,比如医生的四大技能 [望闻问切],[望] 是第一步。这里的 Memory Monitor 就是一种 [望] 的工具,目前我主要用它来看下面几个内存问题:
1.发现内存抖动的场景
2.发现大内存对象分配的场景
3.发现内存不断增长的场景
4.确定卡顿问题是否因为执行了 GC 操作
上面的第一段标记显示内存突然增加了 7M,我们也能看的很清楚,所以这个点我们要去定位了一下问题在哪里,是 Bitmap 还是什么原因造成的,第二段标记是内存抖动,很明显在很短的时间了发生了多次的内存分配和释放。而且在发生内存抖动的时候,也能感觉到 App 的卡顿,可以看出来是由于执行了 GC 操作造成的。
内存的不断增加通过 Memory monitor 很容易看出来,蓝色的曲线是一路高歌猛进的,一看便知。
Memory Monitor 也可以归纳到用于检测内存泄漏的问题,但是我没这么做,因为在实际过程中,到泄漏的点每一次很小的时候,你很难发现,没有 Heap Viewer 好使。如果泄漏的对象占用内存大的话,也能通过 Memory Monitor 看出来。
=。=。。。很好的文章。。。蛋实际。。。。是然并卵。。。。
这不是那个老外的视频吗? 这个工具挺好,但是怎么才能告诉开发怎么改呢?
#5 楼 @lihuazhang 老外那个视频我也看了,这个是我自己写的哈,告诉开发怎么改,还不能通过这一个工具就下定论,后续还有 heap viewer,allocation tracking,mat 等工具解说,会一步一步定位到问题,然后再跟研发沟通,当然,如果有源码自己尽量分析,直接告诉 RD 怎么改就行,但是这个需要点功力。
哇靠,好东西,期待每个工具的讲解,必须收藏
Memory Monitor,heap viewer,allocation tracking,mat
赞!同新手。我觉得 Memory Monitor 最容易看懂。
另外,你们别在这里秀日文。。。分かりますか
中国人何必说外语ˊ_>ˋ
#22 楼 @chenhengjie123 一起 study
MAT 可以扔啦,看到 monitor 左边那个小图标了没,直接 dump 一下,就 AS 里分析问题了
#27 楼 @shenkai600 暂时没有 MAT 全面
#27 楼 @shenkai600 的确。。MAT 还不能扔,AS 的内容太少了
虽然因为之前的测试环境主要用 Eclipse+ADT 搭的,但是还是觉得 Android Studio 的功能和体验很给力。
发生内存抖动也不是什么坏事情吧?没被引用到的或者被覆盖的 objects 总归是要被回收的. 看图像是 minor GC, 总比 full GC 好吧.
这个前提是不是要有源码?
测试的担心开发的不懂这个不懂那个,是不是有点。。。。