最近除了那些忙着项目开发的事情,目前正在准备我的论文。短的时间没有写博客,今晚难得想总结。只要有一点时间。因此,为了凑合用,行。唠叨罗嗦,直接进入正题。

从事Android自移动终端的发展,想必是常常要与内存问题打交道的,说到Android开发中遇到的内存问题,像Bitmap这样的吃内存的大户略微处理不当就非常easy造成OOM,当然,眼下已经有非常多知名的开源图片载入框架,比如:ImageLoader。Picasso等等,这些框架已经能够非常好的攻克了Bitmap造成的OOM问题,尽管这些框架能够节省非常多开发人员的宝贵时间。可是也会遇到一种情况。非常多刚開始学习的人仅仅是会简单的去调用这些框架的提供的接口,被问到框架内部的一些实现原理,基本上都是脑中一片空白。从我的观点出发,我觉得假设能够掌握一些框架原理,想必对我们进行应用调优的意义是非常重大的,今天,主要是是想谈谈。假设没有了图片载入框架,我们要怎么去处理Bitmap的内存问题呢?

谈到Bitmap处理的问题,我们可能要先来了解一些基础的知识,关于Bitmap在Android虚拟机中的内存分配,在Google的站点上给出了以下的一段话



大致的意思也就是说。在Android3.0之前,Bitmap的内存分配分为两部分,一部分是分配在Dalvik的VM堆中。而像素数据的内存是分配在Native堆中,而到了Android3.0之后。Bitmap的内存则已经所有分配在VM堆上。这两种分配方式的差别在于,Native堆的内存不受Dalvik虚拟机的管理。我们想要释放Bitmap的内存,必须手动调用Recycle方法。而到了Android 3.0之后的平台,我们就能够将Bitmap的内存全然放心的交给虚拟机管理了,我们仅仅须要保证Bitmap对象遵守虚拟机的GC Root Tracing的回收规则就可以。OK。基础知识科普到此。接下来分几个要点来谈谈怎样优化Bitmap内存问题。

1.Bitmap的引用计数方式(针对Android3.0之前平台的优化方案,先上Demo Code)

private int mCacheRefCount = 0;//缓存引用计数器
private int mDisplayRefCount = 0;//显示引用计数器
...
// 当前Bitmap是否被显示在UI界面上
public void setIsDisplayed(boolean isDisplayed) {
synchronized (this) {
if (isDisplayed) {
mDisplayRefCount++;
mHasBeenDisplayed = true;
} else {
mDisplayRefCount--;
}
} checkState();
} //标记是否被缓存
public void setIsCached(boolean isCached) {
synchronized (this) {
if (isCached) {
mCacheRefCount++;
} else {
mCacheRefCount--;
}
} checkState();
} //用于检測Bitmap是否已经被回收
private synchronized void checkState() {
if (mCacheRefCount <= 0 && mDisplayRefCount <= 0 && mHasBeenDisplayed
&& hasValidBitmap()) {
getBitmap().recycle();
}
} private synchronized boolean hasValidBitmap() {
Bitmap bitmap = getBitmap();
return bitmap != null && !bitmap.isRecycled();
}

上面的实例代码,它使用了引用计数的方法(mDisplayRefCount 与 mCacheRefCount)来追踪一个bitmap眼下是否有被显示或者是在缓存中. 当以下条件满足时回收bitmap:

mDisplayRefCount 与 mCacheRefCount 的引用计数均为 0.

bitmap不为null, 而且它还没有被回收.

2.使用缓存,LruCache和DiskLruCache的结合

关于LruCache和DiskLruCache,大家一定不会陌生(有疑问的朋友能够去API官网搜一下LruCache,而DiskLrucCache能够參考一下这篇不错的文章:DiskLruCache使用介绍),出于对性能和app的考虑,我们肯定是想着第一次从网络中载入到图片之后,能够将图片缓存在内存和sd卡中。这样,我们就不用频繁的去网络中载入图片,为了非常好的控制内存问题,则会考虑使用LruCache作为Bitmap在内存中的存放容器,在sd卡则使用DiskLruCache来统一管理磁盘上的图片缓存。

3.SoftReference和inBitmap參数的结合

在第二点中提及到,能够採用LruCache作为存放Bitmap的容器,而在LruCache中有一个方法值得留意,那就是entryRemoved,依照文档给出的说法,在LruCache容器满了须要淘汰存放当中的对象腾出空间的时候会调用此方法(注意。这里仅仅是对象被淘汰出LruCache容器,但并不意味着对象的内存会马上被Dalvik虚拟机回收掉),此时能够在此方法中将Bitmap使用SoftReference包裹起来,并用事先准备好的一个HashSet容器来存放这些即将被回收的Bitmap。有人会问。这样存放有什么意义?之所以会这样存放,还须要再提及到inBitmap參数(在Android3.0才開始有的,详情查阅API中的BitmapFactory.Options參数信息)。这个參数主要是提供给我们进行复用内存中的Bitmap,假设设置了此參数,且满足以下条件的时候:

  • Bitmap一定要是可变的,即inmutable设置一定为ture;
  • Android4.4以下的平台,须要保证inBitmap和即将要得到decode的Bitmap的尺寸规格一致;
  • Android4.4及其以上的平台,仅仅须要满足inBitmap的尺寸大于要decode得到的Bitmap的尺寸规格就可以;

在满足以上条件的时候。系统对图片进行decoder的时候会检查内存中是否有可复用的Bitmap。避免我们频繁的去SD卡上载入图片而造成系统性能的下降,毕竟从直接从内存中复用要比在SD卡上进行IO操作的效率要提高几十倍。写了太多文字。以下接着给出几段Demo Code

Set<SoftReference<Bitmap>> mReusableBitmaps;
private LruCache<String, BitmapDrawable> mMemoryCache; // 用来盛放被LruCache淘汰出列的Bitmap
if (Utils.hasHoneycomb()) {
mReusableBitmaps =
Collections.synchronizedSet(new HashSet<SoftReference<Bitmap>>());
} mMemoryCache = new LruCache<String, BitmapDrawable>(mCacheParams.memCacheSize) { // 当LruCache淘汰对象的时候被调用,用于在内存中重用Bitmap,提高载入图片的性能
@Override
protected void entryRemoved(boolean evicted, String key,
BitmapDrawable oldValue, BitmapDrawable newValue) { if (RecyclingBitmapDrawable.class.isInstance(oldValue)) { ((RecyclingBitmapDrawable) oldValue).setIsCached(false);
} else { if (Utils.hasHoneycomb()) { mReusableBitmaps.add
(new SoftReference<Bitmap>(oldValue.getBitmap()));
}
}
}
....
} private static void addInBitmapOptions(BitmapFactory.Options options,
ImageCache cache) {
//将inMutable设置true,inBitmap生效的条件之中的一个
options.inMutable = true; if (cache != null) {
// 尝试寻找能够内存中课复用的的Bitmap
Bitmap inBitmap = cache.getBitmapFromReusableSet(options); if (inBitmap != null) { options.inBitmap = inBitmap;
}
}
} // 获取当前能够满足复用条件的Bitmap,存在则返回该Bitmap,不存在则返回null
protected Bitmap getBitmapFromReusableSet(BitmapFactory.Options options) {
Bitmap bitmap = null; if (mReusableBitmaps != null && !mReusableBitmaps.isEmpty()) {
synchronized (mReusableBitmaps) {
final Iterator<SoftReference<Bitmap>> iterator
= mReusableBitmaps.iterator();
Bitmap item; while (iterator.hasNext()) {
item = iterator.next().get(); if (null != item && item.isMutable()) { if (canUseForInBitmap(item, options)) {
bitmap = item;
iterator.remove();
break;
}
} else { iterator.remove();
}
}
}
}
return bitmap;
} //推断是否满足使用inBitmap的条件
static boolean canUseForInBitmap(
Bitmap candidate, BitmapFactory.Options targetOptions) { if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.KITKAT) {
// Android4.4開始,被复用的Bitmap尺寸规格大于等于须要的解码规格就可以满足复用条件
int width = targetOptions.outWidth / targetOptions.inSampleSize;
int height = targetOptions.outHeight / targetOptions.inSampleSize;
int byteCount = width * height * getBytesPerPixel(candidate.getConfig());
return byteCount <= candidate.getAllocationByteCount();
} // Android4.4之前,必须满足被复用的Bitmap和请求的Bitmap尺寸规格一致才干被复用
return candidate.getWidth() == targetOptions.outWidth
&& candidate.getHeight() == targetOptions.outHeight
&& targetOptions.inSampleSize == 1;
}

4.减少採样率,inSampleSize的计算

相信大家对inSampleSize是一定不会陌生的,所以此处不再做过多的介绍,关于减少採样率对inSampleSize的计算方法。我看到网上的算法有非常多。以下的这段算法应该是最好的算法了,当中还考虑了那种宽高相差非常悬殊的图片(比如:全景图)的处理。

public static int calculateInSampleSize(BitmapFactory.Options options,int reqWidth, int reqHeight) {
// Raw height and width of image
final int height = options.outHeight;
final int width = options.outWidth;
int inSampleSize = 1; if (height > reqHeight || width > reqWidth) { final int halfHeight = height / 2;
final int halfWidth = width / 2; while ((halfHeight / inSampleSize) > reqHeight && (halfWidth / inSampleSize) > reqWidth) {
inSampleSize *= 2;
} long totalPixels = width / inSampleSize * height / inSampleSize ; final long totalReqPixelsCap = reqWidth * reqHeight * 2; while (totalPixels > totalReqPixelsCap) {
inSampleSize *= 2;
totalPixels /= 2;
}
}
return inSampleSize;

5.採用decodeFileDescriptor来编码图片(临时不知道原理。欢迎高手指点迷津)

关于採用decodeFileDescriptor去处理图片能够节省内存这方面。我在写代码的时候进行过尝试。确实想比其它的decode方法要节省内存,查询了网上的解释。不是非常清楚,自己看了一些源码也弄不出个名堂,为什么使用这样的方式就能够节省内存一些呢,假设有明确当中原理的高手。欢迎解答我的疑惑

到此,关于Bitmap处理的几个优化点已经分析完成,就眼下来说,可能大家在开发的过程习惯了使用框架来载入图片,所以不大在意图片内存处理的相关问题,假设你想知道一些优化Bitmap内存原理或者想自己做一个优秀的图片载入框架。希望本文能够为你提供一点点思路。假设读者觉得文章有错误,欢迎在下方评论中批评指正。

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

Android性能优化:谈话Bitmap内存管理和优化的更多相关文章

  1. 性能优化-Bitmap内存管理及优化

    Bitmap作为重要Android应用之一,在很多时候如果应用不当,很容易造成内存溢出,那么这篇文章的目的就在于探讨Bitmap的有效运用及其优化 缓存介绍 当多次发送请求的时候,请求同一内容,为了使 ...

  2. 每个Android开发者必须知道的内存管理知识

    原文:每个Android开发者必须知道的内存管理知识 拷贝在此处,以备后续查看. 相信一步步走过来的Android从业者,每个人都会遇到OOM的情况.如何避免和防范OOM的出现,对于每一个程序员来说确 ...

  3. Android 内存管理之优化建议

    OOM(OutOfMemory)转:http://hukai.me/android-performance-oom/ 前面我们提到过使用getMemoryClass()的方法可以得到Dalvik He ...

  4. oracle基础——内存管理、优化

    内存图解: 自动管理:11g:AMM   10g:ASMM SGA(system global area):由所有服务进程和后台进程共享 PGA(program global area): 由每个服务 ...

  5. 【Android手机测试】linux内存管理 -- 一个进程占多少内存?四种计算方法:VSS/RSS/PSS/USS

    在Linux里面,一个进程占用的内存有不同种说法,可以是VSS/RSS/PSS/USS四种形式,这四种形式首字母分别是Virtual/Resident/Proportional/Unique的意思. ...

  6. iOS内存管理和优化 from 刘延军

  7. Android性能优化:手把手带你全面实现内存优化

      前言 在 Android开发中,性能优化策略十分重要 本文主要讲解性能优化中的内存优化,希望你们会喜欢 目录   1. 定义 优化处理 应用程序的内存使用.空间占用 2. 作用 避免因不正确使用内 ...

  8. android 管理Bitmap内存 - 开发文档翻译

    由于本人英文能力实在有限,不足之初敬请谅解 本博客只要没有注明“转”,那么均为原创,转贴请注明本博客链接链接   Managing Bitmap Memory 管理Bitmap内存 In additi ...

  9. Android性能优化--Listview优化

    ListView的工作原理 首先来了解一下ListView的工作原理(可参见http://mobile.51cto.com/abased-410889.htm),如图: ListView 针对每个it ...

随机推荐

  1. Android CTS測试Fail项改动总结(四)

    Android5.1上的測试 1.android.security.cts.SELinuxDomainTest# testInitDomain fail 打印的log junit.framework. ...

  2. git常用命令学习(转)

    一.Bug分支 1,假设如下场景,你正在dev分支工作,突然接到一个修复代号为101的bug的任务时,dev的东西还没不能提交,但是bug需要马上修复. Git提供了一个stash功能,可以把当前工作 ...

  3. 经验36--C#无名(大事,物...)

    有时候,方便代码,它会使用匿名的东西. 1.匿名事件 args.CookieGot += (s, e) =>                 {                     this ...

  4. hdu3480二维斜率优化DP

    Division Time Limit: 10000/5000 MS (Java/Others)    Memory Limit: 999999/400000 K (Java/Others) Tota ...

  5. android控件 下拉刷新pulltorefresh

    外国人写的下拉刷新控件,我把他下载下来放在网盘,有时候訪问不了github 支持各种控件下拉刷新 ListView.ViewPager.WevView.ExpandableListView.GridV ...

  6. HDU 1198 Farm Irrigation (并检查集合 和 dfs两种实现)

    Farm Irrigation Time Limit: 2000/1000 MS (Java/Others)    Memory Limit: 65536/32768 K (Java/Others) ...

  7. 正则获取URL参数

    一 获取指定URL参数 function getUrlParams(name) { var reg = new RegExp("(^|&)" + name + " ...

  8. oracle----sqlldr用法(转)

    SQL*LOADER是ORACLE的数据加载工具,通常用来将操作系统文件迁移到ORACLE数据库中.SQL*LOADER是大型数据仓库选择使用的加载方法,因为它提供了最快速的途径(DIRECT,PAR ...

  9. ABP领域层——实体

    ABP领域层——实体 基于DDD的现代ASP.NET开发框架--ABP系列之10.ABP领域层——实体 ABP是“ASP.NET Boilerplate Project (ASP.NET样板项目)”的 ...

  10. linux runtime pm在深入了解的机制

    一:runtime机构简介 何为runtime机制?也就是系统在非睡眠状态,设备在空暇时能够进入runtime suspend状态同一时候不依赖系统wake_lock机制.非空暇时运行runtime  ...