OOM是Android  Out  Of   Memory的缩写,基于Android开发应用时,可能经常出现Out Of Memory 异常.
在Android中,一个Process 只能使用16M内存,要是超过了这个限定就会跳出这个异常。这样就要求我们要时刻想着开释资源。Java的回收工作是交给GC的,如何让GC能实时的回收已经不用的对象,有许多办法。

  因为总内存的施用超过16M而引起OOM的情况,非常简单,我就不继续展开说。值当注意的是Bitmap在不用时,肯定是要recycle,不然OOM是非常容易出现的。
  但是还会出现另外一种情况:明明还有许多内存,但是发生OOM了。
  这类情况时常出现在生成Bitmap的时候。有兴趣的可以试一下,在一个函数里生成一个13m 的int数组。
  再该函数结束后,按理说这个int数组应该已经被开释了,或者说可以开释,这个13M的空间应该可以空出来,
  这个时候要是你继续生白手起家的百万富翁成一个10M的int数组是没有问题的,反而生成一个4M的Bitmap就会跳出OOM。这个就奇怪了,为啥子10M的int够空间,反而4M的Bitmap不敷呢? 
  这个问题困扰好久,在网上,国外各大论坛搜刮了好久,一般关于OOM的解释和解决方法都是,如何让GC尽快回收的代码风格之类,并没有现实的支出上面所说的情况的根源。
  直到昨天在一个老外的blog上终于看到了这方面的解释,我理解后归纳如下:
  在Android中:
  1.一个进程的内存可以由2个部门组成:java 施用内存 ,C 施用内存 ,这两个内存的和必需小于16M,不然就会出现各人熟悉的OOM,这个就是熬头种OOM的情况。
  2.越发奇怪的是这个:一朝内存分配给Java后,以后这块内存纵然开释后,也只能给Java的施用,这个估计跟java虚拟机里把内存分成好几块进行缓存的原因有关,反正C就别想用到这块的内存了,所以要是Java突然占用了一个大块内存,纵然很快开释了:
  C能施用的内存 = 16M - Java某一瞬间占在校大学生创业点子用的最大内存。

  而Bitmap的生成是路程经过过程malloc进行内存分配的,占用的是C的内存,这个也就说明了,上面所说的的4MBitmap无法生成的原因,因为在13M被Java用过后,剩下C能用的只有3M了。


leak window    按字面了解大概就是说一个窗体泄漏了,也就是我们常说的内存泄漏,为什么窗体会泄漏呢?

02-29 10:07:51.410: ERROR/WindowManager(4236): Activity cn.bookall.android.zbook.reader.DocReader has leaked window [email protected] that was originally added here
02-29 10:07:51.410: ERROR/WindowManager(4236): android.view.WindowLeaked: Activity cn.bookall.android.zbook.reader.DocReader has leaked window [email protected] that was originally added here
02-29 10:07:51.410: ERROR/WindowManager(4236):     at android.view.ViewRoot.(ViewRoot.java:247)
...

02-29 10:07:51.410: ERROR/WindowManager(4236):     at cn.bookall.android.zbook.reader.DocView.ShowPopWindowCenter(DocView.java:506)

...

02-29 10:07:51.600: ERROR/AndroidRuntime(4236): java.lang.IllegalArgumentException:View not attached to window manager

产生原因:
我们知道Android的每一个Activity都有个WindowManager窗体管理器,同样,构建在某个Activity之上的对话框、PopupWindow也有相应的WindowManager窗体管理器。因为对话框、PopupWindown不能脱离Activity而单独存在着,所以当某个Dialog或者某个PopupWindow正在显示的时候我们去finish()了承载该Dialog(或PopupWindow)的Activity时,就会抛Window Leaked异常了,因为这个Dialog(或PopupWindow)的WindowManager已经没有谁可以附属了,所以它的窗体管理器已经泄漏了。
解决方法:
关闭(finish)某个Activity前,要确保附属在上面的Dialog或PopupWindow已经关闭(dismiss)了。

       @Override 
      public void onPause(){
         super.onPause();
         if(pw != null) {
              pw.dismiss(); 
         }
      }



更多相关文章

  1. Android内存的全面分析-让你吃透
  2. 金九银十中,看看这31道Android面试题
  3. Google 发布 Android(安卓)性能优化典范
  4. Android(安卓)OOM-Heap,MAT工具检测内存泄露
  5. Android优化笔记--崩溃优化
  6. Android(安卓)RxJava 实际应用讲解:从磁盘 / 内存缓存中 获取缓存
  7. Android常见40道原理性面试,去面试之前必须要了解的知识点
  8. Android(安卓)内存查看常用命令
  9. .如何避免Android内存泄漏

随机推荐

  1. Android的生命周期 Start onResume
  2. Android(安卓)获取apk权限
  3. linux下Android开发环境变量设置
  4. Android support library 23.2新特性介绍
  5. android.uid.system无法读取SD卡信息
  6. android Activity类的runOnUiThread
  7. GreenDao 在 Android Studio 中的配置使
  8. Android 发布可穿戴设备 SDK 的开发者预
  9. Unity与Android接口互相调用
  10. Android音频播放--SoundPool