一、解决所有的内存泄漏
内存泄漏概念：
不再使用的对象没有被回收，就是内存泄露。
1. 单利泄漏
主要原因还是因为一般情况下单例都是全局的，有时候会引用一些实际生命周期比较短的变量，导致其无法释放。
例如 ：
activity 的 content 赋值到单利对象里面的成员量变量
code:
privatestaticvolatileClassXX instance;
privateContext context;
privateClassXX(Context context){
this.context = context;
}
publicstaticClassXXgetInstance(Context context){
if(instance ==null) {
synchronized(instance) {
if(instance ==null) {
instance =newClassXX(context);
}
}
}
returninstance;
}
如果这个Context
是Activity的Context，当你的Activity finish();之后Activity这个对象的内存还是在堆中，没有释放。
因为单利对象持有Activity的引用，jvm认为你这个对象还是在使用中，不敢去 回收掉你的Activity。那单例什么时候被回收?
那就只有等到整个进程被回收了，单例才会被回收。
进程杀死（回收）：
Process.killProcess(Process.myPid())
用户手动卡片式摧毁 （亲测可行）
解决方法：
传入和单例一样生命周期的对象，如context.getApplication();
不将context保存在单例的成员变量里面。
2. Handler AsyncTask 等内部类的内存泄漏
主要原因是内部类默认持有外部类的引用
大家应该很喜欢吧Handler写成一个内部类譬如：
privateHandler mMainActivityHandler =newHandler(){
@Override
publicvoidhandleMessage(Message msg){
super.handleMessage(msg);
}
};
其实包括我也很喜欢，而且一个Activity对应一个Handler，每一个Handler负责更新本Activity的 UI，一对一关系，分工明确。好用到爆炸。
然而 java 内部类是默认持有一个外部类的引用，因为 jvm 在把.java 源文件编译成 .class 字节码的时候，会在默认的构造函数加入外部类的引用。所以我们在内部类中也能访问外部类的引用。
然后问题就发生了，当前Handler持有当前Activity的引用，Handler不释放，Activity也别想释放了。MMP
（为什么Handler有时候会不会被释放?）
解决方法：
构造函数传入Activity并用WeakReferencemActivity;弱引用保存下来。GC的时候会不计入Handler对Activity的引用，可以被回收。
Activity OnDestroy的时候 ，把所有的相关请求终止，并且把消息队列清空removeCallbacksAndMessages(null);防止有数据回调到 UI 层。（当然如果不这么做，Activity照样被回收，但是Handler不及时回收而已）
（什么叫 强引用 软引用 弱引用 虚引用 ，以及 Handler 的消息驱动模型是怎么样子的，这里就不展开讲，本文着重内存泄漏）
当然AsyncTask和其它对象内部类也是有这种问题，解决方法同上。
3. 资源使用完未关闭
主要是：
广播（BraodcastReceiver）动态注册之后要反注册，推荐在onStart onStop对应的生命周期执行。
服务（Service）Start之后 记得Stop。启动服务时机看需求。一般不建议在Application启动（启动Service耗时基本要100ms+）。
io Cursor流要记得close，一定要在finally去close，防止抛异常没执行close，那就泄漏了。
Bitmap内存大户，要记得回收recycle一下，当然 90% 的场景Glide已经帮我们处理的。
4.检测内存泄漏的工具
当然有时候不能完全在写代码的时候规避掉所有的内存泄漏，就要用一些工具检测一下：
LeakCanary
Android Studio profile
MAT
选自己喜欢的工具，去研究一下。（网上很多教程）
二、图片压缩
1. bitmap 压缩
大家都知道bitmap占用内存很大，用完之后要recycle一下。
不知道大家有没有用过，图片加载出来内存就爆掉了（OOM）情况，本宝宝就遇到过了（心中一千万头草拟吗奔腾而过）。
首先一张图片从网络获下来，从InputStream转成Bitmap，这个bitmap占了多少内存怎么计算？
献上代码：
Bitmap.getAllocationByteCount();
其实就是 ByteCount = 长* 宽 * 4（假设这里每一个像素点是是RGB888） 那就是 4 个字节。也有一个像素点 RGB565 占 3 个字节,当然占更多字节的 RGB888 更加高清无码。起初版本Glide使用 RGB565，目前Glide4.XX 的默认都是 RGB888，当然自己可以配置一下。
为了解决这个问题一般都是通过下面代码：
BitmapFactory.Options options =newBitmapFactory.Options();
options.inJustDecodeBounds =true;
// 通过这个bitmap获取图片的宽和高
Bitmap bitmap = BitmapFactory.decodeFile("/sdcard/MTXX/3.jpg", options);
floatrealWidth = options.outWidth;
floatrealHeight = options.outHeight;
//计算出scale
options.inSampleSize = scale;
options.inJustDecodeBounds =false;
// 注意这次要把options.inJustDecodeBounds 设为 false,这次图片是要读取出来的。
bitmap = BitmapFactory.decodeFile("/sdcard/MTXX/3.jpg", options);
先获取他的图片大小，根据自己需要的大小计算出缩放比例。（图片大小都是放在图片的头部，这时候不会去加载整张图片）
进行缩放，得出符合自己的控件尺寸的大小。
（当然还有些非法的图片头部是获取不出 长* 宽。这时候记得搞个默认的缩放率，防止 OOM）
有时候为了优化内存，还不如压缩一张图片 所节约的内存来的更快。
譬如 一张 1080 * 1920 图片再乘以 4 等于 7.9 M。
我压缩到 一张缩略图 200*200 等于 156KB。瞬间节约了7M 空间。区别真的太大了，顿时内心 一句 MMP 。
三、解决内存抖动
1.String VS StringBuffer VS StringBuilder
大家应该对着三个类都非常熟悉。那就先看代码：
longtime= System.currentTimeMillis();
Strings= new String("JAVA");
for(inti =0;i<10000; i++) {
s=s+"VERSION";
}
Log.d("TestString","Time consumption:"+(System.currentTimeMillis() -time));
time= System.currentTimeMillis();
StringBuilder s1 = new StringBuilder("JAVA");
for(inti =0;i<10000; i++) {
s1.append("VERSION");
}
Log.d("TestString","Time consumption:"+(System.currentTimeMillis() -time));
D/TestString: Time consumption:3786
D/TestString: Time consumption:2
很明显使用StringBuilder去拼接字符，效率大大快于用加号，我们带着问题来找原因。
那我们看一下用 + 号去拼接的字节码：
使用+号去拼接字符，jvm 会创建一个临时的StringBuilder
25 new #24
然后把上次的结果集，通过构造函数传入，
29invokespecial#25> //调用构造函数，这串符号引用类似 jni 中反调 java的类查找写法
32aload_3//将局变量表Slot 3的元素入栈
再拼接本次需要拼接的字符。然后存到局部变量表中，等待下次循环操作。
44 astore_3
然后跳转编号17 去继续循环。这时候又重新创建了一个StringBulider去拼接。真是啃爹啊。。。
48 goto 17 (-31)
那我们看一下用 StringBuilder 去拼接的字节码：
这个很明显new StringBulider字节码在循环体外面，所以并没有循环新建对象。
总结：
通过上面的例子，String的拼接通过一个for循环创建了 10000 个StringBulider，而且用完就抛弃。特别浪费，在内存吃紧的情况下，很容易引起gc，导致App卡顿。
也许有同学要问 一个StringBuilder的空对象才占堆内存多大？我们来算一算
一个对象 = 对象头 + 成员属性
对象头 =MardWord+Klass= 12个字节 （数组除外）
上图：
MardWord 字段大全（出自网上扣得）：
这个MardWord怎么有这么多锁状态，这些锁状态又是什么？
这就要涉及到synchronized同步锁的知识，这个不在本文讨论范围之内。
那么StringBulider的成员属性有哪些？清单：
staticfinallongserialVersionUID =4383685877147921099L;
char[]value;
intcount;
对象结构图
计算下来：12+8+8+4+24 = 56 个字节 10000 个对象 那就是要 560KB 内存。不小吧。当然我们实际需求不可能一次搞这么多个对象，但是多个地方都用String
去玩的话，积少成多，到时候APP内存比别人的高出一大截。那就尴尬了..
四、尽量使用 “池”
我们常见的池有
线程池
Lrucache缓存池
okhttp里面的ConnectionPool（socket复用池）
okio SegmentPool（buffer复用池）
池的功能：
可以重复利用对象，并且减少内存开销，内存抖动，cpu 开销。
线程池
publicThreadPoolExecutor(intcorePoolSize,
intmaximumPoolSize,
longkeepAliveTime,
TimeUnit unit,
BlockingQueue workQueue,
ThreadFactory threadFactory,
RejectedExecutionHandler handler)
尽量使用线程池去跑任务，而不是动不动就先new Thread去跑，这样子线程是得不到复用的。当任务量一大，使用线程池的效率会超乎你想象（具体自己看源码），毕竟 开启一个线程cpu内存都是有开销的。
这里推荐Rxjava的第三方库，一个将 装饰者模式 玩到上天的 框架，切换线程方便，支持函数式编程 杜绝回调地狱 等等：
Observable.create(newAction1>() {
@Override
publicvoidcall(Emitter subscriber){}
}, Emitter.BackpressureMode.BUFFER)
.subscribeOn(Schedulers.io())//切换到 io 线程池
.subscribeOn(Schedulers.computation())//切换 到计算 线程池
.subscribeOn(Schedulers.immediate())// 使用当前线程
.observeOn(AndroidSchedulers.mainThread())//切换到 android UI 主线程
.subscribe();
2. Lrucache 缓存池
Lrucache 缓存池：最近最少使用缓存池，底层原理是用 LinkHashMap 实现。
谷歌的Glide图片加载库，就是使用了Lrucache，和LruDiskCache对图片进行缓存，进而提高用户体验。
3. ConnectionPool 缓存池
ConnectionPool 缓存池 ：复用tcp socket套接字，进行网络通讯，每一次HTTP请求结束后，并不结束链接，可复用于下次的请求。把网络传输速度极致化。
一次http请求分：
tcp三次握手
数据传输
tcp四次分手
如果每一次请求都经历整个流程，可能别人所有数据都加载完毕了，我还在握手中… 这就不能忍。
（当然http 1.1+才支持这个链接复用，具体详细源码 看OKhttp，本文不做详细展开）
4. okio SegmentPool （buffer 复用池）
SegmentPool：同上。
总结：
对于一些需要 大量频繁生成和回收的对象，建议使用池，如果没有轮子，也是可以手动写一个。
五、其他
常用数据结构优化
xml 层级 和 view
1.常用数据结构优化
内存大用户 ：HashMap（及其子类）
HashMap是一个典型的 空间换时间，时间复杂度趋近 o(1)
占用空间 是大于size / 0.75（负载因子），
/**
* hashMap put 部分源码，
* size 当前已存入数据数目
* threshold = 容量 *0.75
*/
if (++size > threshold)
resize();
通俗点就是 存入100个数据，要占用 133 个数据内存（及以上），所在数据量较小，或者对速度没有那么要求的时候可用 SparseArray（二叉树实现） 代替。
2.xml 层级 和 view
xml 层级最好控制在 5 层以内。
view 的使用多用：
ViewStub
Include
merge