Android内存泄露的原因
（一）释放对象的引用，误将一个本来生命周期短的对象存放到一个生命周期相对较长的对象中，也称“对象游离“。隐蔽的内部类（Anonymous Inner Class）：
mHandler = new Handler() {
@Override
public void handleMessage(Message msg) {
....
}
};
相当于：
class MyHandler implements Handler {
....
}
mHandler = new MyHandler();
类似的还有Listener，Observer，Receiver等。
由于内部类隐含拥有一个外部类对象的引用，所以千万要注意内部类instance的声明周期。
最好不要将一个内部类的instance暴漏出去，除非使用者采用weak reference引用内部类的instance。例如，一些Handler，Listener在做为返回值暴漏出去时，千万注意使用weak reference。
注意：一些系统提供的类偷偷地将自己暴漏出去了，如FileObserver，会将自己暴漏到自己内部开的线程去，不过还好它使用的是weak reference。但是过分的是BroadcastReceiver，一旦我们使用Context的registerReceiver 之后，系统（ ActivityManagerNative ）就会有一个它的强引用，除非我们显式调用unregisterReceiver。
结论：任何提供了开关函数的类，都必须保证显式地调用它们的开关函数。
（二） 构造Adapter时，没有使用缓存的 convertView，从而造成系统创建了大量的view而没有来得及回收。
public View getView(int position, View convertView, ViewGroup parent)
（三）对于资源性对象在不使用的时候，应该调用它的close()函数，将其关闭掉，然后才置为null。资源性对象，比如（Cursor等）往往都用了一些缓冲，我们在不使用的时候，应该及时关闭它们，以便它们的缓冲及时回收内存。它们的缓冲不仅存在于java虚拟机内，还存在于java虚拟机外。如果我们仅仅是把它的引用设置为null，而不关闭它们，往往会造成内存泄露。
（四）都是线程惹的祸
由于线程的执行时间是未知的，所以线程所持有的外部对象，一般要使用weak reference，除非你肯定它们的生命周期。
另外，向其它线程post Runnable或者send Message时也需要注意Runnalbe内部使用的变量和Message中的内容。
（五）AsyncTask-隐藏的故事
Asynctask使用了一个静态的ThreadPoolExecutor，有三个参数是系统固定的：
CORE_POOL_SIZE：5
MAXIMUM_POOL_SIZE：128
QUEUE_CAPACITY: 10
当一个AsyncTask被execute之后：
1.如果线程池中线程数目小于CORE_POOL_SIZE ，就直接开线程；
2.如果队列不满，就被加入队列中；
3.如果队列已满，就直接开线程执行；
4.如果线程池中线程数目大于MAXIMUM_POOL_SIZE，就会Exception。
Tricky的地方在于AsncTask的Cancel操作。
1.不一定都能成功，例如while（true）{}就无法被cancel；
2.如果AsyncTask还在Queue中，那么cancel操作并不会将它从Queue中remove，而仅仅是设置了flag，最终当它被thread执行时，判断该flag，如果false，就不会执行doBackground的代码。
悲剧剧情：你在队列中，正在执行的几个哥们都block了，你就一直呆着吧。
（六）Bitmap-不得不说的故事
Bitmaps in Android are created innative memory, not on the VM heap, so the actual Bitmap object on the VM heapis very small as it doesn't contain any actual bitmap data.
一般情况下，我们都是按需索图，没必要把原始图片都搞进来，所以我们可以先查询原始图片大小，在做scale：
1. 查询原始图片大小，通过BitmapFactory.Options中的属性inJustDecodeBounds来做，If set to true, the decoder will return null (nobitmap), but the out... fields will still be set, allowing the caller to querythe bitmap without having to llocate the memory for its pixels.
2. 然后计算出一个scale的值，通过BitmapFactory.Options中的属性inSampleSize进行缩放。
Bitmap bitmap;
float imagew = 300; // 目标大小
float imageh = 300; // 目标大小
BitmapFactory.Options bitmapFactoryOptions = new BitmapFactory.Options();
bitmapFactoryOptions.inJustDecodeBounds = true;
bitmap = BitmapFactory.decodeFile(imageFile, bitmapFactoryOptions);
int yRatio = (int)Math.ceil(bitmapFactoryOptions.outHeight/imageh);
int xRatio = (int)Math.ceil(bitmapFactoryOptions.outWidth/imagew);
if (yRatio > 1 || xRatio > 1){
if (yRatio > xRatio) {
bitmapFactoryOptions.inSampleSize = yRatio;
} else {
bitmapFactoryOptions.inSampleSize = xRatio;
}
} else{
// inSampleSize = 1
}
bitmapFactoryOptions.inJustDecodeBounds = false;
bitmap = BitmapFactory.decodeFile(imageFile, bitmapFactoryOptions);
myImageView.setImageBitmap(bitmap);
Bitmap-recycle有用吗？以下是官方源代码的注释：
Free the native object associated with this bitmap, and clearthe reference to the pixel data.
This will not free the pixel data synchronously;
it simply allows it to be garbagecollected if there are no other references. The bitmap is marked as "dead", meaning it willthrow an exception ifgetPixels() or setPixels() is called, and will draw nothing. This operation cannot be reversed, so it should only becalled 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 processwill free up this memory when there are no more references to this bitmap.
（七）substring的恶梦
public String substring(int beginIndex, int endIndex) {
return new String(offset + beginIndex,
endIndex - beginIndex,
value);
}
String(int offset, int count, char value[]) {
this.value = value;
this.offset = offset;
this.count = count;
}
也就是说即使你只想用其中的某几个字节，Java也自动把原始String的整个内容帮你保存下来了。
ArrayList<String> oomStringList = new ArrayList<String>(1024);
for (int i=0; i<32*1024; i++) {
String srcString = new String(new char[1024]);
String dstString = srcString.substring(0,1);
oomStringList .add(dstString);
}
refrence：http://blog.csdn.net/edisonlg/article/details/7082063
