Android优化一：提纲
Android优化二：性能检测
Android优化三：内存优化
Android优化四：App启动速度优化
Android优化五：布局优化
Android优化六：性能优化
什么是内存泄漏？
根据 Java 内存回收机制的“可达性分析法”，如果这些对象是可达的，但是这些对象是无用的，就会导致内存泄漏，内存泄漏的积累最终导致内存溢出。
分类
Android中内存溢出主要分为四类：
①集合类泄漏
②单例/静态变量造成的内存泄漏
③匿名内部类/非静态内部类
④资源未关闭造成的内存泄漏
Q：单例为什么会导致内存泄漏？
其实单例本身跟内存泄漏是没什么关系的，只有在单例使用不恰单才会导致内存泄漏。
单例导致内存泄漏主要的原因是：单例的静态特性使得单例的生命周期跟整个应用的生命周期一样长。
如果我们在单例中传入的 Context 是 Activity 的 context，当这个 Context 所对应的 Activity 退出时，由于该 Context 的引用被单例对象所持有，其生命周期等于整个应用程序的生命周期，所以当前 Activity 退出时它的内存并不会被回收，这就造成泄漏了。
同理被static修饰的成员变量也是如此，其生命周期将与整个app进程生命周期一样。
Q：handler 和非静态内部类为什么会导致内存泄漏？
非静态内部类默认会持有外部类的引用，handler 的生命周期与 Activity 的生命周期不一致，
如果 Activity 销毁了但是 Handler 里面有未处理完的延时消息，导致 Activity 不能被 GC 回收。
OOM异常
- 可以通过getMemoryClass( )来获取App的可用堆内存，如果申请的内存超过这个值，就会造成OOM异常。
- 可以在AndroidManifest.xml文件<applicatiion>中可以设置
android:largeHeap="true"活的更大的堆内存。
具体细节
1、Bitmap图片过大
解决办法：
BitmapFactory.Options options = new BitmapFactory.Options();
options.inSampleSize = 2;
图片宽高都为原来的二分之一，即图片为原来的四分之一。
bitmap.get().recycle();
在用完Bitmap时，要及时的recycle掉。recycle并不能确定立即就会将Bitmap释放掉，但是会给虚拟机一个暗示：“该图片可以释放了”。软引用（SoftRefrence）
我们使用Bitmap后没有保留对它的引用，因此就无法调用Recycle函数。这时候巧妙的运用软引用，可以使Bitmap在内存快不足时得到有效的释放 。
但是是现在已经不再推荐使用这种方式了，因为从 Android 2.3 (API Level 9)开始，垃圾回收器会更倾向于回收持有软引用或弱引用的对象，这让软引用和弱引用变得不再可靠。另外，Android 3.0 (API Level 11)中，图片的数据会存储在本地的内存当中，因而无法用一种可预见的方式将其释放，这就有潜在的风险造成应用程序的内存溢出并崩溃。
From 郭霖的博客
- 建议使用成熟的Glide、Picasso、Fresco框架来加载图片。
2、界面切换
- 看页面布局有没有大的图片，比如背景图之类的。
- 直接把XML配置成view再放到一个容器里面，避免重复加载。
- 在页面切换时尽可能少地重复使用一些代码。
3、资源未关闭
-
BraodcastReceiver，ContentObserver，File，Cursor，Stream，Bitmap等资源的使用没有注销导致。 - 在Activity销毁时及时关闭或者注销。
4、ListView没有使用缓存
- 使用的convertView进行缓存
- 建议使用5.0出来的RecycleView替代Listview。
5、Handler导致
- 应该申明为静态对象， 并在其内部类中保存一个对外部类的弱引用。
- 在Activity销毁时及时关闭或者注销
@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_main);
//handler导致内存泄漏;
//当Activity销毁时，匿名内部类一直持有Activity的引用，无法释放。
Handler handler = new Handler();
handler.postDelayed(new Runnable() {
@Override
public void run() {
//执行逻辑
}
}, 10000L);
}
6、 线程导致
- 线程产生内存泄露的主要原因在于线程生命周期的不可控。
- 将线程的内部类，改为静态内部类。
- 采用线程池, 避免程序中存在大量的Thread。
7、尽量使用9path图片
.9图片可以任意调整大小，进行拉伸。
8、使用单例造成
- 当调用getInstance时，如果传入的context是Activity的context。只要这个单例没有被释放，那么这个Activity也不会被释放一直到进程退出才会释放。
- 使用Application的Context。
9、非静态内部类创建静态实例
- 将非静态内部类修改为静态内部类。（静态内部类不会隐式持有外部类）
- Context尽量使用Application Context，因为Application的Context的生命周期比较长。
10、使用了静态的Activity和View
private static View sView;- 应该及时将静态的应用 置为null，而且一般不建议将View及Activity设置为静态。
11、属性动画导致的内存泄漏
- 属性动画有一类无限循环的动画, 如果在Activity中播放此类动画且没有在Activity退出的时候没有停止动画. 尽管无法界面上看到效果, 但是创建这个动画所关联的
View被动画所持有, 而View又持有了Activity, 最终Activity无法释放. - 解决方案是在onDestroy()中调用动画的cancel()来停止动画.
12、帧动画导致
- 帧动画使用的图片过大过多导致
终极大招：LeakCanary
LeakCanary 是一个开源的在debug版本中检测内存泄漏的java库。
LeakCanary 中文使用说明
平时写代码稍微注意点，再用这个检测基本能搞定所有oom异常。
