正篇 二. 内存优化管理：

二. 内存优化管理：

*程序开发就要做到，居安思危，要不然等问题来了，就出现了。垮堤之下，大江奔流，滔滔江水，绵绵不绝，一发而不可收拾。
特别是内存。oom的ant之类的运行几下，莫名其妙的就崩了…一看代码，没错啊。try起来都没用，你会疯掉的。*

1. 万恶的static，老生长谈。时刻告诉自己不能用，不能用，可是还是要用，因为太方便了。无关引用，当界面不可见时释放内存

static是个好东西，声明赋值调用就是那么的简单方便，但是伴随而来的还有性能问题。由于static声明变量的生命周期其实是和APP的生命周期一 样的，有点类似与Application。如果大量的使用的话，就会占据内存空间不释放，积少成多也会造成内存的不断开销，直至挂掉。static的合理 使用一般用来修饰基本数据类型或者轻量级对象，尽量避免修复集合或者大对象，常用作修饰全局配置项、工具类方法、内部类。

2. Bitmap终极杀手

Bitmap的不当处理极可能造成OOM，绝大多数情况都是因这个原因出现的。Bitamp位图是Android中当之无愧的胖小子，所以在操作的时候当 然是十分的小心了。由于Dalivk并不会主动的去回收，需要开发者在Bitmap不被使用的时候recycle掉。使用的过程中，及时释放是非常重要 的。同时如果需求允许，也可以去BItmap进行一定的缩放，通过BitmapFactory.Options的inSampleSize属性进行控制。 如果仅仅只想获得Bitmap的属性，其实并不需要根据BItmap的像素去分配内存，只需在解析读取Bmp的时候使用 BitmapFactory.Options的inJustDecodeBounds属性。最后建议大家在加载网络图片的时候，使用软引用或者弱引用并进 行本地缓存，推荐使用android-universal-imageloader或者xUtils，牛人出品，必属精品。

3. BroadCastReceiver、Service

`绑定广播和服务，一定要记得在不需要的时候给解绑。`

4. for循环不要做图片的处理等耗时的操作。

具体操作：

BaseActivity 中


// 清空系统背景图片
getWindow().setBackgroundDrawable(null);

---

onDestroy()中
// 关闭网络请求
getHttp().cancel();

原则就是用完就清空

如果你已经使用了内存问题，如何排除呢
看看以下几篇：

http://blog.csdn.net/guolin_blog/article/details/42238633

http://mp.weixin.qq.com/s?__biz=MzA3NTYzODYzMg==&mid=400891536&idx=1&sn=0b6c629b0abe4a359d6552cd244c0c0c&scene=0&key=d4b25ade3662d6432f4d008c35c73be9edb35e268795decfd642e018f5b9b57ccf844430313ae8cae1936ae1af28f657&ascene=0&uin=MTYzMjY2MTE1&devicetype=iMac+

http://www.lightskystreet.com/2015/09/01/mat_usage/