android 内存优化

内存泄露:某对象不再使用了（有引用指向他），GC无法回收，该对象占用的内存就无法被使用


java的，内存泄漏和C/C++是不一样
java程序完全结束后，它所有的对象就不可达，就会被GC回收，内存泄漏仅限于它本身，不会影响整个系统
C/C++的内存泄漏是系统级的，即使该C/C++程序退出，它的泄露的内存也无法被系统回收，永远不可用了，除非重启机器


Android的每个应用程序都会使用一个专有的Dalvik虚拟机实例来运行，它是由Zygote服务进程孵化出来的，也就是说每个应用程序都是在属于自己的进程中运行的
当发生内存泄漏会kill掉当前进程，不会影响其他进程


在android的开发中，要时刻注意内存的分配和垃圾回收，因为系统为每一个dalvik虚拟机分配的内存是有限的(最大堆大小16M\24M)


android应用层是由java开发的，android的davlik虚拟机与jvm也类似，只不过它是基于寄存器的。因此要了解android的内存管理就必须得了解java的内存分配和垃圾回收机制。
在java中，是通过new关键字来为对象分配内存的，而内存的释放是由垃圾收集器（GC）来回收的


内存泄露原因：
一.引用没释放造成的内存泄露

1.1注册没取消造成的内存泄露

1.2集合中对象没清理造成的内存泄露

二、资源对象没关闭造成的内存泄露（Cursor，File文件等）

三、一些不良代码成内存压力（没使用的内存没进行有效及时的释放，或是没有有效的利用已有的对象而是频繁的申请新内存）

3.1，Bitmap没调用recycle()

3.2，构造Adapter时，没有使用缓存的 convertView

static是Java中的一个关键字，当用它来修饰成员变量时，那么该变量就属于该类，而不是该类的实例
避免static成员变量引用资源耗费过多的实例，比如Context
Context尽量使用Application Context，因为Application的Context的生命周期比较长，引用它不会出现内存泄露的问题。
使用WeakReference代替强引用。比如可以使用WeakReference<Context> mContextRef;


四、都是线程惹的祸
线程产生内存泄露的主要原因在于线程生命周期的不可控
MyThread中保存了Activity的一个引用，当MyThread的run函数没有结束时，MyThread是不会被销毁的，因此它所引用的老的Activity也不会被销毁，因此就出现了内存泄露的问题
AsyncTask的问题更加严重，Thread只有在run函数不结束时才出现这种内存泄露问题，然而AsyncTask内部的实现机制是运用了ThreadPoolExcutor,该类产生的Thread对象的生命周期是不确定的，是应用程序无法控制的，因此如果AsyncTask作为Activity的内部类，就更容易出现内存泄露的问题


这种线程导致的内存泄露问题应该如何解决呢？
将线程的内部类，改为静态内部类。
在线程内部采用弱引用保存Context引用。


五、超级大胖子Bitmap
如何解决Bitmap带给我们的内存问题？
及时的销毁
设置一定的采样率。

recycle并不能确定立即就会将Bitmap释放掉，但是会给虚拟机一个暗示：“该图片可以释放了”

内存泄漏主要由以下几种情况引起：
1.数据库的cursor没有关闭。
2.构造adapter没有使用缓存contentview。
3.调用registerReceiver后未调用unregisterReceiver()。
4.未关闭InputStream/OutputStream。
5.Bitmap使用后未调用recycle()。
6.Context泄漏。