Android内存管理分析

很多开发者都是从j2me或j2ee上过来的，对于内存的使用和理解并不是很到位，Android开发网本次给大家一些架构上的指导，防止出现豆腐渣工程的出现。Android作为以Java语言为主的智能平台对于我们开发一些高性能和质量的软件来说了解Android程序内存管理机制是必须的。 Android的Dalvik VM在基础方面和SUN JVM没有什么大的区别仅仅是字节码的优化，我们要知道什么时候用gc什么时候用recycle以及到底用不用finalization，因为Java对内存的分配只需要new开发者不需要显示的释放内存，但是这样造成的内存泄露问题的几率反而更高。
    1.对于常规开发者而言需要了解 Java的四种引用方式，比如强引用，软引用，弱引用以及虚引用。一些复杂些的程序在长期运行很可能出现类似OutOfMemoryError的异常。
    2.并不要过多的指望gc，不用的对象可以显示的设置为空，比如obj=null，这里提示大家，java的gc使用的是一个有向图，判断一个对象是否有效看的是其他的对象能到达这个对象的顶点，有向图的相对于链表、二叉树来说开销是可想而知。
    3.Android为每个程序分配的对内存可以通过Runtime类的totalMemory() freeMemory() 两个方法获取VM的一些内存信息，对于系统heap内存获取，可以通过Dalvik.VMRuntime类的getMinimumHeapSize() 方法获取最小可用堆内存，同时显示释放软引用可以调用该类的gcSoftReferences() 方法，获取更多的运行内存。
    4.对于多线程的处理，如果并发的线程很多，同时有频繁的创建和释放，可以通过concurrent类的线程池解决线程创建的效率瓶颈。
    5. 不要在循环中创建过多的本地变量。

   很多时候我们需要考虑Android平台上的内存管理问题，Dalvik VM给每个进程都分配了一定量的可用堆内存，当我们处理一些耗费资源的操作时可能会产生OOM错误(OutOfMemoryError)这样的异常，观察了下国内的类似Market客户端设计，基本上都没有采用很好的内存管理机制和缓存处理。

  如果细心的网友可能发现Android Market客户端载入时，每个列表项的图标是异步刷新显示的，但当我们快速的往下滚动到一定数量比如50个，再往回滚动时可能我们看到了部分App的图标又重新开始加载，当然这一过程可能是从SQLite数据库中缓存的，但是在内存中已经通过类似SoftReference的方式管理内存。

  在Java中内存管理，引用分为四大类，强引用HardReference、弱引用WeakReference、软引用SoftReference和虚引用PhantomReference。它们的区别也很明显，HardReference对象是即使虚拟机内存吃紧抛出OOM也不会导致这一引用的对象被回收，而WeakReference等更适合于一些数量不多，但体积稍微庞大的对象，在这四个引用中，它是最容易被垃圾回收的，而我们对于显示类似Android Market中每个应用的App Icon时可以考虑使用SoftReference来解决内存不至于快速回收，同时当内存短缺面临Java VM崩溃抛出OOM前时，软引用将会强制回收内存，最后的虚引用一般没有实际意义，仅仅观察GC的活动状态，对于测试比较实用同时必须和ReferenceQueue一起使用。

  对于一组数据，我们可以通过HashMap的方式来添加一组SoftReference对象来临时保留一些数据，同时对于需要反复通过网络获取的不经常改变的内容，可以通过本地的文件系统或数据库来存储缓存。