Android内存管理（续）
浏览数：60 /
时间：2015年06月11日
上篇文章讲解了内存管理中的OOM介绍以及如何的避免内存泄露，本文续写代码优化和图片管理
三、代码优化
1、代码优化
2、回收不可见的界面资源
这个地方我想说得是fragment，fragment销毁只是界面的销毁，他的数据还是会保留在内存中的，当fragment进行切换的时候，前一个fragment的ui会销毁掉，但是数据不会丢失。所以当一个fragment不再需要的时候尽量的把数据也清空。
3、布局优化
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层尽快的释放
郑重声明：本站内容如果来自互联网及其他传播媒体，其版权均属原媒体及文章作者所有。转载目的在于传递更多信息及用于网络分享，并不代表本站赞同其观点和对其真实性负责，也不构成任何其他建议。
