Android开发规范详解.docx

每个Android开发者必须知道的内存管理知识
相信一步步走过来的Android从业者，每个人都会遇到OOM的情况。如何避免和防范OOM的出现，对于每一个程序员来说确实是一门必不可少的能力。今天我们就谈谈在Android平台下内存的管理之样的，和IOS的恒久100MB是不同的。一般来说，手机内存的配置越高，厂商也会调大手机支持的内存最大阀值，尤其是现在旗舰机满天发布的情况下。但是开发者为了考虑开发出的APP的内存兼容性，无法保证APP运行在何种手机上，只能从编码角度来优化内存了。
下面我们逐条来分析Android内存优化的关键点。
1、万恶的static
static是个好东西，声明赋值调用就是那么的简单方便，但是伴随而来的还有性能问题。由于static声明变量的生命周期其实是和APP的生命周期一样的，有点类似与Application。如果大量的使用的话，就会占据内存空间不释放，积少成多也会造成内存的不断开销，直至挂掉。static的合理使用一般用来修饰基本数据类型或者轻量级对象，尽量避免修复集合或者大对象，常用作修饰全局配置项、工具类方法、内部类。
2、无关引用
很多情况下，我们需求用到传递引用，但是我们无法确保引用传递出去后能否及时的回收。比如比较有代表性的Context泄漏，很多情况下当Activity 结束掉后，由于仍被其他的对象指向导致一直迟迟不能回收，这就造成了内存泄漏。这时可以考虑第三条建议。
3、善用SoftReference/WeakReference/LruCache
Java、Android中有没有这样一种机制呢，当内存吃紧或者GC扫过的情况下，就能及时把一些内存占用给释放掉，从而分配给需要分配的地方。答案是肯定的，java为我们提供了两个解决方案。如果对内存的开销比较关注的APP，可以考虑使用WeakReference，当GC回收扫过这块内存区域时就会回收；如果不是那么关注的话，可以使用SoftReference，它会在内存申请不足的情况下自动释放，同样也能解决OOM问题。同时 ，使用LRU算法就释放内存，一样的能解决OOM，，请导入v4包。关于第二条的无关引用的问题，我们传参可以考虑使用WeakReference包装一下。
4、谨慎handler
在处理异步操作的时候，handler + thread是个不错的选择。但是相信在使用handler的时候，大家都会遇到警告的情形，这个就是lint为开发者的提醒。handler运行于UI 线程，不断处理来自MessageQueue的消息，如果handler还有消息需要处理但是Activity页面已经结束的情况下，Activity的引用其实并不会被回收，这就造成了内存泄漏。解决方案，一是在Activity的onDestroy方法中调用
(null);取消所有的消息的处理，包括待处理的消息；二是声明handler的内部类为static。
5、Bitmap终极杀手
Bitmap的不当处理极可能造成OOM，绝大多数情况都是因这个原因出现的。Bitamp位图是Android中当之无愧的胖小子，所以在操作的时候当然是十分的