id系统要设定App的内存限制Android有GC自动回收资源为什么还会OOM?容易发生OOM的场景及处理方案如何避免OOM

当程序需要申请一段“大”内存时但是虚拟机没有办法及时的给到这就会抛出

OutOfMemoryError

因为android系统的app的每个进程或者每个虚拟机有个最大内存限制如果申请的内存资源超过这个限制系统就会抛出OOM错误。

跟整个设备的剩余内存没太大关系。

比如比较早的android系统的一个虚拟机最多16M内存当一个app启动后虚拟机不停的申请内存资源来装载图片当超过内存上限时就出现OOM。

APP内存由

两部分组成dalvik也就是java堆创建的对象就是在这里分配的而native是通过c/c方式申请的内存Bitmap就是以这种方式分配的。

以下方法会返回以M为单位的数字不同的系统平台或设备上的值都不太一样这里取到是虚拟机的最大内存资源。

ActivityManager

(ActivityManager)context.getSystemService(Context.ACTIVITY_SERVICE)

int

activityManager.getMemoryClass();//

head堆的大小限制可以查看/system/build.prop文件

48m

heapsize参数表示单个进程heap可用的最大内存但如果存在以下参数dalvik.vm.headgrowthlimit48m表示单个进程heap内存被限定在48m即程序运行过程实际只能使用48m内存为什么Android系统要设定App的内存限制

限制每个应用的可用内存上限可以放置某些应用程序恶意或者无意的使用过多的内存。

而导致其它应用无法正常运行。

Android是有多进程的如果一个进程一个应用耗费过多的内存其他应用就无法运行了。

因为有了限制使得开发者必须好好利用有限资源优化资源的使用。

屏幕显示内容有限内存足够即可。

即使有万千图片千万数据需要使用到但在特定时刻需要展示给用户看的总是有限的因为屏幕显示就那么大上面可以放的信息就是很有限的。

大部分信息都是处于准备显示状态所以没必要给予太多heap内存。

也就是说出现

OOM现象绝大部分原因是我们的程序设计上有问题需要优化。

优化方法很多比如通过时间换空间不停的加载要用的的图片不停的回收不用的图片把大图片解析成适合手机屏幕大小的图片等。

保证了android的稳定性。

android上的app使用独立虚拟机每开一个应用就会打开至少一个独立的虚拟机。

这样可以避免虚拟机崩溃导致整个系统崩溃同时代价就是需要浪费更多的内存。

Android的GC垃圾回收机制会按照特定的算法回收程序不用的内存资源避免app的内存申请约积越多但是GC一般回收的资源是那些无主的对象内存或者软引用的资源。

ps编程要养成习惯不用的对象设置为null。

其实更好的是不用的图片直接recycle。

因为通过设置null让GC来回收有时候还是会来不及。

网络下载大量图片

处理方案多线程异步网络小图直接用LRUCacheSoftRefSd大图按需下载对于需要加载非常多条目信息的ListViewGridView

处理方案Google官方推荐使用“convertview静态类viewholder”

在adapter的getView函数里有个convertView参数告知你是否有可重用的view对象。

如果不使用convertView的话每次调用getView时每次都会重新创建view这样之前的view可能还没销毁加之不断的新建view势必会造成内存剧增从而导致OOM

原因1.

重用缓存convertView传递给getView()方法来避免填充不必要的视图

使用ViewHolder模式来避免没有必要的调用findViewById因为太多的findViewById也会影响性能。

psViewHolder类的作用ViewHolder模式通过在getView方法返回的视图的标签tag中存储一个数据结构。

这个数据结构包含了指向我们要绑定数据的视图的引用从而避免每次调用getView()的时候调用findViewById();

如何避免OOM

避免OOM需要从设计、编码、测试等多个环节综合考虑持续监控和优化应用的内存使用情况可以从四个方面着手首先是减小对象的内存占用其次是内存对象的重复利用然后是避免对象的内存泄露最后是内存使用策略优化

图像资源管理

图片压缩适当尺寸使用适当尺寸和质量的图像避免加载不必要的大图。

可以使用第三方库如Glide、Picasso、Fresco自动处理图像的压缩、大小调整和缓存减小Bitmap对象的内存占用

inSampleSize缩放比例在把图片载入内存之前我们需要先计算出一个合适的缩放比例避免不必要的大图载入decode

format解码格式选择ARGB_8888/RBG_565/ARGB_4444/ALPHA_8存在很大差异。

内存泄漏预防

Context避免不经意的Activity泄露避免静态变量引用Activity或Context静态变量的生命周期与应用相同可能导致Activity无法被正常回收避免在Android里面使用Enum因为Enum的每个值都是一个对象‌会占用额外的内存‌并且在运行时会有较大的开销‌可能导致应用的内存占用增加和DEX文件大小的增大避免在onDraw方法里面执行对象的创建类似onDraw这种频繁调用的方法一定需要注意避免在这里做创建对象的操作因为他会迅速增加内存的使用而且很容易引起频繁的gc甚至是内存抖动监听器和回调的管理注册的监听器和回调应在不再需要时及时取消注册Fragment和View的生命周期管理确保在onDestroy或相应的生命周期方法中清理资源合理释放资源、销毁对象在不再需要的时候要及时释放一些资源或销毁对象尤其是IO流、Bitmap对象、WebView、数据库连接等谨慎使用static对象因为static的生命周期过长和应用的进程保持一致使用不当很可能导致对象泄漏在Android中应该谨慎使用static对象

优化布局与视图

减少布局层级扁平化布局减少嵌套可以有效降低内存占用提高渲染效率避免过度绘制使用工具检测并消除不必要的重叠绘制区域

内存监控与分析

Studio的Profiler工具检查内存使用情况定位内存泄漏LeakCanary在开发过程中要注意避免内存泄漏尤其是长生命周期的对象持有了对Activity或Context的引用导致Activity无法正常被回收。

可以使用工具如LeakCanary来帮助检测内存泄漏问题

数据与缓存策略

使用更加轻量的数据结构比如我们可以考虑使用ArrayMap或SparseArray而不是使用HashMap等传统数据结构。

因为ArrayMap是基于数组实现的‌而HashMap则是基于哈希表实现的在存储少量数据时‌ArrayMap占用的内存相对较少‌因为它通过两个数组来存储键和值‌而HashMap则需要维护一个哈希表和链表‌这增加了其内存开销。

SparseArray更加高效在于他们避免了对key与value的autobox自动装箱并且避免了装箱后的解箱StringBuilder在有些时候代码中会需要使用到大量的字符串拼接的操作这种时候有必要考虑使用StringBuilder来替代频繁的“”合理使用缓存对于一些频繁访问的数据可以使用LruCache来进行内存缓存管理避免重复的创建和销毁提高内存利用率Android自带的Least

Recently

Used缓存策略分页加载对于大量数据采用分页加载避免一次性加载所有数据到内存中

复用系统自带的资源Android系统本身内置了很多的资源例如字符串/颜色/图片/动画/样式以及简单布局等等这些资源都可以在应用程序中直接引用。

这样做不仅仅可以减少应用程序的自身负重减小APK的大小另外还可以一定程度上减少内存的开销复用性更好复用View组件如使用RecyclerView替代ListView利用ViewHolder模式减少重复创建View对象

多进程与服务优化

合理使用多进程对于内存消耗大的服务或模块考虑运行在独立进程中但需注意进程间通信的开销服务生命周期管理后台服务应及时停止避免无谓的内存占用

VM(虚拟机)堆大小调整

size虽然可以通过android:largeHeaptrue申请更大堆空间但这不是根本解决方案且可能导致其他应用或系统性能问题。

借鉴于https://www.runoob.com/w3cnote/android-oom.html