来，
今天来说说Android中的内存分析相关问题。
内存介绍
现在Android手机运行内存是越来越大了，基本上都是6g，8g。那么内存都这么大了，我们还需要考虑内存泄漏，OOM等问题吗。
肯定需要啊，不然我就不用写这篇文章了😖。因为虽然Andorid内存越来越大，但是提供给应用的java堆内存却不多，一般好点的手机可能也就512M左右。所以我们还是需要多多考虑应用的内存问题，尽量优化，避免内存泄漏和OOM等问题。
内存泄漏（Memory Leak） 是指程序中己动态分配的堆内存由于某种原因程序未释放或无法释放，造成系统内存的浪费，导致程序运行速度减慢甚至系统崩溃等严重后果。
OOM，“Out Of Memory”，即内存溢出
简单点说，手机给我们的应用提供了一定大小的堆内存，在不断创建对象的过程中，也在不断的GC(java的垃圾回收机制)，所以内存正常情况下会保持一个平稳的值。
但是出现内存泄漏就会导致某个实例，比如Activity的实例，应用被某个地方引用到了，不能正常释放，从而导致内存占用越来越大，这就是内存泄漏。
那OOM呢，就是内存爆炸了。
打个不是很恰当的比喻，如果把内存比做食物，我们每天都要摄入适量的食物（创建实例），也要正常消化（GC）。如果有一天我们吃了不容易消化的食物（不能正常回收的对象），就会肚子发胀不舒服（内存泄漏），如果还不节制，暴饮暴食，就有可能把胃撑坏，导致生病（OOM）。哈哈，此举例只是方便理解。
举个🌰子
简单直接，我们举个例子，看看这内存泄漏到底是怎么回事，怎么去分析内存问题。
现在有如下一个程序：
public class MainActivity extends AppCompatActivity {
@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_main);
}
public void clickBtn(View view) {
startActivity(new Intent(this, SecondActivity.class));
}
}
public class SecondActivity extends AppCompatActivity {
@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_main);
MemoryManager memoryManager = MemoryManager.getInstance(this);
}
}
MemoryManager
public class MemoryManager {
private static MemoryManager mManager;
private Context mContext;
private MemoryManager(Context mContext) {
this.mContext=mContext;
}
public static MemoryManager getInstance(Context context) {
if (mManager == null) {
synchronized (MemoryManager.class) {
mManager = new MemoryManager(context);
}
}
return mManager;
}
}
可以看到，由于静态变量mContext一直引用SecondActivity的实例，所以就会造成SecondActivity无法正常释放，从而内存泄漏。
现在就来分析查找这个问题
Memory Profiler
AndroidStudio 自带了一个工具Profiler，可以针对App进行Cpu，内存，电池电量等数据分析。其中就有Memory Profiler。
1、启动应用，点击AndroidStudio下方的Profiler，显示如下
2、点击Memery
可以看到，App的内存实时情况就显示出来了，我们怎么去读懂它呢，这里借助官网的说明:
3、然后我们尝试点击几次App中的按钮，跳转到SecondActivity，然后返回，会发现Memory的曲线会不断增长，通过点击2号按钮（捕获堆转储）可以生产一个快照（Heap Dump），其实就是一个hprof文件。
HPROF 最初是由J2SE支持的一种二进制堆转储格式，展示了某一时刻Java堆的使用情况
这里我们就生成了一个堆转储文件并打开它：
我们点击ClassName里面的SecondActivity，发现存在了5个实例，点击一个实例，就显示引用来自MemoryManager，所以就可以发现内存泄漏来自这里了。
当然，也有一些工具可以快速准确的找到我们应用中的内存泄漏，比如leakcanary。
LeakCanary
LeakCanary is a memory leak detection library for Android，是square 公司开源的内存泄漏检测工具
使用很简单，首先导入库
Add LeakCanary to build.gradle:
dependencies {
// debugImplementation because LeakCanary should only run in debug builds.
debugImplementation 'com.squareup.leakcanary:leakcanary-android:2.0-beta-3'
}
That’s it, there is no code change needed!
然后就可以运行应用，会发现同本应用一起安装了一个Leaks的应用，logo是个小鸟。
正常运行我们的应用，操作几次后，打开这个Leaks发现显示有一个leaks
可以发现LeakCanary详细描述了内存泄漏的路径，可以很方便的找到泄漏点。
这里我们简单说下LeakCanary的原理，他是怎么检测并分析内存泄漏的呢？
监听
首先通过ActivityLifecycleCallbacks和FragmentLifeCycleCallbacks监听Activity和Fragment的生命周期。判断
然后在销毁的生命周期中判断对象是否被回收。弱引用在定义的时候可以指定引用对象和一个 ReferenceQueue，通过该弱引用是否被加入ReferenceQueue就可以判断该对象是否被回收。分析
最后通过haha库来分析hprof 文件，从而找出类之前的引用关系。
以上就是两种检测内存泄漏的方法了。在平时项目中，合理运用两种方法，能够更准确的找到项目中的问题。
谢谢大家支持！
——积木
