上篇文章讲解了内存管理中的OOM介绍以及如何的避免内存泄露，本文续写代码优化和图片管理

三、代码优化

1、代码优化

2、回收不可见的界面资源

这个地方我想说得是fragment，fragment销毁只是界面的销毁，他的数据还是会保留在内存中的，当fragment进行切换的时候，前一个fragment的ui会销毁掉，但是数据不会丢失。所以当一个fragment不再需要的时候尽量的把数据也清空。

3、布局优化

尽量使用view自身的参数替换多层次的结构

减少没必要的节点 merge

模块化布局 include ，尽量重用一个布局文件，可以减少以后的维护工作

4、复用内存

listview就是个复用典型。

四、图片管理

开发中一大部分oom都是图片问题。 有些情况下，应用所展示的图片数量多并且不在资源文件中，不能像是用资源文件那样获得图片，需要手动decode图片。

1、图片解码

bitmapfactory提供了一系列的decode方法， 直接解码大图片对时间和空间损耗都很大 ，所以在显示大图片的时候先要解码

2、缩略图

这是一种方案，先给一张缩略图，点击后给出原图，能一开始就只加载缩小的bitmap么？ 能够获得合适的缩放比例吗？

3、图片内存缓存和外存缓存

极端占用时间：解码消耗，用户体验

极端占用空间：oom

折中方案：所有图片常驻内存但不超过某个大小（取oom或者vm的1/2）

4、软弱引用

自2.3之后，GC被放入其他线程，会更积极的回收内存，尤其是软引用和弱引用

lruCache:  2.3之后出现，v4包中有，使用方式和map类似，维持key和value，最终使得内存的占用维持在一个固定值

5、图片的释放

heapsize仅仅是描述在虚拟机中占用内存，在3.0之前，bitmap对象还需要占用native层的内存，  这部分内存监视困难且回收时机并不一定，

所以要使用recycle()，之后再也不能用了，目的是告诉c层尽快的释放