内存优化的三座大山：内存泄露，内存溢出，内存抖动
（请先了解java虚拟机的垃圾回收机制，强引用，软引用，弱引用，虚引用，这几个概念，这对下面的内容理解相当重要。）
内存泄露
产生的原因：内存对象不需要被使用了，但是一直占用，得不到回收
将会导致的问题：
a.内存处于高占用状态，但是得不到有效的利用
b.超过系统的限制，应用进程被杀死
如何避免：
首先要了解是由下面的这些骚操作导致的，避免掉这样做
（1）非静态内部类创建静态实例引起的内存泄漏
该实例的生命周期和应用ClassLoader级别，又由于该静态实例又会隐式持有其外部类的引用，所以导致其外部类无法正常释放，出现了泄漏问题，例如：
public class TestLeakActivityextends AppCompatActivity {
public static InnerClazzinnerClazz;
@Override
protected void onCreate(@Nullable Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
innerClazz=new InnerClazz();
}
public class InnerClazz{
public void doSomething(){
}
}
}
（2）非静态内部类中存在异步线程时，往往会造成内存泄露
非静态内部类对其外部类存在一个隐式引用，非静态内部类中线程生命周期不可控，是否能正常回收全然由线程的生命周期决定，因此在非静态内部类中存在异步线程时，往往会造成内存泄露。handler就算是典型的非静态内部类。
（3）资源后使用没有及时关闭
例如资源性对象比如Cursor、File、Bitmap、音频、视频等，系统都用了一些缓冲技术等
（4）静态的实例与引用context的生命周期不一致
例如单例模式，静态实例的生命周期是伴随整个应用的，静态的实例引用的Context非常关键，如果此时引用的是Activity，由于Context会被创建的实例一直持有，当Activity进入后台或者开启设置里面的不保留活动时，Activity会被销毁，但是静态的实例持有它的Context引用，Activity又没法销毁，导致了内存泄漏
（5）一些注册的方式没有及时取消注册
例如广播接收，eventbus的使用等
（6）集合对象没有及时清理可能引起的内存泄漏
我们通常会把一些对象装入到集合中，当不使用的时候一定要记得及时清理集合，让相关对象不再被引用。如果集合是static、不断的往里面添加东西、又忘记去清理，肯定会引起内存泄漏。
还有一些防不胜防的内存泄露问题，可以用leak canary来排查，用android studio自带的内存分析工具类分析内存使用情况
总结：
Handler持有的引用最好使用弱引用，在Activity被释放的时候要记得清空Message，取消Handler对象的Runnable；
非静态内部类、非静态匿名内部类会自动持有外部类的引用，为避免内存泄露，可以考虑把内部类声明为静态的，或者新建一个类，不要使用内部类；
对于生命周期比Activity长的对象，要避免直接引用Activity的context，可以考虑使用ApplicationContext；
广播接收器、EventBus等的使用过程中，注册/反注册应该成对使用；
不再使用的资源对象Cursor、File、Bitmap等要记住正确关闭（这些资源都有自己实现的缓存机制，不清理掉，则会一直残留造成内存泄露）；
集合里面的东西，不再使用的时候应当清空掉，将强引用置为空。（如果当集合为static或者加入的对象为static的时候，不清理掉就会产生内存泄露）；
内存溢出
android应用程序被限制了内存使用上限，一般为16M或24M（具体看系统设置，但是各个厂家的OS会对这个值进行修改，现在基本都是256M），当应用的使用内存超过这个上限时，就会被系统认为内存溢出，被kill掉
内存抖动
产生的原因：
创建了大量生命周期过短的内存对象，触发了gc，但是这些被gc的对象还是需要被使用的，因此被gc后，需要再次创建，如此反复，造成了内存占用一下很高，一下又很低，看起来就像是在抖动一样。
将会导致的问题：
a.损耗性能，gc是需要消耗性能，可以了解下垃圾回收机制，频繁的gc就导致较大的性能损耗
b.阻塞主线程，造成卡顿，甚至是无响应，导致应用进程被杀死
如何避免：
a.适当拉长对象的生命存活时间
b.避免创建大量的内存对象，尽量复用对象
优秀的应用，内存的占用应该是平缓的、稳定的。因此需要在创建对象的时候，评估它需要的生命周期和作用范围，在合适的地方创建，真的不需要使用的时候才进行回收，但是也不适宜过长，例如appliction里的实例与static修饰的静态变量是伴随应用的整个生命周期的，虽然不抖动了，但是一直在占用，没使用也在占用，导致内存占用一直偏高就得不偿失了。
如何查看应用的运行时占用情况呢？
可以通过Runtime.getRuntime()的相关方法来获取内存的使用情况，如下：
ActivityManager activityManager = (ActivityManager) getSystemService(ACTIVITY_SERVICE);
int memory = activityManager.getMemoryClass();
System.out.println("memory: "+memory);
float maxMemory = (float) (Runtime.getRuntime().maxMemory() * 1.0/ (1024* 1024));
float totalMemory = (float) (Runtime.getRuntime().totalMemory() * 1.0/ (1024* 1024));
float freeMemory = (float) (Runtime.getRuntime().freeMemory() * 1.0/ (1024* 1024));
System.out.println("maxMemory: "+maxMemory);
System.out.println("totalMemory: "+totalMemory);
System.out.println("freeMemory: "+freeMemory);
1.maxMemory()
这个方法返回的是java虚拟机（这个进程）能构从操作系统那里挖到的最大的内存，以字节为单位，如果在运行java程序的时 候，没有添加-Xmx参数，那么就是64兆，也就是说maxMemory()返回的大约是6410241024字节，这是java虚拟机默认情况下能 从操作系统那里挖到的最大的内存。
2.totalMemory()
这个方法返回的是java虚拟机现在已经从操作系统那里挖过来的内存大小，也就是java虚拟机这个进程当时所占用的所有 内存。在java程序运行的过程的，内存总是慢慢的从操作系统那里挖的，基本上是用多少挖多少，直挖到maxMemory()为止，所以totalMemory()是慢慢增大的。
3.freeMemory()
在java程序运行的过程的，内存总是慢慢的从操 作系统那里挖的，基本上是用多少挖多少，但是java虚拟机是会稍微多挖一点的，这些挖过来而又没有用上的内存，实际上就是 freeMemory()，所以freeMemory()的值一般情况下都是很小的 。
已用内存，必须计算：usedMemory = Runtime.getRuntime().totalMemory() - Runtime.getRuntime().freeMemory();
总可用内存，必须计算：freeMemory = Runtime.getRuntime().maxMemory() - usedMemory;
如何申请更大的内存？
1、设定属性android:largeheap = "true"（原本默认是256M的，会给到512M）
2、开一个新进程，在AndroidManifest给某个组件设置android:process标签