|
1 |
|
用BitmapFactory解码一张图片时，有时会遇到该错误。这往往是由于图片过大造成的。要想正常使用，则需要分配更少的内存空间来存储。
BitmapFactory.Options.inSampleSize
设置恰当的inSampleSize可以使BitmapFactory分配更少的空间以消除该错误。inSampleSize的具体含义请参考SDK文档。例如：
|
1 2 3 |
|
如何设置恰当的inSampleSize
设置恰当的inSampleSize是解决该问题的关键之一。BitmapFactory.Options提供了另一个成员inJustDecodeBounds。
|
1 2 3 |
|
设置inJustDecodeBounds为true后，decodeFile并不分配空间，但可计算出原始图片的长度和宽度，即opts.width和opts.height。有了这两个参数，再通过一定的算法，即可得到一个恰当的inSampleSize。
查看Android源码，Android提供了一种动态计算的方法。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 |
|
使用该算法，就可动态计算出图片的inSampleSize。
|
1 2 3 4 5 6 7 8 9 10 11 |
|
另外，可以通过Bitmap.recycle()方法来释放位图所占的空间，当然前提是位图没有被使用
附加:
在开发图片浏览器等软件是，很多时候要显示图片的缩略图，而一般情况下，我们要将图片按照固定大小取缩略图，一般取缩略图的方法是使用BitmapFactory的decodeFile方法，然后通过传递进去 BitmapFactory.Options类型的参数进行取缩略图，在Option中，属性值inSampleSize表示缩略图大小为原始图片大小的几分之一，即如果这个值为2，则取出的缩略图的宽和高都是原始图片的1/2，图片大小就为原始大小的1/4。
然而，如果我们想取固定大小的缩略图就比较困难了，比如，我们想将不同大小的图片去出来的缩略图高度都为200px，而且要保证图片不失真，那怎么办?我们总不能将原始图片加载到内存中再进行缩放处理吧，要知道在移动开发中，内存是相当宝贵的，而且一张100K的图片，加载完所占用的内存何止 100K?
经过研究，发现，Options中有个属性inJustDecodeBounds，研究了一下，终于明白是什么意思了，SDK中的E文是这么说的
If set to true, the decoder will return null (no bitmap), but the out... fields will still be set, allowing the caller to query the bitmap without having to allocate the memory for its pixels.
意思就是说如果该值设为true那么将不返回实际的bitmap不给其分配内存空间而里面只包括一些解码边界信息即图片大小信息，那么相应的方法也就出来了，通过设置inJustDecodeBounds为true，获取到outHeight(图片原始高度)和 outWidth(图片的原始宽度)，然后计算一个inSampleSize(缩放值)，然后就可以取图片了，这里要注意的是，inSampleSize 可能小于0，必须做判断。
具体代码如下：
FrameLayout fr=(FrameLayout)findViewById(R.id.FrameLayout01);
BitmapFactory.Options options = new BitmapFactory.Options();
options.inJustDecodeBounds = true;
// 获取这个图片的宽和高
Bitmap bitmap = BitmapFactory.decodeFile("/sdcard/test.jpg", options); //此时的bitmap为null
options.inJustDecodeBounds = false;
//计算缩放比
int be = (int)(options.outHeight / (float)200);
if (be <= 0)
be = 1;
options.inSampleSize = be;
//重新读入图片，注意这次要把options.inJustDecodeBounds 设为 false
bitmap=BitmapFactory.decodeFile("/sdcard/test.jpg",options); //此时的bitmap不为null
ImageView imageView=new ImageView(this);
imageView.setImageBitmap(bitmap);
这样我们就可以读取较大的图片而不会内存溢出了。如果你想把压缩后的图片保存在Sdcard上的话就很简单了：
File file=new File("/sdcard/feng.png");
try {
FileOutputStream out=new FileOutputStream(file);
if(bitmap.compress(Bitmap.CompressFormat.PNG, 100, out)){
out.flush();
out.close();
}
} catch (FileNotFoundException e) {
// TODO Auto-generated catch block
e.printStackTrace();
} catch (IOException e) {
// TODO Auto-generated catch block
e.printStackTrace();
}
ok，这样就把图片保存在/sdcard/feng.png这个文件里面了，
1.内存溢出就是堆里的东西太多了
2.虚拟机撑不住了就会挂掉,垃圾回收只回收孤儿引用
昨天在模拟器上给gallery放入图片的时候，出现java.lang.OutOfMemoryError: bitmap size exceeds VM budget 异常，图像大小超过了RAM内存。
模拟器RAM比较小，只有8M内存，当我放入的大量的图片（每个100多K左右），就出现上面的原因。
由于每张图片先前是压缩的情况，放入到Bitmap的时候，大小会变大，导致超出RAM内存，具体解决办法如下：
//解决加载图片 内存溢出的问题
//Options 只保存图片尺寸大小，不保存图片到内存
BitmapFactory.Options opts = new BitmapFactory.Options();
//缩放的比例，缩放是很难按准备的比例进行缩放的，其值表明缩放的倍数，SDK中建议其值是2的指数值,值越大会导致图片不清晰
opts.inSampleSize = 4;
Bitmap bmp =
null;
bmp =
BitmapFactory.decodeResource(getResources(), mImageIds[position],opts);
...
//回收
bmp.recycle();
通过上面的方式解决了，但是这并不是最完美的解决方式。
通过一些了解，得知如下：
优化Dalvik虚拟机的堆内存分配
对于Android平台来说，其托管层使用的Dalvik Java VM从目前的表现来看还有很多地方可以优化处理，比如我们在开发一些大型游戏或耗资源的应用中可能考虑手动干涉GC处理，使用
dalvik.system.VMRuntime类提供的setTargetHeapUtilization方法可以增强程序堆内存的处理效率。当然具体原理我们可以参考开源工程，这里我们仅说下使用方法:
private final static float TARGET_HEAP_UTILIZATION = 0.75f; 在程序onCreate时就可以调用
VMRuntime.getRuntime().setTargetHeapUtilization(TARGET_HEAP_UTILIZATION); 即可。
Android堆内存也可自己定义大小
对于一些Android项目，影响性能瓶颈的主要是Android自己内存管理机制问题，目前手机厂商对RAM都比较吝啬，对于软件的流畅性来说RAM对性能的影响十分敏感，除了 优化Dalvik虚拟机的堆内存分配外，我们还可以强制定义自己软件的对内存大小，我们使用Dalvik提供的
dalvik.system.VMRuntime类来设置最小堆内存为例:
private final static int CWJ_HEAP_SIZE = 6* 1024* 1024 ;
VMRuntime.getRuntime().setMinimumHeapSize(CWJ_HEAP_SIZE); //设置最小heap内存为6MB大小。当然对于内存吃紧来说还可以通过手动干涉GC去处理
bitmap 设置图片尺寸，避免 内存溢出 OutOfMemoryError的优化方法
★android 中用bitmap 时很容易内存溢出，报如下错误：Java.lang.OutOfMemoryError
: bitmap size exceeds VM budget
● 主要是加上这段：
BitmapFactory.Options options = new BitmapFactory.Options();
options.inSampleSize = 2;
● eg1：(通过Uri取图片)
private ImageView preview;
BitmapFactory.Options options = new BitmapFactory.Options();
options.inSampleSize = 2;//图片宽高都为原来的二分之一，即图片为原来的四分之一
Bitmap bitmap = BitmapFactory.decodeStream(cr
.openInputStream(uri), null,
options);
preview.setImageBitmap(bitmap);
以上代码可以优化内存溢出，但它只是改变图片大小，并不能彻底解决内存溢出。
● eg2:（通过路径去图片）
private ImageView preview;
private String fileName= "/sdcard/DCIM/Camera/2010-05-14 16.01.44.jpg";
BitmapFactory.Options options = new BitmapFactory.Options();
options.inSampleSize = 2;//图片宽高都为原来的二分之一，即图片为原来的四分之一
Bitmap b = BitmapFactory.decodeFile(fileName,
options);
preview.setImageBitmap(b);
filePath.setText(fileName);
进公司的第一个项目就遇到了一个比较难缠的客户，不过总算对付过去了。在第一个项目中由于app加载的图片、报表比较多，所以经常报出内存溢出的错误，很是头疼。不过在project leader的带领下，基本算是解决了。在此感谢一下my leader，Samuel.Cai辛苦了。哈哈......
以下是一些总结，ps：从我leader那边搞过来的，和大家分享一下，哈哈
1. 当项目中包含大量图片，或者图片过大，可能会oom
方法1 ： 等比例缩小图片
BitmapFactory.Options options = new BitmapFactory.Options();
options.inSampleSize = 4;
方法2 ： 对图片采用软引用，及时地进行recyle()操作
SoftReference<Bitmap> bitmap;
bitmap = new SoftReference<Bitmap>(pBitmap);
if(bitmap != null){
if(bitmap.get() != null && !bitmap.get().isRecycled()){
bitmap.get().recycle();
bitmap = null;
}
}
方法3 ： 对复杂的listview进行合理设计与编码：
1. 注意重用Adapter里面的 convertView 以及holder机制的运用
－－－－－ 参考资料： api
demo list 14. Efficient Adapter
public View getView(int position, View convertView, ViewGroup parent) {
if (convertView == null) {
v =
mInflater.inflate(resource, parent, false);
final int[] to = mTo;
final int
count = to.length;
final View[]
holder = new View[count];
for (int i = 0; i < count; i++) {
holder[i] = v.findViewById(to[i]);
}
v.setTag(holder);
} else {
｝
｝
2. 上述方法尝试还未成功，可用 lazy loading data ----- 参考资料：api demo list 13
方法4 ：
单个页面，横竖屏切换N次后 OOM
1. 看看页面布局当中有没有大的图片，比如背景图之类的。去除xml中相关设置，改在程序中设置背景图（放在onCreate()方法中）：
Drawable bg =
getResources().getDrawable(R.drawable.bg);
XXX.setBackgroundDrawable(rlAdDetailone_bg);
在Activity destory时注意，bg.setCallback(null);
防止Activity得不到及时的释放
2. 跟上面方法相似，直接把xml配置文件加载成view 再放到一个容器里，然后直接调用 this.setContentView(View view);方法
避免xml的重复加载
方法5 ：
在页面切换时尽可能少地重复使用一些代码，比如：重复调用数据库，反复使用某些对象等等......
方法6 ：Android堆内存也可自己定义大小 和 优化Dalvik虚拟机的堆内存分配
注意若使用这种方法：project build
target 只能选择 <= 2.2 版本，否则编译将通不过。 所以不建议用这种方式
private final static int CWJ_HEAP_SIZE= 6*1024*1024;
private final static float TARGET_HEAP_UTILIZATION = 0.75f;
VMRuntime.getRuntime().setMinimumHeapSize(CWJ_HEAP_SIZE);
VMRuntime.getRuntime().setTargetHeapUtilization(TARGET_HEAP_UTILIZATION);
android 内存溢出问题分析
-
-
最近的项目中，内存一直再增长，但是不知道是什么问题，导致内存溢出，在网上看到了这么一篇关于内存分析与管理的文章，解决了部分问题，感觉这篇文章还不错，就转帖到我的blog上了，希望对大家有所帮助。如果哪里有不好的地方，给留下言，然后我们大家继续完善内存泄露的问题，对大家都会有所帮助的，呵呵
一、概述 1
二、Android(Java)中常见的容易引起内存泄漏的不良代码 1
(一)
查询数据库没有关闭游标 2
(二) 构造Adapter时，没有使用缓存的 convertView 3
(三) Bitmap对象不在使用时调用recycle()释放内存 4
(四) 释放对象的引用 4
(五) 其他
5
三、内存监测工具 DDMS --> Heap 5
四、内存分析工具 MAT(Memory Analyzer Tool) 7
(一) 生成.hprof文件 7
(二) 使用MAT导入.hprof文件
8
(三) 使用MAT的视图工具分析内存 8
一、概述
Java编程中经常容易被忽视，但本身又十分重要的一个问题就是内存使用的问题。Android应用主要使用Java语言编写，因此这个问题也同样会在 Android开发中出现。本文不对Java编程问题做探讨，而是对于在Android中，特别是应用开发中的此类问题进行整理。
由于作者接触Android时间并不是很长，因此如有叙述不当之处，欢迎指正。
二、Android(Java)中常见的容易引起内存泄漏的不良代码
Android主要应用在嵌入式设备当中，而嵌入式设备由于一些众所周知的条件限制，通常都不会有很高的配置，特别是内存是比较有限的。如果我们编写的代 码当中有太多的对内存使用不当的地方，难免会使得我们的设备运行缓慢，甚至是死机。为了能够使得Android应用程序安全且快速的运行，Android 的每个应用程序都会使用一个专有的Dalvik虚拟机实例来运行，它是由Zygote服务进程孵化出来的，也就是说每个应用程序都是在属于自己的进程中运 行的。一方面，如果程序在运行过程中出现了内存泄漏的问题，仅仅会使得自己的进程被kill掉，而不会影响其他进程（如果是system_process 等系统进程出问题的话，则会引起系统重启）。另一方面Android为不同类型的进程分配了不同的内存使用上限，如果应用进程使用的内存超过了这个上限， 则会被系统视为内存泄漏，从而被kill掉。Android为应用进程分配的内存上限如下所示：
位置：
/ANDROID_SOURCE/system/core/rootdir/init.rc 部分脚本
# Define the oom_adj values for the classes
of processes that can be
# killed
by the kernel. These are used in ActivityManagerService.
setprop ro.FOREGROUND_APP_ADJ 0
setprop ro.VISIBLE_APP_ADJ 1
setprop ro.SECONDARY_SERVER_ADJ 2
setprop ro.BACKUP_APP_ADJ 2
setprop ro.HOME_APP_ADJ 4
setprop ro.HIDDEN_APP_MIN_ADJ 7
setprop ro.CONTENT_PROVIDER_ADJ 14
setprop ro.EMPTY_APP_ADJ 15
# Define
the memory thresholds at which the above process classes will
# be
killed. These numbers are in pages (4k).
setprop ro.FOREGROUND_APP_MEM 1536
setprop ro.VISIBLE_APP_MEM 2048
setprop ro.SECONDARY_SERVER_MEM 4096
setprop ro.BACKUP_APP_MEM 4096
setprop ro.HOME_APP_MEM 4096
setprop ro.HIDDEN_APP_MEM 5120
setprop ro.CONTENT_PROVIDER_MEM 5632
setprop ro.EMPTY_APP_MEM 6144
# Write
value must be consistent with the above properties.
# Note that the driver only supports 6 slots,
so we have HOME_APP at the
# same
memory level as services.
write
/sys/module/lowmemorykiller/parameters/adj 0,1,2,7,14,15
write /proc/sys/vm/overcommit_memory 1
write /proc/sys/vm/min_free_order_shift 4
write /sys/module/lowmemorykiller/parameters/minfree
1536,2048,4096,5120,5632,6144
# Set init its forked children‘s oom_adj.
write /proc/1/oom_adj -16
正因为我们的应用程序能够使用的内存有限，所以在编写代码的时候需要特别注意内存使用问题。如下是一些常见的内存使用不当的情况。
(一)
查询数据库没有关闭游标
描述：
程序中经常会进行查询数据库的操作，但是经常会有使用完毕Cursor后没有关闭的情况。如果我们的查询结果集比较小，对内存的消耗不容易被发现，只有在常时间大量操作的情况下才会复现内存问题，这样就会给以后的测试和问题排查带来困难和风险。
示例代码：
Cursor
cursor = getContentResolver().query(uri ...);
if
(cursor.moveToNext()) {
... ...
}
修正示例代码：
Cursor
cursor = null;
try {
cursor = getContentResolver().query(uri ...);
if (cursor != null &&
cursor.moveToNext()) {
... ...
}
} finally
{
if (cursor != null) {
try {
cursor.close();
} catch (Exception e) {
//ignore this
}
}
}
(二)
构造Adapter时，没有使用缓存的 convertView
描述：
以构造ListView的BaseAdapter为例，在BaseAdapter中提高了方法：
public
View getView(int position, View convertView, ViewGroup parent)
来 向ListView提供每一个item所需要的view对象。初始时ListView会从BaseAdapter中根据当前的屏幕布局实例化一定数量的 view对象，同时ListView会将这些view对象缓存起来。当向上滚动ListView时，原先位于最上面的list item的view对象会被回收，然后被用来构造新出现的最下面的list item。这个构造过程就是由getView()方法完成的，getView()的第二个形参 View convertView就是被缓存起来的list item的view对象(初始化时缓存中没有view对象则convertView是null)。
由此可以看出，如果我们不去使用convertView，而是每次都在getView()中重新实例化一个View对象的话，即浪费资源也浪费时间，也会使得内存占用越来越大。ListView回收list
item的view对象的过程可以查看:
android.widget.AbsListView.java
--> void addScrapView(View scrap) 方法。
示例代码：
public
View getView(int position, View convertView, ViewGroup parent) {
View view = new Xxx(...);
... ...
return view;
}
修正示例代码：
public
View getView(int position, View convertView, ViewGroup parent) {
View view = null;
if (convertView != null) {
view = convertView;
populate(view, getItem(position));
...
} else {
view = new Xxx(...);
...
}
return view;
}
(三)
Bitmap对象不在使用时调用recycle()释放内存
描述：
有时我们会手工的操作Bitmap对象，如果一个Bitmap对象比较占内存，当它不在被使用的时候，可以调用Bitmap.recycle()方法回收此对象的像素所占用的内存，但这不是必须的，视情况而定。可以看一下代码中的注释：
/**
* Free up the memory associated with this
bitmap‘s pixels, and mark the
* bitmap as "dead", meaning it will
throw an exception if getPixels() or
* setPixels() is called, and will draw
nothing. This operation cannot be
* reversed, so it should only be called if
you are sure there are no
* further uses for the bitmap. This is an
advanced call, and normally need
* not be called, since the normal GC process
will free up this memory when
* there are no more references to this
bitmap.
*/
(四) 释放对象的引用
描述：
这种情况描述起来比较麻烦，举两个例子进行说明。
示例A：
假设有如下操作
public
class DemoActivity extends Activity {
... ...
private Handler mHandler = ...
private Object obj;
public void operation() {
obj = initObj();
...
[Mark]
mHandler.post(new Runnable() {
public void run() {
useObj(obj);
}
});
}
}
我们有一个成员变量 obj，在operation()中我们希望能够将处理obj实例的操作post到某个线程的MessageQueue中。在以上的代码中，即便是 mHandler所在的线程使用完了obj所引用的对象，但这个对象仍然不会被垃圾回收掉，因为DemoActivity.obj还保有这个对象的引用。 所以如果在DemoActivity中不再使用这个对象了，可以在[Mark]的位置释放对象的引用，而代码可以修改为：
... ...
public
void operation() {
obj = initObj();
...
final Object o = obj;
obj = null;
mHandler.post(new Runnable() {
public void run() {
useObj(o);
}
}
}
... ...
示例B:
假设我们希望在锁屏界面(LockScreen)中，监听系统中的电话服务以获取一些信息(如信号强度等)，则可以在LockScreen中定义一个 PhoneStateListener的对象，同时将它注册到TelephonyManager服务中。对于LockScreen对象，当需要显示锁屏界 面的时候就会创建一个LockScreen对象，而当锁屏界面消失的时候LockScreen对象就会被释放掉。
但是如果在释放LockScreen对象的时候忘记取消我们之前注册的PhoneStateListener对象，则会导致LockScreen无法被垃 圾回收。如果不断的使锁屏界面显示和消失，则最终会由于大量的LockScreen对象没有办法被回收而引起OutOfMemory,使得
system_process进程挂掉。
总之当一个生命周期较短的对象A，被一个生命周期较长的对象B保有其引用的情况下，在A的生命周期结束时，要在B中清除掉对A的引用。
(五)
其他
Android应用程序中最典型的需要注意释放资源的情况是在Activity的生命周期中，在onPause()、onStop()、 onDestroy()方法中需要适当的释放资源的情况。由于此情况很基础，在此不详细说明，具体可以查看官方文档对Activity生命周期的介绍，以 明确何时应该释放哪些资源。
三、内存监测工具 DDMS --> Heap
无论怎么小心，想完全避免bad code是不可能的，此时就需要一些工具来帮助我们检查代码中是否存在会造成内存泄漏的地方。Android tools中的DDMS就带有一个很不错的内存监测工具Heap(这里我使用eclipse的ADT插件，并以真机为例，在模拟器中的情况类似)。用
Heap监测应用进程使用内存情况的步骤如下：
1. 启动eclipse后，切换到DDMS透视图，并确认Devices视图、Heap视图都是打开的；
2. 将手机通过USB链接至电脑，链接时需要确认手机是处于“USB调试”模式，而不是作为“Mass Storage”；
3. 链接成功后，在DDMS的Devices视图中将会显示手机设备的序列号，以及设备中正在运行的部分进程信息；
4. 点击选中想要监测的进程，比如system_process进程；
5. 点击选中Devices视图界面中最上方一排图标中的“Update Heap”图标；
6. 点击Heap视图中的“Cause GC”按钮；
7. 此时在Heap视图中就会看到当前选中的进程的内存使用量的详细情况。
说明：
a) 点击“Cause GC”按钮相当于向虚拟机请求了一次gc操作；
b) 当内存使用信息第一次显示以后，无须再不断的点击“Cause GC”，Heap视图界面会定时刷新，在对应用的不断的操作过程中就可以看到内存使用的变化；
c) 内存使用信息的各项参数根据名称即可知道其意思，在此不再赘述。
如何才能知道我们的程序是否有内存泄漏的可能性呢。这里需要注意一个值：Heap视图中部有一个Type叫做data object，即数据对象，也就是我们的程序中大量存在的类类型的对象。在data object一行中有一列是“Total Size”，其值就是当前进程中所有Java数据对象的内存总量，一般情况下，这个值的大小决定了是否会有内存泄漏。可以这样判断：
a) 不断的操作当前应用，同时注意观察data object的Total Size值；
b) 正常情况下Total Size值都会稳定在一个有限的范围内，也就是说由于程序中的的代码良好，没有造成对象不被垃圾回收的情况，所以说虽然我们不断的操作会不断的生成很多对 象，而在虚拟机不断的进行GC的过程中，这些对象都被回收了，内存占用量会会落到一个稳定的水平；
c) 反之如果代码中存在没有释放对象引用的情况，则data object的Total Size值在每次GC后不会有明显的回落，随着操作次数的增多Total Size的值会越来越大，
直到到达一个上限后导致进程被kill掉。
d) 此处已system_process进程为例，在我的测试环境中system_process进程所占用的内存的data object的Total Size正常情况下会稳定在2.2~2.8之间，而当其值超过3.55后进程就会被kill。
总之，使用DDMS的Heap视图工具可以很方便的确认我们的程序是否存在内存泄漏的可能性。
Android的内存溢出是如何发生的?
Android的虚拟机是基于寄存器的Dalvik，它的最大堆大小一般是16M，有的机器为24M。因此我们所能利用的内存空间是有限的。如果我们的内存占用超过了一定的水平就会出现OutOfMemory的错误。
为什么会出现内存不够用的情况呢？我想原因主要有两个：
由于我们程序的失误，长期保持某些资源（如Context）的引用，造成内存泄露，资源造成得不到释放。
保存了多个耗用内存过大的对象（如Bitmap），造成内存超出限制。
三、万恶的static
static是Java中的一个关键字，当用它来修饰成员变量时，那么该变量就属于该类，而不是该类的实例。所以用static修饰的变量，它的生命周期是很长的，如果用它来引用一些资源耗费过多的实例（Context的情况最多），这时就要谨慎对待了。
public
class ClassName {
private static Context mContext;
//省略
}
以上的代码是很危险的，如果将Activity赋值到么mContext的话。那么即使该Activity已经onDestroy，但是由于仍有对象保存它的引用，因此该Activity依然不会被释放。
我们举Android文档中的一个例子。
private
static Drawable sBackground;
@Override
protected void onCreate(Bundle state) {
super.onCreate(state);
TextView label = new TextView(this);
label.setText("Leaks are
bad");
if (sBackground == null) {
sBackground = getDrawable(R.drawable.large_bitmap);
}
label.setBackgroundDrawable(sBackground);
setContentView(label);
}
sBackground, 是 一个静态的变量，但是我们发现，我们并没有显式的保存Contex的引用，但是，当Drawable与View连接之后，Drawable就将View设 置为一个回调，由于View中是包含Context的引用的，所以，实际上我们依然保存了Context的引用。这个引用链如下：
Drawable->TextView->Context
所以，最终该Context也没有得到释放，发生了内存泄露。
如何才能有效的避免这种引用的发生呢？
第一，应该尽量避免static成员变量引用资源耗费过多的实例，比如Context。
第二、Context尽量使用Application Context，因为Application的Context的生命周期比较长，引用它不会出现内存泄露的问题。
第三、使用WeakReference代替强引用。比如可以使用WeakReference<Context> mContextRef;
该部分的详细内容也可以参考Android文档中Article部分。
四、都是线程惹的祸
线程也是造成内存泄露的一个重要的源头。线程产生内存泄露的主要原因在于线程生命周期的不可控。我们来考虑下面一段代码。
public
class MyActivity extends Activity {
@Override
public void onCreate(Bundle savedInstanceState)
{
super.onCreate(savedInstanceState);
setContentView(R.layout.main);
new MyThread().start();
}
private class MyThread extends Thread{
@Override
public void run() {
super.run();
//do somthing
}
}
}
这段代码很平常也很 简单，是我们经常使用的形式。我们思考一个问题：假设MyThread的run函数是一个很费时的操作，当我们开启该线程后，将设备的横屏变为了竖屏，一 般情况下当屏幕转换时会重新创建Activity，按照我们的想法，老的Activity应该会被销毁才对，然而事实上并非如此。
由于我们的线程是Activity的内部类，所以MyThread中保存了Activity的一个引用，当MyThread的run函数没有结束时，MyThread是不会被销毁的，因此它所引用的老的Activity也不会被销毁，因此就出现了内存泄露的问题。
有些人喜欢用Android提供的AsyncTask，但事实上AsyncTask的问题更加严重，Thread只有在run函数不结束时才出现这种内 存泄露问题，然而AsyncTask内部的实现机制是运用了ThreadPoolExcutor,该类产生的Thread对象的生命周期是不确定的，是应 用程序无法控制的，因此如果AsyncTask作为Activity的内部类，就更容易出现内存泄露的问题。
这种线程导致的内存泄露问题应该如何解决呢？
第一、将线程的内部类，改为静态内部类。
第二、在线程内部采用弱引用保存Context引用。
★Android 还有一些性能优化的方法：
● 首先内存方面，可以参考 Android堆内存也可自己定义大小 和 优化Dalvik虚拟机的堆内存分配
● 基础类型上，因为Java没有实际的指针，在敏感运算方面还是要借助NDK来完成。Android123提示游戏开发者，这点比较有意思的是Google 推出NDK可能是帮助游戏开发人员，比如OpenGL ES的支持有明显的改观，本地代码操作图形界面是很必要的。
● 图形对象优化，这里要说的是Android上的Bitmap对象销毁，可以借助recycle()方法显示让GC回收一个Bitmap对象，通常对一个不用的Bitmap可以使用下面的方式，如
if(bitmapObject.isRecycled()==false) //如果没有回收
bitmapObject.recycle();
● 目前系统对动画支持比较弱智对于常规应用的补间过渡效果可以，但是对于游戏而言一般的美工可能习惯了GIF方式的统一处理，目前Android系统仅能预览GIF的第一帧，可以借助J2ME中通过线程和自己写解析器的方式来读取GIF89格式的资源。
● 对于大多数Android手机没有过多的物理按键可能我们需要想象下了做好手势识别 GestureDetector 和重力感应来实现操控。通常我们还要考虑误操作问题的降噪处理。
Android堆内存也可自己定义大小
对于一些大型Android项目或游戏来说在算法处理上没有问题外，影响性能瓶颈的主要是Android自己内存管理机制问题，目前手机厂商对RAM都比较吝啬，对于软件的流畅性来说RAM对性能的影响十分敏感，除了上次Android开发网提到的优化Dalvik虚拟机的堆内存分配外，我们还可以强制定义自己软件的对内存大小，我们使用Dalvik提供的
dalvik.system.VMRuntime类来设置最小堆内存为例:
private final static int CWJ_HEAP_SIZE = 6* 1024* 1024 ;
VMRuntime.getRuntime().setMinimumHeapSize(CWJ_HEAP_SIZE); //设置最小heap内存为6MB大小。当然对于内存吃紧来说还可以通过手动干涉GC去处理，我们将在下次提到具体应用。
优化Dalvik虚拟机的堆内存分配
对于Android平台来说，其托管层使用的Dalvik JavaVM从目前的表现来看还有很多地方可以优化处理，比如我们在开发一些大型游戏或耗资源的应用中可能考虑手动干涉GC处理，使用
dalvik.system.VMRuntime类提供的setTargetHeapUtilization方法可以增强程序堆内存的处理效率。当然具体原理我们可以参考开源工程，这里我们仅说下使用方法:
private final static floatTARGET_HEAP_UTILIZATION = 0.75f; 在程序onCreate时就可以调用
VMRuntime.getRuntime().setTargetHeapUtilization(TARGET_HEAP_UTILIZATION); 即可。
介绍一下图片占用进程的内存算法吧。
android中处理图片的基础类是Bitmap，顾名思义，就是位图。占用内存的算法如下：
图片的width*height*Config。
如果Config设置为ARGB_8888，那么上面的Config就是4。一张480*320的图片占用的内存就是480*320*4
byte。
前面有人说了一下8M的概念，其实是在默认情况下android进程的内存占用量为16M，因为Bitmap他除了java中持有数据外，底层C++的 skia图形库还会持有一个SKBitmap对象，因此一般图片占用内存推荐大小应该不超过8M。这个可以调整，编译源代码时可以设置参数。
Android的虚拟机是基于寄存器的Dalvik，它的最大堆大小一般是16M。但是Android采用的是Java语言编写，所以在很大程度上，Android的内存机制等同于Java的内存机制，在刚开始开发的时候，内存的限制问题会给我们带来内存溢出等严重问题。在我们不使用一些内存的时候，我们要尽量在Android或者其他平台上避免在运行其他程序时，保存必要的状态，使得一些死进程所带来的内存问题，应该尽量在关闭程序或者保存状态的时候释放掉，这样能提高系统在运行方面的流畅性。
Android的内存主要表现在：
1. 在Android平台上，长期保持一些资源的引用，造成一些内存不能释放，带来的内存泄露问题很多。比如：Context（下文中提到的Activity都是Context），在一些你需要保持你的首个类对象状态，并且把状态传入其他类对象中时，这样消除掉首个类对象之前，你必须先把接收类对象释放掉。需要注意一点的是：因为在Java或者Android内存机制中，顶点的结点释放前必须保证其他对象没有调用才能被系统GC回收释放。我们来看一段代码：
@Override
protected void onCreate(Bundle state) {
super.onCreate(state);
TextViewlabel = new
TextView(this);
label.setText("Leaksare
bad");
setContentView(label);
}
这个代码的意思就是我们把一个TextView的实例加载到了我们正在运行的Activity（Context）当中，因此，通过GC回收机制，我们知道，要释放Context，就必须先释放掉引用他的一些对象。如果没有，那在要释放Context的时候，你会发现会有大量的内存溢出。所以在你不小心的情况下内存溢出是一件非常容易的事情。 保存一些对象时，同时也会造成内存泄露。最简单的比如说位图（Bitmap），比如说：在屏幕旋转时，会破坏当前保持的一个Activity状态，并且重新申请生成新的Activity，直到新的Activity状态被保存。我们再看一段代码：
privatestatic Drawable sBackground;
@Override
protected void onCreate(Bundle state) {
super.onCreate(state);
TextView label = new TextView(this);
label.setText("Leaks are bad");
if (sBackground == null) {
sBackground =getDrawable(R.drawable.large_bitmap);
}
label.setBackgroundDrawable(sBackground);
setContentView(label);
}
这个代码是非常快的同时也是错误的。它的内存泄露很容易出在屏幕转移的方向上。虽然我们会发现没有显示的保存Context这个实例，但是当我们把绘制的图连接到一个视图的时候，Drawable就会将被View设置为回调，这就说明，在上述的代码中，其实在绘制TextView到活动中的时候，我们已经引用到了这个Activity。链接情况可以表现为：Drawable->TextView->Context。
所以在想要释放Context的时候，其实还是保存在内存中，并没有得到释放。
如何避免这种情况：主要在于。线程最容易出错。大家不要小看线程，在Android里面线程最容易造成内存泄露。线程产生内存泄露的主要原因在于线程生命周期的不可控。下面有一段代码：
publicclass MyTest extends Activity {
@Override
publicvoid onCreate(BundlesavedInstanceState)
{
super.onCreate(savedInstanceState);
setContentView(R.layout.main);
new
MyThread().start();
}
privateclass MyThread extends
Thread{
@Override
public void run()
{
super.run();
//do
somthing
}
}
}
代码很简单，但是在Android上又来新问题了，当我们在切换视图屏幕的时候（横竖屏），就会重新建立横屏或者竖屏的Activity。我们形象的认为之前建立的Activity会被回收，但是事实如何呢？Java机制不会给你同样的感受，在我们释放Activity之前，因为run函数没有结束，这样MyThread并没有销毁，因此引用它的Activity（Mytest）也有没有被销毁，因此也带来的内存泄露问题。
有些人喜欢用Android提供的AsyncTask，但事实上AsyncTask的问题更加严重，Thread只有在run函数不结束时才出现这种内存泄露问题，然而AsyncTask内部的实现机制是运用了ThreadPoolExcutor,该类产生的Thread对象的生命周期是不确定的，是应用程序无法控制的，因此如果AsyncTask作为Activity的内部类，就更容易出现内存泄露的问题。
线程问题的改进方式主要有：
l 将线程的内部类，改为静态内部类。
l 在程序中尽量采用弱引用保存Context。
2. 万恶的bitmap。。。
Bitmap是一个很万恶的对象，对于一个内存对象，如果该对象所占内存过大，在超出了系统的内存限制时候，内存泄露问题就很明显了。。
解决bitmap主要是要解决在内存尽量不保存它或者使得采样率变小。在很多场合下，因为我们的图片像素很高，而对于手机屏幕尺寸来说我们并不用那么高像素比例的图片来加载时，我们就可以先把图片的采样率降低在做原来的UI操作。
如果在我们不需要保存bitmap对象的引用时候，我们还可以用软引用来做替换。具体的实例代码google上面也有很多。
综上所述，要避免内存泄露，主要要遵循以下几点：
第一：不要为Context长期保存引用（要引用Context就要使得引用对象和它本身的生命周期保持一致）。
第二：如果要使用到Context，尽量使用ApplicationContext去代替Context，因为ApplicationContext的生命周期较长，引用情况下不会造成内存泄露问题
第三：在你不控制对象的生命周期的情况下避免在你的Activity中使用static变量。尽量使用WeakReference去代替一个static。
第四：垃圾回收器并不保证能准确回收内存，这样在使用自己需要的内容时，主要生命周期和及时释放掉不需要的对象。尽量在Activity的生命周期结束时，在onDestroy中把我们做引用的其他对象做释放，比如：cursor.close()。
其实我们可以在很多方面使用更少的代码去完成程序。比如：我们可以多的使用9patch图片等。有很多细节地方都可以值得我们去发现、挖掘更多的内存问题。我们要是能做到C/C++对于程序的“谁创建，谁释放”原则，那我们对于内存的把握，并不比Java或Android本身的GC机制差，而且更好的控制内存，能使我们的手机运行得更流畅。