android应用内存管理终极解决之道

       不容易呀，第一次花了4个小时写一篇原创的技术文章。呵呵，本人文采和编码技术有限，是否写清楚了，也不知道是否对各位麻油有用，不管怎么着，作为自己的技术积累，还是得写出来，以供自己以后回忆，顺便为论坛为码友做点共享。

       这篇文章是我在实际项目中使用的已被证实非常有效的一套内存管理机制。为了表现一下程序猿的应该有的共享精神，就此分享一下。

 在android应用的中，造成内存泄漏的一般情况下最大的罪魁祸首自然非图片莫属了，如果其他普通的对象造成内存泄漏，那毋庸置疑，你的代码肯定出大的问题。

         要解决内存问题，很多从J2EE/J2ME过来的人都认为用软引用弱引用即可，可是事实是：在占内存很大的bitmap对象面前，软引用弱引用显得力不从心。还有些人在用一种android最新的内存管理算法--称为LRU的东西，我的一些朋友就在用，听他们说貌似很不错，基本能解决绝大多数图片内存问题，但是貌似在一些比较极端情况下还是会内存溢出，比如说，页面图片很多，每张图片又比较大，此时如果快速滑动浏览图片，内存崩溃的几率还是很高的。至于其他的还有什么更高效的内存回收，小菜我也就不知道了。但是现在我想写写自己的经过实战总结出来的有效的内存回收办法，那么废话不多说，咱就来说道说道。
    
        要说我们的这套内存管理方法，就不得不说我们的这个项目架构背景了，由于我们采用单Acitivity的方式，所以所有的大页面（这里大页面就相当于传统多Acitivity方式中单个的全屏Acitivity）都是用ViewGroup或者其子类--这里我把大页面称为ViewPage，每个ViewPage包含一个或者多个独立的自定义View或者ViewGroup(或者其子类)--这些独立的View或者ViewGroup我称之为ViewChild。这样的UI，是不是很像Fragment呢？没错，这个完全可以用Fragment方式弄。出于效率的考虑，我们把应用要用到的所有ViewPage和ViewChild在应用启动的时候就实例化出来了，这就碰到一个非常棘手的问题，由于这些ViewPage和ViewChild当中要用很多携带背景或者SRC图片的系统控件，所以应用刚启动，内存就飙到了30M左右，天哪，这可得了？     //注：看到这样的UI架构，很多人要骂了吧？呵呵，不但你们要骂，我更是在现实中跟架构师，也是我们的技术总监，天天吵架！因为这脑残的架构就是他的杰作。简直无法直视，但还是得解决啊!怎么办...??? 

    在这样的背景下，对付内存的办法,可以说无所不用其极了，不夸张的说我们这套管理内存的机制，已经到达了登峰造极的地步。各种逻辑处理，算法处理，能用的内存处理API都基本用上了。下面，各位观众，干货要来了！

    首先，“精准即时”回收图片。  说道“精准即时”，什么是精准，什么是即时？我们知道，使用java的软引用弱引用，既不能做到精准，更不能做到即时；这是由java的GC机制决定的，这个大家都知道，我不多说。精准，就是准确回收想要回收的某些图片；即时，就是想回收时，立即就回收之，而不是像java GC机制那样，回收的对象，回收的时机都是不确定的。下面就说说，怎么做到精准即时。
	如何做到精准即时？