zoukankan      html  css  js  c++  java
  • 使用Android Studio调试内存问题

    http://blog.csdn.net/yutao52shi/article/details/50055669

    前言

    内存问题对于Android开发者是永远的痛。如果一个android程序员说他没有遇到过OutOfMemory,那只能说他绝对不是做Android的。以往在ADT年代,都是使用eclipse的Mat(http://www.eclipse.org/mat/)插件来做内存分析。在使用了Android Studio开发后,发现AS不仅带来了不少编码上的便利,同时还带来了很多有用的工具。其中的内存分析工具就是一个经典。

    正文

    打开AS,在底部的Android Monitor里面就能发现这个Memory的Tab,在里面可以实时的看到内存的走势,能够在自测中发现什么地方会造成内存暴增,同时也很容易的看出GC point(内存突然下降一大截,肯定就是做了Full GC)。
    这里写图片描述
    看到右边有4个按钮,第一个是暂停,暂时不做任何讲解了。下面详细讲解其他三个按钮的功能。

    Initial GC

    这个命令会让APP执行一次Full GC。这个功能使用场景不是很多,我一般是会在Dump Heap之前执行一次,这样会减少很多无用的对象。点击之后,有时候能够明显看出内存变化
    这里写图片描述

    Dump Java Heap

    这个功能是我用得最多,也是认为最好用的内存分析功能。因为基本能够通过它观察出哪些对象占用了巨量内存,并且能够找出它们被什么对象把持住,导致无法释放。点击Dump Java Heap后,APP会Freeze住。然后就是等待,这个时候最好别做其他事情,否则可能失败。大概几十秒后,就会进入读取hprof文件的界面了。
    这里写图片描述
    从途中可以基本看出来,有一个10Mac大小的Bitmap被gpuimage里面的模块把持住了(由于被混淆,所以类名是f)。通过这些信息,基本就可以解决绝大部分OOM问题了。

    Start Allocation Tracking

    这个功能可以记录一段区间内各个线程各个方法的内存分配情况。我用得并不多,主要用于调试在复杂系统里面短时间内存暴增造成GC频繁的Case。使用方法:先点击一次,然后会看到Memory Recorder开始转动,然后自己开始在APP上面做相应的操作。在合适的时间再点一次,结束记录。
    这里写图片描述
    然后APP会Freeze,过一会儿就会进入到alloc文件的打开界面了。通过分析alloc数据,我们可以知道某一个thread里面的所有的调用过的方法所分配的堆大小,通过这些数据可以让我们针对方法级别堆程序进行优化。
    这里写图片描述

    题外话

    除了即时Dump即时查看,我们也可以用AS直接打开.hprof和.alloc文件,十分方便打开一些其他人员(比如QA)Dump出来的Heap dump。
    此外,这些工具虽然在以前的DDMS里面也带了,但是个人觉得在AS里面进行了一些Improvement,界面十分简洁,关键数据一目了然。基本能够满足日常生产需求了。但是如果要做更加深入的分析,还是需要借助外部工具,AS里面带的hprof查看工具远没有MAT的数据详细,只是提供了一些关键数据。

  • 相关阅读:
    398. Random Pick Index
    382. Linked List Random Node
    645. Set Mismatch
    174. Dungeon Game
    264. Ugly Number II
    115. Distinct Subsequences
    372. Super Pow
    LeetCode 242 有效的字母异位词
    LeetCode 78 子集
    LeetCode 404 左叶子之和
  • 原文地址:https://www.cnblogs.com/onelikeone/p/7115259.html
Copyright © 2011-2022 走看看