android内存泄露优化总结
2015-06-04 14:50
549 查看
转自:
/content/2840961.html
http://www.2cto.com/kf/201412/365600.html
android手机给应用分配的内存通常是8兆左右,如果处理内存处理不当很容易造成OutOfMemoryError,我们的产品出现最多的错误也是OutOfMemoryError的异常,
在解决这个异常时在网上发现很多关于OutOfMemoryError的原因的介绍。
OutOfMemoryError主要由以下几种情况造成:
1.数据库的cursor没有关闭。
操作Sqlite数据库时,Cursor是数据库表中每一行的集合,Cursor提供了很多方法,可以很方便的读取数据库中的值,
可以根据索引,列名等获取数据库中的值,通过游标的方式可以调用moveToNext()移到下一行
当我们操作完数据库后,一定要记得调用Cursor对象的close()来关闭游标,释放资源。
2.构造adapter没有使用缓存contentview。
在继承BaseAdapter时会让我们重写getView(int position, View convertView, ViewGroup parent)方法,
第二个参数convertView就是我们要用到的重用的对象
Java代码
![](https://oscdn.geek-share.com/Uploads/Images/Content/201909/21/ce1566552704405406e5259ab81f6841.png)
@Override
public View getView(int position, View convertView, ViewGroup parent) {
ViewHolder vHolder = null;
//如果convertView对象为空则创建新对象,不为空则复用
if (convertView == null) {
convertView = inflater.inflate(..., null);
// 创建 ViewHodler 对象
vHolder = new ViewHolder();
vHolder.img= (ImageView) convertView.findViewById(...);
vHolder.tv= (TextView) convertView
.findViewById(...);
// 将ViewHodler保存到Tag中
convertView.setTag(vHolder);
} else {
//当convertView不为空时,通过getTag()得到View
vHolder = (ViewHolder) convertView.getTag();
}
// 给对象赋值,修改显示的值
vHolder.img.setImageBitmap(...);
vHolder.tv.setText(...);
return convertView;
}
//将显示的View 包装成类
static class ViewHolder {
TextView tv;
ImageView img;
}
这里只讲使用方法,具体性能测试文章请见:
ListView中getView的原理+如何在ListView中放置多个item
http://www.cnblogs.com/xiaowenji/archive/2010/12/08/1900579.html
Android开发之ListView适配器(Adapter)优化
http://shinfocom.iteye.com/blog/1231511
3.调用registerReceiver()后未调用unregisterReceiver().
广播接收者(BroadcastReceiver)经常在应用中用到,可以在多线程任务完成后发送广播通知UI更新,也可以接收系统广播实现一些功能
可以通过代码的方式注册:
IntentFilter postFilter = new IntentFilter();
postFilter.addAction(getPackageName() + ".background.job");
this.registerReceiver(receiver, postFilter);
当我们Activity中使用了registerReceiver()方法注册了BroadcastReceiver,一定要在Activity的生命周期内调用unregisterReceiver()方法取消注册
也就是说registerReceiver()和unregisterReceiver()方法一定要成对出现,通常我们可以重写Activity的onDestory()方法:
Java代码
![](https://oscdn.geek-share.com/Uploads/Images/Content/201909/21/ce1566552704405406e5259ab81f6841.png)
@Override
protected void onDestroy() {
this.unregisterReceiver(receiver);
super.onDestroy();
}
4.未关闭InputStream/OutputStream。
这个就不多说了,我们操作完输入输出流都要关闭流
5.Bitmap使用后未调用recycle()。
图片处理不好是造成内存溢出的又一个头号原因,(在我们的产品中也有体现),
当我们处理完图片之后可以通过调用recycle()方法来回收图片对象
Java代码
![](https://oscdn.geek-share.com/Uploads/Images/Content/201909/21/ce1566552704405406e5259ab81f6841.png)
if(!bitmap.isRecycled())
{
bitmap.recycle()
}
除此之外:
直接使用ImageView显示bitmap会占用较多资源,特别是图片较大的时候,可能导致崩溃。
使用BitmapFactory.Options设置inSampleSize, 这样做可以减少对系统资源的要求。
属性值inSampleSize表示缩略图大小为原始图片大小的几分之一,即如果这个值为2,则取出的缩略图的宽和高都是原始图片的1/2,图片大小就为原始大小的1/4。
BitmapFactory.Options bitmapFactoryOptions = new BitmapFactory.Options();
bitmapFactoryOptions.inJustDecodeBounds = true;
bitmapFactoryOptions.inSampleSize = 2;
// 这里一定要将其设置回false,因为之前我们将其设置成了true
// 设置inJustDecodeBounds为true后,decodeFile并不分配空间,即,BitmapFactory解码出来的Bitmap为Null,但可计算出原始图片的长度和宽度
options.inJustDecodeBounds = false;
Bitmap bmp = BitmapFactory.decodeFile(sourceBitmap, options);
6.Context泄漏。
Context类,时刻的在与它打交道,例如:Service、BroadcastReceiver、Activity等都会利用到Context的相关方法。
但是不懂Context的原理、类结构关系。一个简单的问题是,一个应用程序App中存在多少个Context实例对象呢?
Context,中文直译为“上下文”,SDK中对其说明如下:
Interface to global information about an application environment. This is an abstract class whose implementation
is provided by the Android system. It allows access to application-specific resources and classes, as well as up-calls
for application-level operations such as launching activities, broadcasting and receiving intents, etc
从上可知一下三点,即:
1、它描述的是一个应用程序环境的信息,即上下文。
2、该类是一个抽象(abstract class)类,Android提供了该抽象类的具体实现类(后面我们会讲到是ContextIml类)。
3、通过它我们可以获取应用程序的资源和类,也包括一些应用级别操作,例如:启动一个Activity,发送广播,接受Intent
信息 等。。
应用程序创建Context实例的情况有如下几种情况:
1、创建Application 对象时, 而且整个App共一个Application对象
2、创建Service对象时
3、创建Activity对象时
因此应用程序App共有的Context数目公式为:
总Context实例个数 = Service个数 + Activity个数 + 1(Application对应的Context实例)
具体创建Context的时机
1、创建Application对象的时机
每个应用程序在第一次启动时,都会首先创建Application对象。如果对应用程序启动一个Activity(startActivity)流程比较
清楚的话,创建Application的时机在创建handleBindApplication()方法中
2、创建Activity对象的时机
通过startActivity()或startActivityForResult()请求启动一个Activity时,如果系统检测需要新建一个Activity对象时,就会
回调handleLaunchActivity()方法,该方法继而调用performLaunchActivity()方法,去创建一个Activity实例,并且回调
onCreate(),onStart()方法等。
3、创建Service对象的时机
通过startService或者bindService时,如果系统检测到需要新创建一个Service实例,就会回调handleCreateService()方法,
完成相关数据操作。
Android中context可以作很多操作,但是最主要的功能是加载和访问资源。在android中常用两种context,一种是application context,一种是activity context,通常我们在各种类和方法间传递的是activity context。
继承关系:
![](https://oscdn.geek-share.com/Uploads/Images/Content/201909/21/3083ed173ab63ff1fdbe209a85d9d7f0.png)
区别联系:
public class MyActivity extends Activity {
public void method() {
mContext = this; // since Activity extends Context
mContext = getApplicationContext();
mContext = getBaseContext();
}
}
this 是Activity 的实例,扩展了Context,其生命周期是Activity 创建到销毁。getApplicationContext()返回应用的上下文,生命周期是整个应用,应用摧毁它才摧毁。Activity.this的context 返回当前activity的上下文,属于activity ,activity摧毁他就摧毁
getBaseContext() 返回由构造函数指定或setBaseContext()设置的上下文,SDK文档很少,不推荐使用
搞清楚了生命周期就会在使用过程中犯错误,比如有一个全局的数据操作类用到了context,这个时候就要getApplicationContext 而不是用ACtivity,这就保证了数据库的操作与activity无关(不会一直引用Activity的资源,防止内存泄漏)
应用场景:
比如一个activity的onCreate:
protected void onCreate(Bundle state) {
super.onCreate(state);
TextView label = new TextView(this); //??context?view c
ontrol
label.setText("Leaks are bad");
setContentView(label);
}
把activity context传递给view,意味着view拥有一个指向activity的引用,进而引用activity占有的资源:view hierachy, resource等。这样如果context发生内存泄露的话,就会泄露很多内存。这里泄露的意思是gc没有办法回收activity的内存。
Leaking an entire activity是很容易的一件事。当屏幕旋转的时候,系统会销毁当前的activity,保存状态信息,再创建一个新的activity。
比如我们写了一个应用程序,它需要加载一个很大的图片,我们不希望每次旋转屏幕的时候都销毁这个图片重新加载。
实现这个要求的简单想法就是定义一个静态的Drawable,这样Activity类创建销毁它始终保存在内存中。
实现示例:
public class myactivity extends Activity {
private static Drawable sBackground;
protected void onCreate(Bundle state) {
super.onCreate(state);
TextView label = new TextView(this);
label.setText("Leaks are bad");
if (sBackground == null) {
P 2 / 3
Android Context 详解
sBackground = getDrawable(R.drawable
.large_bitmap);
}
label.setBackgroundDrawable(sBackground);//dra
wable attached to a view
setContentView(label);
}
}
这段程序看起来很简单,但是却问题很大。当屏幕旋转的时候会有leak(即gc没法销毁activity)。我们刚才说过,屏幕旋转的时候系统会销毁当前的activity。但是当drawable和view关联后,drawable保存了view的reference,即sBackground保存了label的引用,而label保存了activity的引用。既然drawable不能销毁,它所引用和间接引用的都不能销毁,这样系统就没有办法销毁当前的activity,于是造成了内存泄露。gc对这种类型的内存泄露是无能为力的。避免这种内存泄露的方法是避免activity中的任何对象的生命周期长过activity,避免由于对象对activity的引用导致activity不能正常被销毁。我们可以使用application
context。application context伴随application的一生,与activity的生命周期无关。application context可以通过Context.getApplicationContext()或者Activity.getApplicationContext()方法获取。
定制一个自己的Application:首先创建一个MyApplication类继承自Application
public class MyApplication extends Application
{
private static Context context;
public void onCreate()
{
context=getApplicationContext();
}
public static Context getContext()
{
return context;
}
}
注意:当程序启动的时候应该初始化MyApplication类,而不是默认的Application类。在AndroidMainifest.xml文件的标签下进行指定就可以了。
<application< p="">
android:name="com.example.hl.MyApplication"
这样就已经实现了一种全局获取Context的机制,之后想在项目中使用Application的Context时,只需调用一下MyApplication.getContext()就可以了。
避免context相关的内存泄露,记住以下几点:
1. 不要让生命周期长的对象引用activity context,即保证引用activity的对象要与activity本身生命周期是一样的
2. 对于生命周期长的对象,可以使用application context
3. 避免非静态的内部类,尽量使用静态类,避免生命周期问题,注意内部类对外部对象引用导致的生命周期变化
4.Context里如果有线程,一定要在onDestroy()里及时停掉。
7.static关键字
当类的成员变量声明成static后,它是属于类的而不是属于对象的,如果我们将很大的资源对象(Bitmap,context等)声明成static,那么这些资源不会随着对象的回收而回收,
会一直存在,所以在使用static关键字定义成员变量的时候要慎重
/content/2840961.html
http://www.2cto.com/kf/201412/365600.html
android手机给应用分配的内存通常是8兆左右,如果处理内存处理不当很容易造成OutOfMemoryError,我们的产品出现最多的错误也是OutOfMemoryError的异常,
在解决这个异常时在网上发现很多关于OutOfMemoryError的原因的介绍。
OutOfMemoryError主要由以下几种情况造成:
1.数据库的cursor没有关闭。
操作Sqlite数据库时,Cursor是数据库表中每一行的集合,Cursor提供了很多方法,可以很方便的读取数据库中的值,
可以根据索引,列名等获取数据库中的值,通过游标的方式可以调用moveToNext()移到下一行
当我们操作完数据库后,一定要记得调用Cursor对象的close()来关闭游标,释放资源。
2.构造adapter没有使用缓存contentview。
在继承BaseAdapter时会让我们重写getView(int position, View convertView, ViewGroup parent)方法,
第二个参数convertView就是我们要用到的重用的对象
Java代码
![](https://oscdn.geek-share.com/Uploads/Images/Content/201909/21/ce1566552704405406e5259ab81f6841.png)
@Override
public View getView(int position, View convertView, ViewGroup parent) {
ViewHolder vHolder = null;
//如果convertView对象为空则创建新对象,不为空则复用
if (convertView == null) {
convertView = inflater.inflate(..., null);
// 创建 ViewHodler 对象
vHolder = new ViewHolder();
vHolder.img= (ImageView) convertView.findViewById(...);
vHolder.tv= (TextView) convertView
.findViewById(...);
// 将ViewHodler保存到Tag中
convertView.setTag(vHolder);
} else {
//当convertView不为空时,通过getTag()得到View
vHolder = (ViewHolder) convertView.getTag();
}
// 给对象赋值,修改显示的值
vHolder.img.setImageBitmap(...);
vHolder.tv.setText(...);
return convertView;
}
//将显示的View 包装成类
static class ViewHolder {
TextView tv;
ImageView img;
}
这里只讲使用方法,具体性能测试文章请见:
ListView中getView的原理+如何在ListView中放置多个item
http://www.cnblogs.com/xiaowenji/archive/2010/12/08/1900579.html
Android开发之ListView适配器(Adapter)优化
http://shinfocom.iteye.com/blog/1231511
3.调用registerReceiver()后未调用unregisterReceiver().
广播接收者(BroadcastReceiver)经常在应用中用到,可以在多线程任务完成后发送广播通知UI更新,也可以接收系统广播实现一些功能
可以通过代码的方式注册:
IntentFilter postFilter = new IntentFilter();
postFilter.addAction(getPackageName() + ".background.job");
this.registerReceiver(receiver, postFilter);
当我们Activity中使用了registerReceiver()方法注册了BroadcastReceiver,一定要在Activity的生命周期内调用unregisterReceiver()方法取消注册
也就是说registerReceiver()和unregisterReceiver()方法一定要成对出现,通常我们可以重写Activity的onDestory()方法:
Java代码
![](https://oscdn.geek-share.com/Uploads/Images/Content/201909/21/ce1566552704405406e5259ab81f6841.png)
@Override
protected void onDestroy() {
this.unregisterReceiver(receiver);
super.onDestroy();
}
4.未关闭InputStream/OutputStream。
这个就不多说了,我们操作完输入输出流都要关闭流
5.Bitmap使用后未调用recycle()。
图片处理不好是造成内存溢出的又一个头号原因,(在我们的产品中也有体现),
当我们处理完图片之后可以通过调用recycle()方法来回收图片对象
Java代码
![](https://oscdn.geek-share.com/Uploads/Images/Content/201909/21/ce1566552704405406e5259ab81f6841.png)
if(!bitmap.isRecycled())
{
bitmap.recycle()
}
除此之外:
直接使用ImageView显示bitmap会占用较多资源,特别是图片较大的时候,可能导致崩溃。
使用BitmapFactory.Options设置inSampleSize, 这样做可以减少对系统资源的要求。
属性值inSampleSize表示缩略图大小为原始图片大小的几分之一,即如果这个值为2,则取出的缩略图的宽和高都是原始图片的1/2,图片大小就为原始大小的1/4。
BitmapFactory.Options bitmapFactoryOptions = new BitmapFactory.Options();
bitmapFactoryOptions.inJustDecodeBounds = true;
bitmapFactoryOptions.inSampleSize = 2;
// 这里一定要将其设置回false,因为之前我们将其设置成了true
// 设置inJustDecodeBounds为true后,decodeFile并不分配空间,即,BitmapFactory解码出来的Bitmap为Null,但可计算出原始图片的长度和宽度
options.inJustDecodeBounds = false;
Bitmap bmp = BitmapFactory.decodeFile(sourceBitmap, options);
6.Context泄漏。
Context类,时刻的在与它打交道,例如:Service、BroadcastReceiver、Activity等都会利用到Context的相关方法。
但是不懂Context的原理、类结构关系。一个简单的问题是,一个应用程序App中存在多少个Context实例对象呢?
Context,中文直译为“上下文”,SDK中对其说明如下:
Interface to global information about an application environment. This is an abstract class whose implementation
is provided by the Android system. It allows access to application-specific resources and classes, as well as up-calls
for application-level operations such as launching activities, broadcasting and receiving intents, etc
从上可知一下三点,即:
1、它描述的是一个应用程序环境的信息,即上下文。
2、该类是一个抽象(abstract class)类,Android提供了该抽象类的具体实现类(后面我们会讲到是ContextIml类)。
3、通过它我们可以获取应用程序的资源和类,也包括一些应用级别操作,例如:启动一个Activity,发送广播,接受Intent
信息 等。。
应用程序创建Context实例的情况有如下几种情况:
1、创建Application 对象时, 而且整个App共一个Application对象
2、创建Service对象时
3、创建Activity对象时
因此应用程序App共有的Context数目公式为:
总Context实例个数 = Service个数 + Activity个数 + 1(Application对应的Context实例)
具体创建Context的时机
1、创建Application对象的时机
每个应用程序在第一次启动时,都会首先创建Application对象。如果对应用程序启动一个Activity(startActivity)流程比较
清楚的话,创建Application的时机在创建handleBindApplication()方法中
2、创建Activity对象的时机
通过startActivity()或startActivityForResult()请求启动一个Activity时,如果系统检测需要新建一个Activity对象时,就会
回调handleLaunchActivity()方法,该方法继而调用performLaunchActivity()方法,去创建一个Activity实例,并且回调
onCreate(),onStart()方法等。
3、创建Service对象的时机
通过startService或者bindService时,如果系统检测到需要新创建一个Service实例,就会回调handleCreateService()方法,
完成相关数据操作。
Android中context可以作很多操作,但是最主要的功能是加载和访问资源。在android中常用两种context,一种是application context,一种是activity context,通常我们在各种类和方法间传递的是activity context。
继承关系:
![](https://oscdn.geek-share.com/Uploads/Images/Content/201909/21/3083ed173ab63ff1fdbe209a85d9d7f0.png)
区别联系:
public class MyActivity extends Activity {
public void method() {
mContext = this; // since Activity extends Context
mContext = getApplicationContext();
mContext = getBaseContext();
}
}
this 是Activity 的实例,扩展了Context,其生命周期是Activity 创建到销毁。getApplicationContext()返回应用的上下文,生命周期是整个应用,应用摧毁它才摧毁。Activity.this的context 返回当前activity的上下文,属于activity ,activity摧毁他就摧毁
getBaseContext() 返回由构造函数指定或setBaseContext()设置的上下文,SDK文档很少,不推荐使用
搞清楚了生命周期就会在使用过程中犯错误,比如有一个全局的数据操作类用到了context,这个时候就要getApplicationContext 而不是用ACtivity,这就保证了数据库的操作与activity无关(不会一直引用Activity的资源,防止内存泄漏)
应用场景:
比如一个activity的onCreate:
protected void onCreate(Bundle state) {
super.onCreate(state);
TextView label = new TextView(this); //??context?view c
ontrol
label.setText("Leaks are bad");
setContentView(label);
}
把activity context传递给view,意味着view拥有一个指向activity的引用,进而引用activity占有的资源:view hierachy, resource等。这样如果context发生内存泄露的话,就会泄露很多内存。这里泄露的意思是gc没有办法回收activity的内存。
Leaking an entire activity是很容易的一件事。当屏幕旋转的时候,系统会销毁当前的activity,保存状态信息,再创建一个新的activity。
比如我们写了一个应用程序,它需要加载一个很大的图片,我们不希望每次旋转屏幕的时候都销毁这个图片重新加载。
实现这个要求的简单想法就是定义一个静态的Drawable,这样Activity类创建销毁它始终保存在内存中。
实现示例:
public class myactivity extends Activity {
private static Drawable sBackground;
protected void onCreate(Bundle state) {
super.onCreate(state);
TextView label = new TextView(this);
label.setText("Leaks are bad");
if (sBackground == null) {
P 2 / 3
Android Context 详解
sBackground = getDrawable(R.drawable
.large_bitmap);
}
label.setBackgroundDrawable(sBackground);//dra
wable attached to a view
setContentView(label);
}
}
这段程序看起来很简单,但是却问题很大。当屏幕旋转的时候会有leak(即gc没法销毁activity)。我们刚才说过,屏幕旋转的时候系统会销毁当前的activity。但是当drawable和view关联后,drawable保存了view的reference,即sBackground保存了label的引用,而label保存了activity的引用。既然drawable不能销毁,它所引用和间接引用的都不能销毁,这样系统就没有办法销毁当前的activity,于是造成了内存泄露。gc对这种类型的内存泄露是无能为力的。避免这种内存泄露的方法是避免activity中的任何对象的生命周期长过activity,避免由于对象对activity的引用导致activity不能正常被销毁。我们可以使用application
context。application context伴随application的一生,与activity的生命周期无关。application context可以通过Context.getApplicationContext()或者Activity.getApplicationContext()方法获取。
定制一个自己的Application:首先创建一个MyApplication类继承自Application
public class MyApplication extends Application
{
private static Context context;
public void onCreate()
{
context=getApplicationContext();
}
public static Context getContext()
{
return context;
}
}
注意:当程序启动的时候应该初始化MyApplication类,而不是默认的Application类。在AndroidMainifest.xml文件的标签下进行指定就可以了。
<application< p="">
android:name="com.example.hl.MyApplication"
这样就已经实现了一种全局获取Context的机制,之后想在项目中使用Application的Context时,只需调用一下MyApplication.getContext()就可以了。
避免context相关的内存泄露,记住以下几点:
1. 不要让生命周期长的对象引用activity context,即保证引用activity的对象要与activity本身生命周期是一样的
2. 对于生命周期长的对象,可以使用application context
3. 避免非静态的内部类,尽量使用静态类,避免生命周期问题,注意内部类对外部对象引用导致的生命周期变化
4.Context里如果有线程,一定要在onDestroy()里及时停掉。
7.static关键字
当类的成员变量声明成static后,它是属于类的而不是属于对象的,如果我们将很大的资源对象(Bitmap,context等)声明成static,那么这些资源不会随着对象的回收而回收,
会一直存在,所以在使用static关键字定义成员变量的时候要慎重
相关文章推荐
- Android平台上使用气压传感器计算海拔高度
- Android Service的使用方法 音乐播放器实例
- Android项目使用support v7时遇到的各种问题
- Android 自定义字体中英文混合后导致页边距不对的解决方案
- Android带下载进度条的通知栏
- Android退出整个应用程序
- Android 获取屏幕信息
- Android 属性动画简介
- Android换肤技术
- Android设置界面切换动画的两种方式
- Android常用开源组件
- android Canvas drawText 文字居中
- SeAndroid上指纹系统的权限说明
- Android自定义控件实战——仿淘宝商品浏览界面
- android 自定义Adapter
- 抽取android4.4原生浏览器的PieMenu并修改为所需的功能
- android studio下gradle与Git出错解决方法
- android 动态设置控件的高度,使用对应布局中的dp值
- Android手机SD卡文件或目录拷贝、复制、粘贴功能实现代码
- 使用Ant批量打包Android渠道包