ART:Android从4.4引入了一个ART（Android runtime），之前管理应用的runtime是用的Dalvik. ART增加了预编译、优化GC（如并行处理、压缩GC时间、GC处理最近分配的Object更快...）
Memory Leak（内存泄露）：内存已经不被使用，但是GC时没有识别出来。导致一直保存，内存无法被释放。
Memory，GC，Performance关系：
简单地说Memory会被GC，内存被分割程不同的空间。根据不同的内存分配类型（type of allocation)和未来GC的最优化处理，会在不同的Space分配内存。当然也根据不同的Android Runtime类型。
而Space有一定容量，当容量变大时就需要GC，来为未来对象分配留下空间。根据Android runtime版本的不同，GC的行为会有差异。在Dalvik中GC事件将会停止运行World Event，意味着任何对正在运行的代码都将停止，知道GC运行完。
1.我们前面说的每帧是16ms。你GC多次，会导致画面不流畅。
2.程序处理流程可能强制 GC更频繁，或者使GC持续的时间更长。例如 分配一个大的对象在一个循环时间很长的代码里，将会污染很多的内存堆，导致GC更频繁。还有Memory leak（内存泄露），导致其在GC是泄露的内存不能被释放。让GC更频繁发生。
比较容易发现的：无用对象之间循环引用。困难的：持有加载该对象的ClassLoader。所以要借助工具辅助。
用MemoryMonitor去初步确定，再用HeapViewer定位到类，用Allocation Tracer定位到代码上。第一个在Android Studio，6 Android这个tab的Memory中，后两个工具都在DDMS中。
1数据分析：
a)灰色是剩余可分配内存，蓝色是已分配的内存。
b）每个尖峰就是GC时间发生的地方。
如果在短期出现大量尖峰（如下图）。即大量GC事件发生，就可能有内存泄露发生。
如图可以看出在绿色框内，很短的事件内出现了多个尖峰（即GC事件），说明该段时间有大量对象分配，并且GC并没有成功释放掉内存。而多了GC事件会卡顿界面。
而后来蓝色区域增加，可灰色区域剩余更少。证明系统给APP增加了内存分配总额，但是仍旧无法满足。
定位是否有内存泄露
可以看到分配的对象，具体分配空间。一次GC后剩余了多少，谁没有被GC掉。定位内存泄露到某个对象上。
使用方法：点击左上角圆柱体（里面有绿色）Update Heap，然后在右侧Heap的tab上点击Cause GC。
可以用来监测在那个方法中分配了大量的类。定位内存泄露到代码上
总的来说当发现程序变慢，或者崩溃时，用MemoryMonitor从大体上监测APP是否为内存泄露、OOM。
然后，用HeapViewer查看具体是哪个类、对象在Heap上分配的空间过多。
最后用AllocationTracer进行代码上的定位。
原文地址：http://blog.csdn.net/zhjali123/article/details/45932639
