缓存池大小
现在很多图片加载组件都不仅仅是使用软引用或者弱引用了，实际上类似Glide 默认使用的事LruCache，因为软引用 弱引用都比较难以控制，使用LruCache可以实现比较精细的控制，而默认缓存池设置太大了会导致浪费内存，设置小了又会导致图片经常被回收，所以需要根据每个App的情况，以及设备的分辨率，内存计算出一个比较合理的初始值，可以参考Glide的做法。
内存抖动
什么是内存抖动呢？Android里内存抖动是指内存频繁地分配和回收，而频繁的gc会导致卡顿，严重时还会导致OOM。
枚举
Android平台上枚举是比较争议的，在较早的Android版本，使用枚举会导致包过大，在个例子里面，使用枚举甚至比直接使用int包的size大了10多倍 在stackoverflow上也有很多的讨论, 大致意思是随着虚拟机的优化，目前枚举变量在Android平台性能问题已经不大，而目前Android官方建议，使用枚举变量还是需要谨慎，因为枚举变量可能比直接用int多使用2倍的内存。
减少view的层级
对于可以 延迟初始化的页面，使用viewstub
1、通过MAT查看内存占用，优化占用内存较大的地方；
关于MAT的使用，网上教程无数，简单推荐两篇MAT使用教程[11]，MAT - Memory Analyzer Tool 使用进阶[12]。
下面这个就是传说中的内存抖动
实际代码如下，因为打Log而进行了字符串拼接，一旦这个函数被比较频繁地调用，那么就很有可能会发生内存抖动。这里我们新版本已经改为使用stringbuilder进行优化。
还有一些比较奇怪的情况，这里是我们扫描歌曲文件头的时候发生的，有些文件头居然有几百M大，导致一次申请了过大的内存，直接OOM,这里暂时也无法修复，直接catch住out of memory error。
4. 同时我们对一些逻辑代码进行调整，比如我们的App主页的第三个tab(Live tab)进行了数据延迟加载,和定时回收。
这里因为这个页面除了有大图还有轮播banner，实际强引用的图片会有多张，如果这个时候切到其他页面进行听歌等行为，这个页面一直在后台缓存，实际是很浪费耗内存的，同时为优化体验，我们又不能直接通过设置主页的viewpager的缓存页数，因为这样经常都会回收，导致影响体验，所以我们在页面不可见后过一段时间，清理掉adapter数据(只是清空adapter里的数据，实际从网络加载回来的数据还在，这里只是为了去掉界面对图片的引用)，当页面再次显示时再用已经加载的数据显示，即减少了很多情况下图片的引用，也不影响体验。
文中引用参考链接
1.Android 操作系统的内存回收机制
https://www.ibm.com/developerworks/cn/opensource/os-cn-android-mmry-rcycl/
2.阿里巴巴的Android内存优化分享
http://www.infoq.com/cn/presentations/android-memory-optimization
3.Android进程的内存管理分析
http://blog.csdn.net/gemmem/article/details/8920039
4.android dalvik heap 浅析
http://blog.csdn.net/cqupt_chen/article/details/11068129
5.揭秘 ART 细节 —— Garbage collection
http://www.cnblogs.com/jinkeep/p/3818180.html
6.Android性能优化之常见的内存泄漏
http://blog.csdn.net/u010687392/article/details/49909477
7.Android App 内存泄露之Handler
http://blog.csdn.net/zhuanglonghai/article/details/38233069
8.GlideBitmapPool
https://github.com/amitshekhariitbhu/GlideBitmapPool
9.Android 性能优化之String篇
http://blog.csdn.net/vfush/article/details/53038437
10.HashMap，ArrayMap，SparseArray源码分析及性能对比
http://www.jianshu.com/p/7b9a1b386265
11.MAT使用教程
http://blog.csdn.net/itomge/article/details/48719527
12.MAT - Memory Analyzer Tool 使用进阶
