内存优化
内存泄漏不一定造成程序的crash,但内存溢出肯定会造成程序的crash,所以我们需要解决的是在程序没有crash之前的问题
1. 内存泄漏: 根本原因是长生命周期的对象持有短生命周期的对象,造成短生命周期对象无法及时释放
- 内存泄漏种类:
静态集合类引起内存泄漏
像HashMap、Vector等的使用最容易出现内存泄露，这些静态变量的生命周期和应用程序一致，他们所引用的所有的对象Object也不能被释放，因为他们也将一直被Vector等引用着。
尽量避免使用 static 成员变量当集合里面的对象属性被修改后，再调用remove()方法时不起作用。
经过测试,当set集合的hashcode被修改后,就没有办法remove了监听器没有remove
我们经常会跟监听器打交道，通常一个应用当中会用到很多监听器，我们会调用一个控件的诸如addXXXListener()等方法来增加监听器，但是当我们不需要的时候,却忘记removeXXXListener()，从而增加了内存泄漏的机会,最经常的是unregisterrecevier(反注册广播)各种数据链接没有关闭,比如数据库
比如数据库连接，网络连接(socket),io流连接,ContentProvider(内容提供者)，cursor(游标)除非其显式的调用了其close（）方法在finally里面将其连接关闭，否则是不会自动被GC回收的
在数据连接使用完毕以后一定要进行关闭操作内部类:
java内部类拥有外部类的强引用,比如在new thread中,当线程没有结束时,activity不会被回收
比如context的引用,当内部类的TextView等等都会持有上下文的引用
如果有static drawable就会导致内存无法释放
将内部类改为静态内部类,静态内部类中使用弱引用来引用外部类的成员变量单例模式
单例是一个全局的静态对象,当持有外部类对象的引用时,此对象无法被释放,内存会leak
避免 override finalize() (手动开启GC回收机制)
*finalize 方法被执行的时间不确定，不能依赖与它来释放紧缺的资源。时间不确定的原因是： 虚拟机调用GC的时间不确定
如何避免00M异常
首先OOM是什么？(内存溢出)
当程序需要申请一段“大”内存，但是虚拟机没有办法及时的给到，即使做了GC操作以后
这就会抛出 OutOfMemoryException 也就是OOM
Android的OOM怎么样？
为了减少单个APP对整个系统的影响，android为每个app设置了一个内存上限。
HTC M7实测，192M上限。512M 一般情况下，192M就是上限，但是由于某些特殊情况，android允许使用一个更大的RAM。
如何避免OOM?
最重要的是肯定是你的程序没有语法,逻辑错误导致的OOM,然后使用以下方法尽量减少内存消耗在,Android应用的开发中，为了防止内存溢出，在处理一些占用内存大而且声明周期较长的对象时候，可以尽量应用软引用和弱引用技术。
- 减少内存对象的占用
- ArrayMap/SparseArray代替hashmap
- 避免在android里面使用Enum
- 减少bitmap的内存占用
• inSampleSize：缩放比例，在把图片载入内存之前，我们需要先计算出一个合适的缩放比例，避免不必要的大图载入。
• decode format：解码格式，选择ARGB_8888/RBG_565/ARGB_4444/ALPHA_8，存在很大差异。 - 减少资源图片的大小，过大的图片可以考虑分段加载
- 内存对象的重复利用
大多数对象的复用，都是利用对象池的技术。
- listview/gridview/recycleview contentview的复用
- inBitmap 属性对于内存对象的复用ARGB_8888/RBG_565/ARGB_4444/ALPHA_8
这个方法在某些条件下非常有用，比如要加载上千张图片的时候。 - 避免在ondraw方法里面 new对象
- StringBuilder 代替+
- 使用最近最少使用算法(Lrucache)等算法,利用时间换空间策略减少内存消耗
