android 内存优化

OOM

      内存泄漏引起很多问题:

     1:节目卡顿。反应慢(高内存使用情况JVM 虚拟机的频繁离职GC)

     2:消失

     3:直接崩溃


ANDROID 内存面临的问题

  1: 有限的堆内存,原始仅仅有16M

  2:内存大小消耗等依据设备。操作系统等级。尺寸的不同而不同

  3:程序不能直接控制

  4:支持后台多任务处理

  5:执行在虚拟机之上


5R 

1.Reckon(计算)

首先须要知道你的app所消耗内存的情况,知己知彼才干百战不殆

2.Reduce(降低)

消耗更少的资源

3.Reuse(重用)

当第一次使用完以后,尽量给其它的使用

5.Recycle(回收)

回收资源

4.Review(检查)

回想检查你的程序。看看设计或代码有什么不合理的地方。


1.Reckon(计算)

首先须要知道你的app所消耗内存的情况,知己知彼才干百战不殆

2.Reduce(降低)

消耗更少的资源

3.Reuse(重用)

当第一次使用完以后。尽量给其它的使用

5.Recycle(回收)

回收资源

4.Review(检查)

回想检查你的程序,看看设计或代码有什么不合理的地方。


Reduce :


reduce 意思就是降低。直接降低内存的使用。是最有效的优化方法

Bitmap:

Bitmap 是内存消耗大户,绝大多数的OOM崩溃都是在操作Bitmap 时产生的以下看看几个处理图片的方法

图片显示:

 我们须要依据需求去载入图片大小

 比如在列表中仅用于预览时载入缩略图

 仅仅有当用户点击具体条目想看具体信息的时候。这时另启动一个fragement /activity 对话框等等。去显示整个图片



1.Reckon(计算)

首先须要知道你的app所消耗内存的情况,知己知彼才干百战不殆

2.Reduce(降低)

消耗更少的资源

3.Reuse(重用)

当第一次使用完以后,尽量给其它的使用

5.Recycle(回收)

回收资源

4.Review(检查)

回想检查你的程序,看看设计或代码有什么不合理的地方。


图片大小:

直接使用ImageView显示bitmap会占用较多资源,特别是图片较大的时候,可能导致崩溃。

 
使用BitmapFactory.Options设置inSampleSize, 这样做能够降低对系统资源的要求。 
属性值inSampleSize表示缩略图大小为原始图片大小的几分之中的一个,即假设这个值为2。则取出的缩略图的宽和高都是原始图片的1/2,图片大小就为原始大小的1/4。 


1.Reckon(计算)

首先须要知道你的app所消耗内存的情况,知己知彼才干百战不殆

2.Reduce(降低)

消耗更少的资源

3.Reuse(重用)

当第一次使用完以后,尽量给其它的使用

5.Recycle(回收)

回收资源

4.Review(检查)

回想检查你的程序。看看设计或代码有什么不合理的地方。


图片像素:

Android中图片有四种属性。各自是:
ALPHA_8:每一个像素占用1byte内存 
ARGB_4444:每一个像素占用2byte内存 
ARGB_8888:每一个像素占用4byte内存 (默认)
RGB_565:每一个像素占用2byte内存 

1.Reckon(计算)

首先须要知道你的app所消耗内存的情况,知己知彼才干百战不殆

2.Reduce(降低)

消耗更少的资源

3.Reuse(重用)

当第一次使用完以后,尽量给其它的使用

5.Recycle(回收)

回收资源

4.Review(检查)

回想检查你的程序,看看设计或代码有什么不合理的地方。


图片回收:

使用Bitmap过后,就须要及时的调用Bitmap.recycle()方法来释放Bitmap占用的内存空间,而不要等Android系统来进行释放。

以下是释放Bitmap的演示样例代码片段。

  1. // 先推断是否已经回收  
  2. if(bitmap != null && !bitmap.isRecycled()){  
  3.     // 回收而且置为null  
  4.     bitmap.recycle();  
  5.     bitmap = null;  
  6. }  
  7. System.gc()

1.Reckon(计算)

首先须要知道你的app所消耗内存的情况,知己知彼才干百战不殆

2.Reduce(降低)

消耗更少的资源

3.Reuse(重用)

当第一次使用完以后,尽量给其它的使用

5.Recycle(回收)

回收资源

4.Review(检查)

回想检查你的程序,看看设计或代码有什么不合理的地方。


究竟什么时候使用软引用,什么时候使用弱引用呢?

个人觉得。假设仅仅是想避免OutOfMemory异常的发生。则能够使用软引用。假设对于应用的性能更在意,想尽快回收一些占用内存比較大的对象,则能够使用弱引用。

还有就是能够依据对象是否常常使用来推断。假设该对象可能会常常使用的,就尽量用软引用。假设该对象不被使用的可能性更大些,就能够用弱引用。

另外,和弱引用功能类似的是WeakHashMap。WeakHashMap对于一个给定的键。其映射的存在并不阻止垃圾回收器对该键的回收。回收以后,其条目从映射中有效地移除。

WeakHashMap使用ReferenceQueue实现的这样的机制。


1.Reckon(计算)

首先须要知道你的app所消耗内存的情况。知己知彼才干百战不殆

2.Reduce(降低)

消耗更少的资源

3.Reuse(重用)

当第一次使用完以后,尽量给其它的使用

5.Recycle(回收)

回收资源

4.Review(检查)

回想检查你的程序。看看设计或代码有什么不合理的地方。


http://blog.csdn.net/a396901990/article/details/38707007

1.Reckon(计算)

首先须要知道你的app所消耗内存的情况,知己知彼才干百战不殆

2.Reduce(降低)

消耗更少的资源

3.Reuse(重用)

当第一次使用完以后,尽量给其它的使用

5.Recycle(回收)

回收资源

4.Review(检查)

回想检查你的程序。看看设计或什么是不合理的代码。

版权声明:本文博主原创文章,博客,未经同意不得转载。

posted @ 2015-09-19 09:41  hrhguanli  阅读(236)  评论(0编辑  收藏  举报