内存分析

71 阅读 0 评论 47 点赞

我是靠谱客的博主老实手链，最近开发中收集的这篇文章主要介绍内存分析，觉得挺不错的，现在分享给大家，希望可以做个参考。

概述

本文介紹android分析内存的几种方法。大概有四个方法可以分析内存：Memory，ART的GC Log，DDMS的Heap分析，内存分析工具进行分析（本文主要讲下MAT的分析方法）。

1.Monitors下的可视图Memory分析内存

android studio提供了Monitors可以观察Memory，CPU，Network和GPU的使用情况。

Memory实时显示了内存的的占用情况。蓝色部分显示占用的内存，灰色部分表示空闲的内存。

Memory大体可以分析出下列情况

（1）可以观察到哪个地方内存占用暴增，也可以观察到内存占用的减少

（2）如果内存占用该下降时，但没减少，可以分析出该模块出现内存泄露

（3）如图红色框显示则出现了内存抖动。当一段时间大量的创建和回收对象就会造成内存抖动，因为创建对象会占用内存，回收对象时释放内存。因为当发生GC时，会暂停其它线程，如果频繁GC会造成程序的卡顿。

如下代码。通过定时器不断的Copy Bitmap对象，因为创建Bitmap时会暂用大量内存，而又马上释放，则出现如图内存抖动的现象。

public class MainActivity extends Activity {
private Button button;
private Timer timer;
private TimerTask timerTask;
private Bitmap bitmap;
private boolean flag;
private Handler handler = new Handler(){
@Override
public void handleMessage(Message msg) {
super.handleMessage(msg);
switch (msg.what){
case 1:
Bitmap bitmap1 = bitmap.copy(Bitmap.Config.ARGB_8888,true);
bitmap1.recycle();
break;
default:
break;
}
}
};
@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_main);
button = (Button) findViewById(R.id.button);
button.setOnClickListener(new View.OnClickListener() {
@Override
public void onClick(View view) {
if(!flag){
start();
}else {
stop();
}
}
});
}
private void start(){
bitmap = BitmapFactory.decodeResource(getResources(),R.mipmap.brother);
flag = true;
timer = new Timer();
timerTask = new TimerTask() {
@Override
public void run() {
handler.sendEmptyMessage(1);
}
};
timer.schedule(timerTask,0,100);
}
private void stop(){
flag = false;
if(timer != null ){
timer.cancel();
}
}
}

2.GC之后都会在Logcat输出一段信息

在ART模式下输出的Logcat信息格式如下

I/art: <GC_Reason> <GC_Name> <Objects_freed>(<Size_freed>) AllocSpace Objects, <Large_objects_freed>(<Large_object_size_freed>) <Heap_stats> LOS objects, <Pause_time(s)>

手动进行了GC,如下是实例输出

I/art: Explicit concurrent mark sweep GC freed 52170(2MB) AllocSpace objects, 33(1608KB) LOS objects, 40% free, 16MB/27MB, paused 800us total 85.768ms

因为是手动的GC,所以例子输出的GC Reason为Explicit

如下是各个字段的意思和情况

GC Reason
什么触发了GC，以及属于哪种类型的垃圾回收，一般出现的值包括：

Concurrent
并发GC，不会挂起app线程，这种GC在后台线程中运行，不会阻止内存分配

Alloc

GC被初始化，app在heap已满的时候请求分配内存，此时，GC会在当前线程（请求分配内存的线程）执行

Explicit

GC被app显式请求，例如，通过调用 System.gc() 或者 runtime.gc() 。和Dalvik一样，ART建议相信GC，尽可能地避免请求显式GC。不建议使用显式GC，因为会阻塞当前线程，并引起不必要的CPU周期。如果GC导致其它线程被抢占的话，显式GC还会引发jank

NativeAlloc
来自native分配的native memory压力引起的GC，比如Bitmap或者RenderScript对象

CollectorTransition
heap变迁引起的GC，运行时动态切换GC造成的，垃圾回收器变迁过程包括从free-list backed space复制所有对象到bump pointer space（反之亦然）。当前垃圾回收器过渡只会在低RAM设备的app改变运行状态时发生，比如从可察觉的停顿态到非可察觉的停顿态（反之亦然）

HomogeneousSpaceCompact
Homogeneous space compaction是free-list space与free-list space的合并，经常在app变成不可察觉的停顿态时发生，这样做的主要原因是减少RAM占用并整理heap碎片

GC Name
ART有几种不同的GC

Concurrent mark sweep (CMS)
全堆垃圾收集器，负责收集释放除image外的所有空间
Concurrent partial mark sweep
差不多是全堆垃圾收集器，负责收集除image和zygote外的所有空间
Concurrent sticky mark sweep
分代垃圾收集器，只负责释放从上次GC到现在分配的对象，该GC比全堆和部分标记清除（mark sweep）执行得更频繁，因为它更快而且停顿更短
Marksweep + semispace

非并发的，复制堆过渡和homogeneous space compaction（用来整理heap碎片）使用的GC

Objects freed
本次GC从非大对象空间（non large object space）回收的对象数目

Size freed
本次GC从非大对象空间回收的字节数

Large objects freed
本次GC从大对象空间里回收的对象数目

Large object size freed
本次GC从大对象空间里回收的字节数

Heap stats
可用空间所占的百分比和[已使用内存大小]/[heap总大小]

Pause times
一般情况下，GC运行时，停顿次数和被修改的对象引用数成比例。目前，ART CMS GC只会在GC结束的时停顿一次，GC过渡会有一个长停顿，是GC时耗的主要因素