13518219792
常用的Android性能优化方法：
创新互联成立十载来，这条路我们正越走越好，积累了技术与客户资源，形成了良好的口碑。为客户提供成都做网站、成都网站制作、网站策划、网页设计、国际域名空间、网络营销、VI设计、网站改版、漏洞修补等服务。网站是否美观、功能强大、用户体验好、性价比高、打开快等等，这些对于网站建设都非常重要，创新互联通过对建站技术性的掌握、对创意设计的研究为客户提供一站式互联网解决方案，携手广大客户，共同发展进步。
一、布局优化：
1）尽量减少布局文件的层级。
层级少了，绘制的工作量也就少了，性能自然提高。
2）布局重用 include标签
3）按需加载：使用ViewStub,它继承自View,一种轻量级控件，本身不参与任何的布局和绘制过程。他的layout参数里添加一个替换的布局文件，当它通过setVisibility或者inflate方法加载后，它就会被内部布局替换掉。
二、绘制优化：
基于onDraw会被调用多次，该方法内要避免两类操作：
1）创建新的局部对象，导致大量垃圾对象的产生，从而导致频繁的gc，降低程序的执行效率。
2）不要做耗时操作，抢CPU时间片，造成绘制很卡不流畅。
三、内存泄漏优化：
1）静态变量导致内存泄漏 比较明显
2）单例模式导致的内存泄漏 单例无法被垃圾回收，它持有的任何对象的引用都会导致该对象不会被gc。
3）属性动画导致内存泄漏 无限循环动画，在activity中播放，但是onDestroy时没有停止的话，动画会一直播放下去，view被动画持有，activity又被view持有，导致activity无法被回收。
四、响应速度优化：
1）避免在主线程做耗时操作 包括四大组件，因为四大组件都是运行在主线程的。
2）把一些创建大量对象等的初始化工作放在页面回到前台之后，而不应该放到创建的时候。
五、ListView的优化：
1）使用convertView，走listView子View回收的一套：RecycleBin 机制
主要是维护了两个数组，一个是mActiveViews,当前可见的view,一个是mScrapViews，当前不可见的view。当触摸ListView并向上滑动时，ListView上部的一些OnScreen的View位置上移，并移除了ListView的屏幕范围，此时这些OnScreen的View就变得不可见了，不可见的View叫做OffScreen的View，即这些View已经不在屏幕可见范围内了，也可以叫做ScrapView，Scrap表示废弃的意思，ScrapView的意思是这些OffScreen的View不再处于可以交互的Active状态了。ListView会把那些ScrapView（即OffScreen的View）删除，这样就不用绘制这些本来就不可见的View了，同时，ListView会把这些删除的ScrapView放入到RecycleBin中存起来，就像把暂时无用的资源放到回收站一样。
当ListView的底部需要显示新的View的时候，会从RecycleBin中取出一个ScrapView，将其作为convertView参数传递给Adapter的getView方法，从而达到View复用的目的，这样就不必在Adapter的getView方法中执行LayoutInflater.inflate()方法了。
RecycleBin中有两个重要的View数组，分别是mActiveViews和mScrapViews。这两个数组中所存储的View都是用来复用的，只不过mActiveViews中存储的是OnScreen的View，这些View很有可能被直接复用；而mScrapViews中存储的是OffScreen的View，这些View主要是用来间接复用的。
2）使用ViewHolder避免重复地findViewById
3)快速滑动不适合做大量异步任务，结合滑动监听，等滑动结束之后加载当前显示在屏幕范围的内容。
4）getView中避免做耗时操作，主要针对图片：ImageLoader来处理(原理：三级缓存)
5）对于一个列表，如果刷新数据只是某一个item的数据，可以使用局部刷新，在列表数据量比较大的情况下，节省不少性能开销。
六、Bitmap优化：
1）减少内存开支：图片过大，超过控件需要的大小的情况下，不要直接加载原图，而是对图片进行尺寸压缩，方式是BitmapFactroy.Options 采样，inSampleSize 转成需要的尺寸的图片。
2）减少流量开销：对图片进行质量压缩，再上传服务器。图片有三种存在形式：硬盘上时是file，网络传输时是stream，内存中是stream或bitmap，所谓的质量压缩，它其实只能实现对file的影响，你可以把一个file转成bitmap再转成file，或者直接将一个bitmap转成file时，这个最终的file是被压缩过的，但是中间的bitmap并没有被压缩。bitmap.compress(Bitmap.CompressFormat.PNG,100,bos);
七、线程优化：
使用线程池。为什么要用线程池？
1、从“为每个任务分配一个线程”转换到“在线程池中执行任务”
2、通过重用现有的线程而不是创建新线程，可以处理多个请求在创建销毁过程中产生的巨大开销
3、当使用线程池时，在请求到来时间 ，不用等待系统重新创建新的线程，而是直接复用线程池中的线程，这样可以提高响应性。
4、通过和适当调整线程池的大小 ，可以创建足够多的线程以使处理器能够保持忙碌状态，同时还可以防止过多线程相互竞争资源而使应用程序耗尽内存或者失败。
5、一个App里面所有的任务都放在线程池中执行后，可以统一管理 ，当应用退出时，可以把程序中所有的线程统一关闭，避免了内存和CPU的消耗。
6、如果这个任务是一个循环调度任务，你则必须在这个界面onDetach方法把这个任务给cancel掉，如果是一个普通任务则可cancel，可不cancel，但是最好cancel
7、整个APP的总开关会在应用退出的时间把整个线程池全部关闭。
八、一些性能优化建议：
1）避免创建过多对象，造成频繁的gc
2)不要过多使用枚举，枚举占用的空间比整型大很多
3）字符串的拼接使用StringBuffer、StringBuilder来替代直接使用String,因为使用String会创建多个String对象，参考第一条。
4）适当使用软引用，（弱引用就不太推荐了）
5）使用内存缓存和磁盘缓存。
随着智能手机的不断发展以及用户需求的不断增加，手机的运行内存(RAM)的大小已经从MB过渡到了GB容量，作为用户的我们只是知道运行内存越大越好，而运行内存到底有什么用你知道么?接下来是我为大家收集的提升Android手机运行内存教程，希望能帮到大家。
提升Android手机运行内存教程
知识小科普
无应用运行时内存占用已近半
这个时候就又到了笔者给大家科普的时候了。RAM全称Random Access Memory，我们都习惯称之为运行内存，又称随机存储器。其是与CPU直接交换数据的内部存储器，也叫主存(内存)。它可以随时读写，并且速度很快，通常作为系统或正在运行程序的临时数据存储媒介。
为啥安卓手机更吃内存
看到这你可能深深的认为RAM还是越大越好，对没错笔者也是这么认为的。纵观安卓手机的发展，RAM已经从最初的128MB发展到了现在的6GB(消息称8GB已经在路上)，而苹果从最初的128MB至今RAM也不过才发展到2GB而已，但仍然可以流畅运行，这又是为何呢?
iOS VS Android(图片引自antutu)
这就完全要归结于安卓和苹果不同的内存运行机制。安卓系统在运行一个程序时：CPU开始计算-内存开始缓存-再读取目标文件开始计算，当结束程序时CPU计算完毕但内存仍然有部分缓存占用。而苹果就不同当CPU开始运算后就会收集所有内存为应用运行进行缓存，在结束应用时会释放全部内存。
用户的内存不足解决之道
对于一般用户来说就是安装各类清理软件，卸载多余不常用APP，软件关闭后及时清理后台。目前许多手机中还加入了后台应用管理的功能并提供一键清理选项，实在受不了的时候就对手机进行一次出厂化设置。
手机中自带的权限管理应用
对于安卓有一定了解的用户，则会选择精简版的ROM来进行刷机(一般情况下系统的精简度是和流畅性成正比的)，并通过ROOT获取权限，从根本控制软件的自启及对内存的占用。
各类刷机软件中都提供精简版ROM一键刷机和一键ROOT(图片引自romjd)
而那些动手能力极强的用户还会选择一些特别的方法，比如通过创建Swap(交换分区)来解决，当用户的实体内存不足时便会调用这部分虚拟内存来运行应用。
Linux中的Swap即交换分区，类似于Windows的虚拟内存，就是当内存不足的时候，把一部分硬盘空间虚拟成内存使用,从而解决内存容量不足的情况。而Android正是基于Linux研发的操作系统，所以也可以使用Swap分区来提升系统运行效率。
对于安卓手机如何创建Swap的具体过程笔者就不做过多介绍，不过首先你的手机内核需要支持Swap，并且已ROOT，可以利用内置存储或内存卡(需注意卡片读写速度)进行制作，详细方法及所需软件请执行百度。
看了“提升Android手机运行内存教程”还想看：
1. 安卓手机运行内存不够用的解决方法
2. 怎样能刷运行内存
3. 安卓手机运行内存太小怎么优化
4. 怎样扩大手机内部内存
5. 怎样扩展手机最大内存
内容整理自网络。
在做内存优化的时候，我们发现除了解决内存泄露问题，剩下的就只有想办法减少真实的内存占用。而在App中，大部分内存可能被我们图片占用了，所以减少图片的内存占用可以带来直接的效果。本文就简单介绍一张图片到底占用多少内存，我们先假设我们有一张图片时** 600 * 800** 的，图片占用空间大小假设是** 100KB**。
图片内存大小跟占用空间大小有什么关系？
占用空间的大小不是图片占用内存的大小，一些初学者可能会误解一下。占用空间是在磁盘上占用的空间，内存大小是加载到内存中占用的内存大小。两个只是单位是一样的，本质不是一个概念。
一张图片到底占用多少内存呢？（ARGB_8888编码）
1. 图片占用内存的计算公式： 图片高度 * 图片宽度 * 一个像素占用的内存大小
2. 所以上面的图片占用内存是：**800 * 600 * 4 byte = 1875KB = 1.83M **
上面的计算公式中，为什么是4byte呢？文章后面有总结哦
图片所在目录对内存的影响？
在Android中，图片的存放目录和手机的屏幕密度影响图片最终的大小，举个例子：
假设我们的图片放到 xhdpi 目录下，那么我们本文中的图片占用的内存大小如下：
屏幕密度为2的设备：800 * 600 * 4byte = 1.83M
屏幕密度为3的设备：800 * 1.5 * 600 * 1.5 * 4byte = 1.83 * 2.25M =** 4.12M**
所以，计算图片占用内存大小的时候，要考虑图片所在的目录跟设备密度，这两个因素其实影响的是图片的高宽，android会对图片进行拉升跟压缩。
总结
1. 图片确实很占用内存，内存优化先考虑图片内存占用；
2. 一定要避免使用大图片，这就是.9图很有用的原因之一；
3. 图片的大小对内存的影响是正比关系；
4. 本文只是简单的告知读者怎么计算图片的内存大小。
大图： 440 * 336 小图： 220 * 168 资源目录： xhdpi
小图的高宽都是大图的1/2--小图是原图的1/4
界面效果：
测试设备： Coolpad 8676-M01 5.1 density=2.0
测试前准备操作： 同一款设备，设置图片前后多次调用gc直到内存短时间内保持稳定不再变化
内存使用情况： 下图依次是 初始内存，大图内存，小图内存
大图占用内存： 11.23 MB - 10.66 MB = 0.57 MB
小图占用内存： 10.81 MB - 10.66 MB = 0.15 MB
大图小图内存关系： 0.15 MB * 4 = 0.60 MB 约等于 0.57 MB (这是统计工具的误差，理论上就是相等的)
同样的方式在另外一台设备小米4c上得到的结果如下：
测试设备： Xiaomi Mi-4c V8.2.1.0.LXKCNDL 5.1.1 density=3.0
大图占用内存： 13.22 MB - 11.95 MB = 1.27 MB
小图占用内存： 12.27 MB - 11.95 MB = 0.32 MB
大图小图内存关系： 0.32 MB * 4 = 1.28 MB 约等于 1.27 MB
结论： 由此可见大图比小图占用更多的内存，图片大小（分辨率）与占用内存成正比关系
备注： 图片在硬盘上占用的磁盘空间大小，与在内存中占用的内存大小完全不一样，不是一个概念，不要混淆
根据上文中图片大小与内存的关系，可以更加深刻的理解Android中.9图片的作用，它不但能减少apk的体积，还能减少图片占用内存。
有些时候我们根本不需要图片，而是自己绘制背景，可以在自定义View的onDraw中绘制背景，当然最方便的还是使用系统的Drawable，绘制部分交给系统去完成。
下面测试图片与Drawable的内存占用对比
原始图片大小： 482 * 482
界面效果：
测试设备： Xiaomi Mi-4c V8.2.1.0.LXKCNDL 5.1.1
测试前准备操作： 同一款设备，设置背景前后多次调用gc直到内存短时间内保持稳定不再变化
内存使用情况： 下图依次是 初始内存，使用图片占用的内存，使用Drawable占用的内存，使用onDraw绘制占用的内存
使用图片占用内存： 13.97 MB - 11.97 MB = 2.00 MB
使用Drawable占用内存： 11.97 MB - 11.97 MB = 0.00 MB （不会是0，有误差，只是很少）
使用onDraw绘制占用内存： 11.98 MB - 11.97 MB = 0.01 MB
结论： 绘制背景，或者使用系统提供Drawable作为背景，会大大减少内存占用
Drawable参考资料：
Drawable实战解析：Android XML shape 标签使用详解（apk瘦身，减少内存好帮手）
Android GradientDrawable（shape标签定义）静态使用和动态使用(圆角，渐变实现)
“让你的图片最小化”一节中描述的方法：使用尽可能小的图，使用.9，自己绘制背景或者使用Drawable来绘制背景
加载大图片时需要对图片进行压缩，使用等比例压缩方法直接在内存中处理图片
这样做要注意的是，图片质量会变差，inSampleSize设置的值越大，图片质量就越差。
有时候我们取得一张图片，也许只是为了获得这个图片的一些信息，比如图片的width、height等信息，不需要显示到界面上，这个时候我们可以不把图片加载到内存中。
由于Android外层是使用java，而底层使用的是C语言为图片对象分配的内存空间。所以我们的外部虽然看起来释放了，但里层却并不一定完全释放了，我们使用完图片后最好再释放掉里层的内存空间。
RGB(ARGB)
RGB色彩模式是工业界的一种颜色标准，是通过对红(R)、绿(G)、蓝(B)三个颜色通道的变化以及它们相互之间的叠加来得到各式各样的颜色的，RGB即是代表红、绿、蓝三个通道的颜色，这个标准几乎包括了人类视力所能感知的所有颜色，是目前运用最广的颜色系统之一。在Android中还有包含透明度Alpha的颜色模型，即ARGB。
YUV
YUV，分为三个分量，“Y”表示明亮度（Luminance或Luma），也就是灰度值；而“U”和“V” 表示的则是色度（Chrominance或Chroma），作用是描述影像色彩及饱和度，用于指定像素的颜色。
YUV的原理是把亮度与色度分离，研究证明，人眼对亮度的敏感超过色度。利用这个原理，可以把色度信息减少一点，人眼也无法查觉这一点。
主要用于电视系统以及模拟视频领域，它将亮度信息（Y）与色彩信息（UV）分离，没有UV信息一样可以显示完整的图像，只不过是黑白的，这样的设计很好地解决了彩色电视机与黑白电视的兼容问题
YUV的存储中与RGB格式最大不同在于，RGB格式每个点的数据是连继保存在一起的。即R，G，B是前后不间隔的保存在2-4byte空间中。而YUV的数据中为了节约空间，U，V分量空间会减小。每一个点的Y分量独立保存，但连续几个点的U，V分量是保存在一起的，（反正人眼一般也看不出区别）.这几个点合起来称为macro-pixel， 这种存储格式称为Packed格式。另外一种存储格式是把一幅图像中Y，U，V分别用三个独立的数组表示。这种模式称为planar模式。
CMYK
CMYK也称作印刷色彩模式，顾名思义就是用来印刷的。印刷四分色模式是彩色印刷时采用的一种套色模式，利用色料的三原色混色原理，加上黑色油墨，共计四种颜色混合叠加，形成所谓“全彩印刷”。四种标准颜色是：
CMYK和RGB相比有一个很大的不同：RGB模式是一种发光的色彩模式，你在一间黑暗的房间内仍然可以看见屏幕上的内容；CMYK是一种依靠反光的色彩模式，我们是怎样阅读报纸的内容呢？是由阳光或灯光照射到报纸上，再反射到我们的眼中，才看到内容。它需要有外界光源，如果你在黑暗房间内是无法阅读报纸的。只要是在印刷品上看到的图像，就是CMYK模式表现的。比如期刊、杂志、报纸、宣传画等，都是印刷出来的，那么就是CMYK模式的了。
CMYK原色与叠加之后的颜色对比
在不考虑透明度的情况下，一个像素点的颜色值在计算机中的表示方法有以下3种：
在Java中，float类型的变量占32位，int类型的变量占32位，short和char类型的变量都在16位，因此可以看出，用浮点数表示法编码一个像素的颜色，内存占用量是96位即12字节；而用24位整数表示法编码，只要一个int类型变量，占用4个字节（高8位空着，低24位用于表示颜色）；用16位整数表示法编码，只要一个short类型变量，占2个字节；因此可以看出采用整数表示法编码颜色值，可以大大节省内存，当然，颜色质量也会相对低一些。在Android中获取Bitmap的时候一般也采用整型编码。
回想一下Android的BitmapConfig类中，有ARGB_8888、ARGB_4444、RGB565等常量，现在可以知道它们分别代表了什么含义。同时也可以计算一张图片在内存中可能占用的大小，比如采用ARGB_8888编码载入一张1920 1200的图片，大概就会占用1920 1200*4/1024/1024=8.79MB的内存。
采用低内存占用量的编码方式，比如Bitmap.Config.ARGB_4444比Bitmap.Config.ARGB_8888更省内存；
1920 1200的图片:*
ARGB_8888:1920 1200 4/1024/1024=8.79MB
ARGB_4444,RGB565:1920 1200 2/1024/1024=4.39MB
在Android中，对图片的使用一定要关注，大多数情况下，占用内存多，OOM发生都是因为图片资源使用不当。不要盲目加一个大图到Android项目中，能使用.9进来使用，而且.9图本身尽可能小，另外能使用绘制实现就不要加一个图片资源。有些时候，在不影响用户体验的情况下，可以降低图片素材质量，比如不需要透明度的就不要了，有些透明度用肉眼看不出来。
2个基本原则
既然需要的内存公式已得到，那优化就显而易见了，无非就是减小的这三个参数的值，具体的策略如下：
这里我们将图片分为2种情况来探讨：
图片占用的内存 大小为：
为什么mipmap不在这种情况的考虑范围之内呢？
因为mipmap是Android系统为了避免Launcher Icon变形而添加的资源目录，也就是说，mipmap中的图片不会被缩放。所以Google也不推荐将除Launcher Icon之外的图片放在mipmap目录中。
本地图片通常都是通过Android提供的BitmapFactory来加载的, 这里看几个常用的API：
图片的优化可通过Options参数来实现(Options的介绍可参考 从fresco 看图片优化 ：
inPreferredConfig的取值为Bitmap.Config类型(这里只考虑以下几种情况)，它是一个枚举类型，用来设置每个像素需要的字节数：
1.jpeg和gif
2.webp
3.png8, png24, png32
网络图片通常我们都是使用开源库进行加载, 所以不需要拿到Bitmap再进行缩放或裁剪。
这时可让后台实现网络图片的裁剪，即：根据图片的请求参数返回合适的尺寸，最大也只需要控件的大小即可。
再大也没意义，不仅浪费流量，还占用内存。
如果你的APP中有很多图片，那么可对图片的宽高根据设备的内存情况进行适当的缩小：
尽量为所有分辨率创建资源 资源匹配分辨率 = 减少不必要的缩放，从而提高UI绘制效率
对于一个多图片的APP来说，图片所占内存的优化是一项必不可少的工作。
总的来说，其优化也就是通过 缩放 和指定 Bitmap.Config的值 来实现的，只是不同位置，不同格式的图片有所差异而已。
;utm_source=weixinqun
Android内存优化一:java垃圾回收机制
Android内存优化二:内存泄漏
Android内存优化三:内存泄漏检测与监控
Android内存优化四：OOM
Android内存优化五：Bitmap优化
压缩比：scale = (flaot) targetDensity / density
targetDensity : 设备屏幕像素密度dpi
density: 图片对应的文件夹的像素密度dpi
1)、同一张图片放在不同的资源目录下，其分辨率会有变化。
2)、Bitmap的分辨率越高，其解析后的宽高越小，甚至小于原有的图片（及缩放），从而内存也响应的减少。
3)、图片不放置任何资源目录时，其使用默认分辨率mdpi：160。
4)、资源目录分辨率和屏幕分辨率一致时，图片尺寸不会缩放。
Bitmap放在资源目录中的计算方式为：
主要通过编码、采样、复用、匿名共享区进行优化
由于ARGB_4444的画质惨不忍睹，一般假如对图片没有透明度要求的话，可以改成RGB_565，相比ARGB_8888将节省一半的内存开销
其中，A代表透明度；R代表红色；G代表绿色；B代表蓝色。
ALPHA_8 表示8位Alpha位图,即A=8,一个像素点占用1个字节,它没有颜色,只有透明度。
ARGB_4444 表示16位ARGB位图，即A=4,R=4,G=4,B=4,一个像素点占4+4+4+4=16位，2个字节。
ARGB_8888 表示32位ARGB位图，即A=8,R=8,G=8,B=8,一个像素点占8+8+8+8=32位，4个字节。
RGB_565 表示16位RGB位图,即R=5,G=6,B=5,它没有透明度,一个像素点占5+6+5=16位，2个字节。
bitmap的占用内存，是以bitmap的宽高和每个像素占用的字节数决定的。
根据BitmapFactory 的采样率进行压缩 设置采样率，不能小于1 假如是2 则宽为之前的1/2，高为之前的1/2，一共缩小1/4 以此类推
图片复用指的是inBitmap这个属性。
不使用这个属性，你加载三张图片，系统会给你分配三份内存空间，用于分别储存这三张图片
如果用了inBitmap这个属性，加载三张图片，这三张图片会指向同一块内存，而不用开辟三块内存空间。
inBitmap的限制：
1、3.0-4.3
复用的图片大小必须相同
编码必须相同
2、4.4以上
复用的空间大于等于即可
编码不必相同
3、不支持WebP
4、图片复用，这个属性必须设置为true；
options.inMutable = true;
Android 系统为了进程间共享数据开辟的一块内存区域，由于这块区域不受应用的Head的大小限制，相当于可以绕开oom，FaceBook的Fresco首次应用到实际中。
限制：5.0以后就限制了匿名共享内存的使用。
在SDK 11 - 18之间，重用的bitmap大小必须是一致的，例如给inBitmap赋值的图片大小为100-100，那么新申请的bitmap必须也为100-100才能够被重用。从SDK 19开始，新申请的bitmap大小必须小于或者等于已经赋值过的bitmap大小。 新申请的bitmap与旧的bitmap必须有相同的解码格式，例如大家都是8888的，如果前面的bitmap是8888，那么就不能支持4444与565格式的bitmap了。 我们可以创建一个包含多种典型可重用bitmap的对象池，这样后续的bitmap创建都能够找到合适的“模板”去进行重用。
8.0Bitmap的像素数据存储在Native，为什么又改为Native存储呢？
因为8.0共享了整个系统的内存，测试8.0手机如果一直创建Bitmap，如果手机内存有1G，那么你的应用加载1G也不会oom。
可以利用LRU开管理Bitmap，给他设置内存最大值，及时回收。
BitmapRegionDecoder
Android内存优化一:java垃圾回收机制
Android内存优化二:内存泄漏
Android内存优化三:内存泄漏检测与监控
Android内存优化四：OOM
Android内存优化五：Bitmap优化
Memory Profiler 是 Profiler 中的其中一个版块，Profiler 是 Android Studio 为我们提供的性能分析工具，使用 Profiler 能分析应用的 CPU、内存、网络以及电量的使用情况。
进入了 Memory Profiler 界面。
点击 Record 按钮后，Profiler 会为我们记录一段时间内的内存分配情况。
在内存分配面板中，通过拖动时间线来查看一段时间内的内存分配情况
通过搜索类或者报名的方式查看对象的使用情况
使用Memory Profiler 分析内存可以查看官网： 使用内存性能分析器查看应用的内存使用情况
对于内存泄漏问题，Memory Profiler 只能提供一个简单的分析，不能够确认具体发生问题的地方。
而 MAT 就可以帮我们做到这一点，它是一款功能强大的 Java 堆内存分析工具，可以用于查找内存泄漏以及查看内存消耗情况。
as 生成hprof文件无法被mat识别，需要进行转换
使用hprof-conv进行转换，hprof-conv位于sdk\platform-tools
ps：as导出hprof前最好先gc几次，可排除一些干扰
Histogram 可以列出内存中的对象，对象的个数以及大小； Dominator Tree 可以列出那个线程，以及线程下面的那些对象占用的空间； Top consumers 通过图形列出最大的object； Leak Suspects 通过MA自动分析泄漏的原因。
Shallow Heap就是对象本身占用内存的大小，不包含其引用的对象内存，实际分析中作用不大。常规对象（非数组）的ShallowSize由其成员变量的数量和类型决定。数组的shallow size有数组元素的类型（对象类型、基本类型）和数组长度决定。对象成员都是些引用，真正的内存都在堆上，看起来是一堆原生的byte[], char[], int[]，对象本身的内存都很小。
Retained Heap值的计算方式是将Retained Set（当该对象被回收时那些将被GC回收的对象集合）中的所有对象大小叠加。或者说，因为X被释放，导致其它所有被释放对象（包括被递归释放的）所占的heap大小。
Path To GC Roots - exclude all phantim/weak/soft etc. references：查看这个对象的GC Root，不包含虚、弱引用、软引用，剩下的就是强引用。从GC上说，除了强引用外，其他的引用在JVM需要的情况下是都可以 被GC掉的，如果一个对象始终无法被GC，就是因为强引用的存在，从而导致在GC的过程中一直得不到回收，因此就内存泄漏了。
List objects - with incoming references：查看这个对象持有的外部对象引用
List objects - with outcoming references：查看这个对象被哪些外部对象引用
使用对象查询语言可以快速定位发生泄漏的Activity及Fragment
使用 MAT 来分析内存问题，效率比较低，为了能迅速发现内存泄漏，Square 公司基于 MAT 开源了 LeakCanary ，LeakCanary 是一个内存泄漏检测框架。
集成LeakCanary后，可以在桌面看到 LeakCanary 用于分析内存泄漏的应用。
当发生泄漏，会为我们生成一个泄漏信息概览页，可以看到泄漏引用链的详情。
LeakCanary 会解析 hprof 文件，并且找出导致 GC 无法回收实例的引用链，这也就是泄漏踪迹（Leak Trace）。
泄漏踪迹也叫最短强引用路径，这个路径是 GC Roots 到实例的路径。
LeakCanary 存在几个问题，不同用于线上监控功能
线上监控需要做的，就是解决以上几个问题。
各大厂都有开发线上监控方案，比如快手的 KOOM ，美团的 Probe ，字节的 Liko
快手自研OOM解决方案KOOM今日宣布开源
总结一下几点：
通过无性能损耗的 内存阈值监控 来触发镜像采集。将对象是否泄漏的判断延迟到了解析时
利用系统内核COW( Copy-on-write ，写时复制)机制，每次dump内存镜像前先暂停虚拟机，然后fork子进程来执行dump操作，父进程在fork成功后立刻恢复虚拟机运行，整个过程对于父进程来讲总耗时只有几毫秒，对用户完全没有影响。
