Android 常见导致OOM的主要原因

OOM主要有两种原因导致:

1. 加载大图片;

2. 内存泄漏;

一、加载大图片

在Android应用中加载Bitmap的操作是需要特别小心处理的,因为Bitmap会消耗很多内存。比如,Galaxy Nexus的照相机能够拍摄2592x1936 pixels (5 MB)的图片。 如果bitmap的图像配置是使用ARGB_8888 (从Android 2.3开始的默认配置) ,那么加载这张照片到内存大约需要19MB(2592*1936*4 bytes) 的空间,从而迅速消耗掉该应用的剩余内存空间。
对于分辨率比我们手机屏幕的分辨率高得多的图片,我们应该加载一个缩小版本的图片,从而避免超出程序的内存限制。下面我们就来看一看,如何对一张大图片进行适当的压缩,让它能够以最佳大小显示的同时,还能防止OOM的出现。

来自 http://blog.csdn.net/z191726501/article/details/51182230

2.单例模式

不正确使用单例模式是引起内存泄漏的一个常见问题,单例对象在被初始化后将在JVM的整个生命周期中存在(以静态变量的方式),如果单例对象持有外部对象的引用,那么这个外部对象将不能被JVM正常回收,导致内存泄漏。
如果需要Context,尽量引用Application,而不用Activity。

3.Handler

Handler的生命周期与Activity不一致
由于Handler属于TLS(Thread Local Storage)变量,生命周期和Activity是不一致的。
当Android应用启动的时候,会先创建一个UI主线程的Looper对象,Looper实现了一个简单的消息队列,一个一个的处理里面的Message对象。主线程Looper对象在整个应用生命周期中存在。
当在主线程中初始化Handler时,该Handler和Looper的消息队列关联(没有关联会报错的)。发送到消息队列的Message会引用发送该消息的Handler对象,这样系统可以调用 Handler#handleMessage(Message) 来分发处理该消息。
只要Handler发送的Message尚未被处理,则该Message及发送它的Handler对象将被线程MessageQueue一直持有。因此这种实现方式一般很难保证跟View或者Activity的生命周期保持一致,故很容易导致无法正确释放。
handler引用Activity阻止了GC对Acivity的回收
在Java中,非静态(匿名)内部类会默认隐性引用外部类对象。而静态内部类不会引用外部类对象。
如果外部类是Activity,则会引起Activity泄露。
当Activity finish后,延时消息会继续存在主线程消息队列中1分钟,然后处理消息。而该消息引用了Activity的Handler对象,然后这个Handler又引用了这个Activity。这些引用对象会保持到该消息被处理完,这样就导致该Activity对象无法被回收,从而导致了上面说的 Activity泄露。
错误示例:
private final Handler mHandler = new Handler() {
@Override public void handleMessage(Message msg) { // … }
};
解决办法:
使用显形的引用,1.静态内部类。 2. 外部类
使用弱引用 2. WeakReference
正确示例:

private static class MyHandler extends Handler { 
private final WeakReference<HandlerActivity2> mActivity;                   public MyHandler(HandlerActivity2 activity) {
   mActivity = new WeakReference<HandlerActivity2>(activity);
} 
if (mActivity.get() == null) { return; } mActivity.get().todo(); 
} 
@Override public void onDestroy() { 
// If null, all callbacks and messages will be removed. 

mHandler.removeCallbacksAndMessages(null); 
}
4.非静态内部类导致的内存泄漏:

非静态的内部类会持有外部类的一个引用,所以和前面context说到的一样,如果该内部类生命周期超过外部类的生命周期,就可能引起内存泄露了,如AsyncTask和Handler。因为在Activity中我们可能会用到匿名内部类,所以要小心管理其生命周期。 如果明确生命周期较外部类长的话,那么应该使用静态内部类。

5.Context导致内存泄漏:

android 中很多地方都要用到context,连基本的Activty 和 Service都是从Context派生出来的,我们利用Context主要用来加载资源或者初始化组件,在Activity中有些地方需要用到Context的时候,我们经常会把context给传递过去了,将context传递出去就有可能延长了context的生命周期,最终导致了内存泄漏。例如 我们将activty context对象传递给一个后台线程去执行某些操作,如果在这个过程中因为屏幕旋转而导致activity重建,那么原先的activity对象不会被回收,因为它还被后台线程引用着,如果这个activity消耗了比较多的内存,那么新建activity或者后续操作可能因为旧的activity没有被回收而导致内存泄漏。所以,遇到需要用到context的时候,我们要合理选择不同的context,对于android应用来说还有一个单例的Application Context对象,该对象生命周期和应用的生命周期是绑定的。选择context应该考虑到它的生命周期,如果使用该context的组件的生命周期超过该context对象,那么我们就要考虑是否可以用application context。如果真的需要用到该context对象,可以考虑用弱引用来WeakReference来避免内存泄漏。

来自 http://blog.csdn.net/z191726501/article/details/51182230

  • 0
    点赞
  • 4
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
OOM(Out of Memory)是指在Android应用程序中由于内存不足而导致的崩溃。当应用程序加载或创建大量的对象并且无法释放时,系统的内存资源会耗尽,从而引发OOM异常。 以下是一些常见导致OOM原因和解决方法: 1. 内存泄漏:在Android应用程序中,内存泄漏是最常见导致OOM原因之一。内存泄漏指的是应用程序中的对象无法被垃圾回收器正常释放,从而占用了大量的内存。解决内存泄漏问题需要仔细检查代码,确保在不再需要对象时及时释放对其的引用,例如Activity或Fragment的引用。 2. 大图资源:加载过大的图片资源也是常见的引发OOM原因。在处理图片时,可以使用合适的图片压缩算法、适当的缩放和裁剪操作,并在不需要时及时释放图片资源。 3. 内存占用过高的库或框架:某些第三方库或框架可能会占用大量的内存,尤其是在处理大量数据或图像时。在使用这些库或框架时,需要仔细评估其内存占用情况,并根据实际需求进行优化或选择其他替代方案。 4. 频繁的网络请求:过多的网络请求可能导致内存资源的耗尽。可以通过合理控制请求的频率、使用缓存机制来减少重复请求,以及优化网络请求的代码来减少内存占用。 5. 大量的数据缓存:如果应用程序在缓存数据时没有有效地管理和清理缓存,会导致内存资源的浪费。需要合理使用缓存策略,并在不再需要时及时清理缓存数据。 6. 内存泄漏检测工具:使用内存泄漏检测工具,如LeakCanary,可以帮助发现和解决应用程序中的内存泄漏问题。 7. 优化布局和资源:避免过度使用嵌套布局和过多的资源文件,减少布局层级和资源文件的数量,以降低内存占用。 总之,避免OOM需要开发人员在开发过程中注意内存管理,合理使用内存资源,并进行适当的优化和测试。此外,不同版本的Android系统和设备可能对内存的限制有所不同,因此也需要针对不同的环境进行测试和优化。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值