背景:由于公司项目需要长时间运行，理论上应该是24小时不间断运行，所以必须保证不能发生OOM异常。但是在实际应用中，我的项目长时间运行(10多个小时)之后内存会从起初的50多M上涨至500多M乃至更多，最后每1~2天连续运行之后就会发生OOM异常。根据之前的一些内存优化经验对项目进行优化，从今天开始归类总结，内存分析模块做出4篇终结。
图一是OOM奔溃的日志。
图二是项目跑了9个多小时之后内存涨至400M以上。
今天首先想来总结下OOM原因以及可能造成OOM的地方
OOM，即Out of Memory。就是我们经常说的内存溢出。当内存占有量超过了VM所分配的最大值时，内存不够再分配了就会产生OOM异常。
网上流传的OOM解决方案大多是避免，即如何在使用大内存的地方避免OOM。大多数是如下几点:
1.适当调整图像大小。
2.采用合适的缓存策略。
3.采用低内存占用量的编码方式，比如Bitmap.Config.ARGB_4444比Bitmap.Config.ARGB_8888更省内存。
4.及时回收Bitmap。
5.不要在循环中创建过多的本地变量。
6.自定义对内存分配大小。
7.特殊情况可在mainfests的Application中增加 android:largeHeap="true"属性，比如临时创建多个小图片(地图marker)
这些解决方案更多的是减少内存的使用来避免OOM，其实我觉得OOM还有一个更重要的原因：内存泄漏。
内存泄漏的本质就是new 出来的对象放在Heap上无法被GC回收，即使这个对象已经 没有再引用了
