OOM分析:缩小资源,及时释放;
两次OOM,listView的convertView使用;多次旋转屏幕;android4.2,OOM,堆内存增涨单位为9M;View占用的Bitmap对象不能recycle,也不能被GC;
Drawable在内存占用和绘制速度这两个非常关键的点上胜过Bitmap;
android4.3,GC源码log:GC_CONCURRENT,当分配的对象大小超过384K时触发; GC_EXPLICIT,对垃圾收集的显式调用(System.gc); GC_FOR_ALLOC,内存分配失败时触发; GC_BEFORE_OOM,内存溢出前触发;
freed 199K表示本次垃圾收集释放了199K的内存;53% free 3023K/6343K,其中6343K表示当前内存总量,3023K表示可用内存,53%表示可用内存占总内存的比例;
external 0K/0K，表示可用外部内存/外部内存总量; paused 2ms+2ms,第一个时间值表示markrootset的时间,第二个时间值表示第二次mark的时间,如果触发原因不是GC_CONCURRENT,这一行为单个时间值,表示垃圾收集的耗时时间;
Malloc向系统申请分配指定size个字节的内存空间;返回类型是void*类型;void*表示未确定类型的指针;C,C++规定,void*类型可以强制转换为任何其它类型的指针;
WebP是一种有损压缩利用预测编码技术,主要优势在于高效率;在质量相同的情况下,WebP格式图像的体积要比JPEG格式图像小40%;Google购买On2 Technologies后发展出来的格式;WebP格式图像的编码时间比JPEG格式图像长8倍;
Dalvik虚拟机会为应用程序分配固定大小的heap,如果使用超过了这个heap的大小,且没有可被回收对象,就会报oom;
OOM的具体原因,1.一个进程的内存可以由2个部门组成,java使用内存,C使用内存,这两个内存的和必需小于16M,不然就会出现各人熟悉的OOM;2.一旦内存分配给Java后，,后这块内存纵然开释后,也只能给Java的使用,这个估计跟java虚拟机里把内存分成好几块进行缓存的原因有关,反正C就别想用到这块的内存了,所以要是Java突然占用了一个大块内存,纵然很快开释了,C能使用的内存=16M-Java某一瞬间占在的最大内存;3.而Bitmap的生成是路程经过过程malloc进行内存分配的,占用的是C的内存;
据此,有效避免OOM几点建议:1.对于java中不再使用的资源需要尽快的释放,即设置成null,不要老是指望垃圾回收器为你工作,如果不设置成null,那么资源回收会受到一定的影响;2.尽量少用static方法和static成员,因为static的方法或成员被外部使用的话,而外部的牵引对象没有对其进行释放的话那么整个static的类都不会被释放,也就造成内存泄漏;3.对于不再使用的bitmap应该手动调用recycle方法，并且设置成null。图片还要尽量使用软引用方式，这样可以加快垃圾回收;
解决方法,推荐第一种,1.使用BitmapFactory.Options对图片进行缩略读取解决;2.使用SoftReference解决;
mBitmap.recycle();//高级调用,在没有引用后正常GC将会释放内存. Free the native object associated with this bitmap, and clear the reference to the pixel data.
修改系统/system/build.prop的dalvik.vm.heapsize的堆内存值;
大图片处理:缩放;异步线程(ImageView弱引用),GridView同步(Drawable弱引用);内存缓存(LinkedHashMap),磁盘缓存;内存管理(inBitmap);Displaying Bitmaps in Your UI;
2.2,API8之前,暂停回收;2.3,concurrentGC;
过去图片缓存用SoftReference or WeakReference;2.3,API9,GC对soft/weak references十分激进,失效;2.3,API10之前,bitmap的数据分离存储在nativeMemory中,不可预测的方式释放,3.0,API11,关联存储在Dalvik栈内存;
内存缓存检查在UI线程,磁盘缓存检查在后台线程;
3.0,API11,可以使用BitmapFactory.Options.inBitmap类型;
