从事过移动端应用开发的童鞋应该都清楚,内存是非常宝贵的资源.如果能很好的利用有限的内存,对应用性能的提升会有很大的帮助.在实际应用开发中图片内存占整个应用非常大的比重,我们只有了解图片是如何加载到内存中,才能更好的优化图片所占的内存. 那么对于图片在Android应用中的使用进行探讨一下. 图片所占内存大小=内存中图片高 * 内存中图片宽 * 每个像素所占字节数   1,那么图片的物理高宽和加载到内存中的高宽是否是一样的呢? 在应用中关于图片的加载一般分为两种情况,其加载到内存中的大小也是不一样

1. 对图片本身进行操作 尽量不要使用 setImageBitmap.setImageResource. BitmapFactory.decodeResource 来设置一张大图,因为这些方法在完成 decode 后,最终都是通过 Java 层的 createBitmap 来完成的,需要消耗更多内存.因此,改用先通过 BitmapFactory.decodeStream 方法,创建出一个 bitmap,再将其设为 ImageView 的 source,decodeStream 最大的秘密在于其直

图片对象: drawable bitmap etc.图片对象在Android上该缓存吗?什么时候缓存?怎么缓存?缓存后使用时怎么取出?怎么销毁?什么时候销毁? bitmap对象(new出来的) :需要回收吗? 什么时候回收? 放入view中的bitmap对象需要回收吗? imageview 加载网络图片时,怎样设置加载中及加载失败后的图片? 若事先设置backgroud/src ,当加载网络图片失败后 imageview 为空? if (imgView.getDrawable() == null

在android开发过程中,经常遇到oom的问题,原因有很多种,其中最难处理的是图片造成的oom,于是在网络上对比了几个图片加载的库,最终选择了Facebook的fresco库(github地址:https://github.com/facebook/fresco). fresco对内存的处理做得很好,5.0以前的系统几乎不会出现问题,但是问题会在5.0的某些机型上出现. 解决方案: 1.网络图片使用更合理的取图规则 2.改变图片为webp 3.图片压缩时判断oom的异常 4.manifest文

Picasso 是 Android 上一个强大的图片下载和缓存库. 示例代码: ? 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 Picasso.with(context).load("http://i.imgur.com/DvpvklR.png").into(imageView);   @Override public void getView(int position, View convertView, ViewGroup parent

android 图片占用内存与什么有关 原文链接:http://blog.csdn.net/zjl5211314/article/details/7041813 在开发手机应用的时候,内存是有限的,那使用的时候,就要合理的运用和释放. 那么最占用内存的,估计也是就图片了,有时候,需要在加载一些大量的图片.但是,往往回报内存溢出的错误.看看图片的大小呢,也 不大,也就20KB左右,为什么还是很占内存呢? 原来,将图片转成bitmap 来使用的时候,图片所占的内存,不是它原来的大小,是与 图片的宽度

Android高效内存:让图片占用尽可能少的内存 一.让你的图片最小化 1.1 大图小图内存使用情况对比 大图:440 * 336    小图:220 * 168 小图的高宽都是大图的1/2-->小图是原图的1/4 界面效果: 测试设备:Coolpad   8676-M01   5.1 测试前准备操作:同一款设备,设置图片前后多次调用gc直到内存短时间内保持稳定不再变化 内存使用情况:下图依次是 初始内存,大图内存,小图内存 大图占用内存:11.23 MB - 10.66 MB = 0.57 M

Android高效内存之让你的图片省内存 在做内存优化的时候,我们发现除了解决内存泄露问题,剩下的就只有想办法减少真实的内存占用.而在App中,大部分内存可能被我们图片占用了,所以减少图片的内存占用可以带来直接的效果. 一.一张图片到底占用多少内存 我们先假设我们有一张图片是600 * 800像素的,图片磁盘占用空间大小假设是 100KB. 图片内存大小跟磁盘占用空间大小有什么关系? 磁盘占用空间的大小不是图片占用内存的大小,磁盘占用空间是在磁盘上存储图片需要的一个空间大小,内存大小是加载到内存

Android高效内存:让图片占用尽可能少的内存 一.让你的图片最小化 1.1 大图小图内存使用情况对比 大图:440 * 336    小图:220 * 168 资源目录:xhdpi 小图的高宽都是大图的1/2-->小图是原图的1/4 界面效果: 测试设备:Coolpad   8676-M01   5.1   density=2.0 测试前准备操作:同一款设备,设置图片前后多次调用gc直到内存短时间内保持稳定不再变化 内存使用情况:下图依次是 初始内存,大图内存,小图内存 大图占用内存:11.

网上有很多大拿分享的关于Android性能优化的文章,主要是通过各种工具分析,使用合理的技巧优化APP的体验,提升APP的流畅度,但关于内存优化的文章很少有看到.在Android设备内存动不动就上G的情况下,的确没有必要去太在意APP对Android系统内存的消耗,但在实际工作中我做的是教育类的小学APP,APP中的按钮.背景.动画变换基本上全是图片,在2K屏上(分辨率2048*1536)一张背景图片就会占用内存12M,来回切换几次内存占用就会增涨到上百兆,为了在不影响APP的视觉效果的前提下,

Android中一张图片(BitMap)占用的内存主要和以下几个因数有关:图片长度,图片宽度,单位像素占用的字节数. 一张图片(BitMap)占用的内存=图片长度*图片宽度*单位像素占用的字节数 注:图片长度和图片宽度的单位是像素. 图片(BitMap)占用的内存应该和屏幕密度(Density)无关,虽然我暂时还拿不出直接证据. 创建一个BitMap时,其单位像素占用的字节数由其参数BitmapFactory.Options的inPreferredConfig变量决定. inPreferredC

前言: 上篇我们总结了Bitmap的处理,同时对比了各种处理的效率以及对内存占用大小.我们得知一个应用如果使用大量图片就会导致OOM(out of memory),那该如何处理才能近可能的降低oom发生的概率呢?之前我们一直在使用SoftReference软引用,SoftReference是一种现在已经不再推荐使用的方式,因为从 Android 2.3 (API Level 9)开始,垃圾回收器会更倾向于回收持有软引用或弱引用的对象,这让软引用变得不再可靠,所以今天我们来认识一种新的缓存处理算法

相信做Android开发的小伙伴对于Android图片压缩.裁剪一定有很深的印象,今天我将带领大家一起学习一下这个看着高深莫测的知识,以便再以后的学习.工作中可以帮助到大家. 首先我们看一下这个问题出现的原因,当我们需要在我们的应用中添加大量图片是,程序往往会报出OMM问题,这是什么问题呢?是当我们添加的照片过多或过大时,Android就会报出超内存错误,往往我们遇到这个问题都很无奈,进行图片缓存优化可以帮助我们解决这个问题,但是很多时候我们根本不知道,如何进行内存优化,很明显我就是这样的一位,

前言: 前面学习了Glide的简单使用(Android图片缓存之初识Glide),今天来学习一下Glide稍微复杂一点的使用. 图片缓存相关博客地址: Android图片缓存之Bitmap详解 Android图片缓存之初识Glide Android图片缓存之Glide进阶 Android图片缓存之Lru算法 GlideModule使用: GlideModule 是一个抽象方法,全局改变 Glide 行为的一个方式,通过全局GlideModule 配置Glide,用GlideBuilder设置选项

前言: 前面总结学习了图片的使用以及Lru算法,今天来学习一下比较优秀的图片缓存开源框架.技术本身就要不断的更迭,从最初的自己使用SoftReference实现自己的图片缓存,到后来做电商项目自己的实现方案不能满足项目的需求改用Afinal,由于Afinal不再维护而选择了师出同门的Xutils,中间也接触过别的开源框架比如Picasso,对Picasso的第一次印象就不太好,初次接触是拿到了公司刚从外包公司接手过来的图片社交类app,对内存占用太大,直接感受就是导致ListView滑动有那么一

前言: 最近准备研究一下图片缓存框架,基于这个想法觉得还是先了解有关图片缓存的基础知识,今天重点学习一下Bitmap.BitmapFactory这两个类. 图片缓存相关博客地址: Android图片缓存之Bitmap详解 Android图片缓存之初识Glide Android图片缓存之Glide进阶 Android图片缓存之Lru算法 Bitmap: Bitmap是Android系统中的图像处理的最重要类之一.用它可以获取图像文件信息,进行图像剪切.旋转.缩放等操作,并可以指定格式保存图像文件.

Android的虚拟机是基于寄存器的Dalvik,它的最大堆大小一般是16M.但是Android采用的是Java语言编写,所以在很大程度上,Android的内存机制等同于Java的内存机制,在刚开始开发的时候,内存的限制问题会给我们带来内存溢出等严重问题.在我们不使用一些内存的时候,我们要尽量在Android或者其他平台上避免在运行其他程序时,保存必要的状态,使得一些死进程所带来的内存问题,应该尽量在关闭程序或者保存状态的时候释放掉,这样能提高系统在运行方面的流畅性. Android的内存主要表

一.Picasso https://github.com/square/picasso Picasso是Square公司开源的一个Android平台上的图片加载框架,简单易用,一句话搞定项目中的图片加载,好用到令人发指. 使用一句话:Picasso.with(this).load("url").placeholder(R.mipmap.ic_default).into(imageView); 二.Glide https://github.com/bumptech/glide Glide

今天我们试着来制作一个自己的Android图片浏览器. 图片浏览器应该具有什么功能呢?鉴于不同的人不同的理解,这里提出一个基本的需求: 搜索手机内的所有图片,展示于一个列表中: 列表中展示的是图片的缩略图,点击图片之后,进入图片的大图显示: 在大图显示状态下,可以进行左右滑动,查看其它图片: 在大图显示状态下,我们应该可以查看图片的详细信息: 也许我们还可以支持大图下的放大与缩小? 好了,要求先这么多,我们来实现吧. 第一步:我们要得到手机内的所有图片,展示在一个列表中. android内部为我

前言     这是“基础自测”系列的第三篇文章,以Android开发需要熟悉的20个技术点为切入点,本篇重点讲讲Android中的ImageLoader这个库的一些理解,在Android上最让人头疼是从网络中获取图片,显示,回收,任何一个环节有问题都可能直接OOM,当需要加载大量的图片的时候,每当快速滑,有时候会很卡,甚至会因为内存溢出而崩溃.这里讲解的库是:Universal_Image_Loader. 内容目录 ImageLoader设计原理 ImageLoader流程图 ImageLoad

一. Android的内存机制Android的程序由Java语言编写,所以Android的内存管理与Java的内存管理相似.程序员通过new为对象分配内存,所有对象在java堆内分配空间:然而对象的释放是由垃圾回收器来完成的.那么GC怎么能够确认某一个对象是不是已经被废弃了呢?Java采用了有向图的原理.Java将引用关系考虑为图的有向边,有向边从引用者指向引用对象.线程对象可以作为有向图的起始顶点,该图就是从起始顶点开始的一棵树,根顶点可以到达的对象都是有效对象,GC不会回收这些对象.如果某个