Android系统优化OOM问题分析.ppt

如何解决OOM问题 避免资源泄漏； 场景：如数据库cursor，文件描述符等系统资源，在处理完毕后都应close。 加载大块数据时，使用soft ref或者weak ref，并进行缓存管理； 场景：加载大量图片时，应使用soft ref，并进行队列缓存管理。 加载Bitmap资源时，使用sample处理，并在使用后调用recycle方法； 如何解决OOM问题 对于超出组件周期的处理应考虑换用安全合理的解决方案； 场景：Activity调用AsyncTask做异步处理，在退出Activity时，应取消AsyncTask的异步线程处理，若逻辑上需要继续执行，安全的做法是采用后台Service的处理方案。 参考资料 /blog/1956059 /blog/1956638 /luoshengyang/article/details/8852432 * * * * Android系统优化系列之二 OOM篇 Overview 什么是OOM OOM产生原因 发生OOM如何定位 如何解决OOM问题 参考资料 什么是OOM OOM是“Out of memory error”的缩写，即“内存溢出错误”； Anroid系统中，每个Process都有一个可使用内存上限，超过这个上限就会出现OOM问题。 OOM产生原因 Dalvik内存相关知识： Dalvik内存大体上分为Java Object Heap、Bitmap Memory和Native Heap三种； Java Object Heap的大小，从dalvik.vm.heapstartsize读取缺省最小值，从dalvik.vm.heapsize读取缺省最大值，这个最大值就是Android应用进程能够使用的最大内存，超过了这个值就会造成OOM； 在HoneyComb之后的版本，Bitmap Memory直接在Java Object Heap中分配，可以受GC的管理。之前的版本是在Native Heap中分配的，但是大小是计入Java Object Heap的使用大小之内的； Native Heap是Native code(c/c++)使用的内存，不受Java Object Heap的大小限制。 OOM产生原因 关于GC（Android 2.3之后的版本）： Cocurrent，GC线程与其他线程是并发执行； Partial collection，一次可能只回收一部分垃圾； 一次垃圾回收造成的程序中止时间通常小于5s； 几种GC类型： GC_CONCURRENT 避免Heap内存满而执行的回收 GC_FOR_MALLOC 应用分配内存不足，需要更多内存进行的回收 GC_EXTERNAL_ALLOC 为external分配的内存执行的回收，如Bitmap GC_HPROF_DUMP_HEAP 做HPROF操作创建HPROF文件的时候执行的 GC_EXPLICIT 程序显式调用了System.gc()引起的回收 OOM产生原因 常见原因 对象被长时间强引用，导致无法被GC回收，而造成内存泄漏； 频繁创建对象； 资源泄漏； 加载数据量太大导致内存占用过多。 发生OOM如何定位 分析Logcat日志中的stack trace dump； DDMS内存监测工具Heap； 内存分析工具MAT（Memory Analyzer Tool） 发生OOM如何定位 分析Logcat日志中dump的OOM stack trace； 分析Logcat日志中dump的memory信息； Memory相关术语: ( VSS = RSS = PSS = USS ) VSS (Virtual Set Size) 进程能访问的所有内存空间大小，包含了一些没有驻留在RAM的内存，比如mallocs已分配但尚未写入 RSS (Resident Set Size) 实际占用的内存，包含所有该进程使用的共享库所占用的内存总大小 PSS (Proportional Set Size) 实际占用的内存，包含按比例分配共享库所占用的内存，比如3个进程共享一个库，则每个进程会计算该库占用的1/3内存大小。很重要的参考量，系统所有进程的PSS总和即为系统占用内存的总和。 USS (Unique Set Size) 进程独自占用的物理内存，运行一个特定进程所需的真正成本，当进程被杀死时，USS即为系统回收的内存值。 发生OOM如何定位 DDMS内存监测工具Heap。 将在工具篇详细介绍。 发生OOM如何定位 内存分析工具MAT。 将在工具篇详细介绍。 如何解决OOM问题 创建对象时，谨慎对待其生命周期，尤其是静态对象。对象的生命周期应与其上下文周期一致； 场景1：全局静态对象若需要调用context对象，应取Application Con