【Android】Android优化-oom

问题:OOM异常

Android的虚拟机是基于寄存器的Dalvik，它的最大堆大小一般是16M，有的机器为24M。我们平常看到的OutOfMemory的错误，通常是堆内存溢出。移动开发和web开发的最大的区别是设备资源受限，对一般手机应用，这个资源是相当有限的，堆内存的上限值只有16M。Android的缺省值是16M（某些机型是24M），而对于普通应用这是不能改的，当应用程序处理大资源的资源，如图片或视频等媒体资源时 ，数量一多，时间一长，这个16M是很容易耗尽的，OOM是很容易出现的。

原因:

1.数据库的cursor没有关闭。

2.构造adapter没有使用缓存contentview。

3.调用registerReceiver()后未调用unregisterReceiver().

4.未关闭InputStream/OutputStream。

5.Bitmap使用后未调用recycle()。

6.Context泄漏。

7.static关键字等。

一.cursor没有关闭

Cursor是Android查询数据后得到的一个管理数据集合的类，正常情况下，如果查询得到的数据量较小时不会有内存问题，而且虚拟机能够保证Cusor最终会被释放掉。然而如果Cursor的数据量特别大，特别是如果里面有Blob信息时，应该保证Cursor占用的内存被及时的释放掉，而不是等待GC来处理。并且Android明显是倾向于编程者手动的将Cursor close掉，因为在源代码中我们发现，如果等到垃圾回收器来回收时，会给用户以错误提示。

二.adapter没有使用contentview

当一个listview的子项有成千上万个时，如果我们没有采用一定的策略来重用这些资源，那应用的那点内存，是远远不够使用的。在继承BaseAdapter时会让我们重写getView(int position, View   convertView, ViewGroup parent)方法，第二个参数convertView就是我们要用到的重用的对象。

三.没有unregisterReceiver()

广播接收者（BroadcastReceiver）经常在应用中用到，可以在多线程任务完成后发送广播通知UI更新，也可以接收系统广播实现一些功能。当我们Activity中使用了registerReceiver()方法注册了BroadcastReceiver，一定要在Activity的生命周期内调用unregisterReceiver()方法取消注册 ,也就是说registerReceiver()和unregisterReceiver()方法一定要成对出现，通常我们可以重写Activity的onDestory().

四.未关闭InputStream/OutputStream

这个就不多说了，我们操作完输入输出流都要关闭流

五.Bitmap使用后未调用recycle()
可以说出现OutOfMemory问题的绝大多数人，都是因为Bitmap的问题。因为Bitmap占用的内存实在是太多了，它是一个“超级大胖子”，特别是分辨率大的图片，如果要显示多张那问题就更显著了。

解决方法：
1 . 及时的销毁

2 . 设置一定的采样率

3 . 使用软引用(SoftReference)

六.Context泄漏

内部类持有外部对象造成的内存泄露，常见是内部线程造成的

七.static关键字
static是Java中的一个关键字，当用它来修饰成员变量时，那么该变量就属于该类，而不是该类的实例。   不少程序员喜欢用static这个关键字修饰变量，因为他使得变量的生命周期大大延长啦，并且访问的时候，也极其的方便，用类名就能直接访问，各个资源间传值也极其的方便，所以，它经常被我们使用。但如果用它来引用一些资源耗费过多的实例（Context的情况最多），这时就要谨慎对待了

下载文件:http://download.csdn.net/detail/lingwu7/9372959