亲宝软件园·资讯

展开

android bitmapfun 基于android示例程序(bitmapfun) 高效加载图片让人无语地方

人气:0
想了解基于android示例程序(bitmapfun) 高效加载图片让人无语地方的相关内容吗,在本文为您仔细讲解android bitmapfun的相关知识和一些Code实例,欢迎阅读和指正,我们先划重点:android,bitmapfun,下面大家一起来学习吧。

  在android的开发指南上有这样一篇文章,如何更有效率的加载图片,地址为 https://developer.android.com/training/displaying-bitmaps/index.html,这篇文章详细地介绍了如何加载高清图到内存,同时避免系统报OOM的问题,文章写得很不错,示例程序也可以直接运行。在我们项目的一次小版本升级的过程中,我们尝试了使用git上的一个开源项目afinal(bitmapfun的封装版)来加载图片,但是在测试的时候发现了一个问题,新的图片加载器(bitmapfun)比之前用的ImageDownloader要慢很多,特别是在网络状况不好的时候,那简直是坑爹,等5s钟算少的,一般要等10s左右,老大找到我,说这个图片加载不出来啊,太慢了。我靠,不是吧,这玩笑开的有点大了吧,拿来一用,果然是慢很多。

  然后开始了调试工作,开始我在想是不是网络下载部分不一样,之前用的是httpclient,现在bitmapfun用的是url.openConnection,果断替换成之前的httpclient方法,感觉有所好转(其实是自己心理在作怪),再试试,发现有时快,有时慢,对比之前的,之前的图片一直很稳定,不会出现这种情况啊,然后想了个办法,在项目中的找了两个页面,一个用之前的ImageDownload加载,另一个用bitmapfun加载,然后把各个时段(可以分为3段吧,1是从内存缓存中查找、2是从网络加载、3是存到内在缓存和sdcard缓存)的时间打印出来对比,发现确实是bitmapfun下载这块(processBitmap方法)里面最耗时间,这部分的代码,看到同步锁,应该是他吧,咋一看,没问题啊,只锁住一小块,应该是防止缓存没被初始化的吧,过。。。再往下看,频繁的对sdcard进行io操作,恩对,应该是这里,把刚才的方法重复一下,分段打印耗时,一看结果,tnnd,占用时间最长的居然是wait操作,也就是那个锁的等待,再去看下代码,双击下锁的范围,发现基本是对整个下载过程进行了同步锁定,这尼玛,太坑爹了吧,一个图片在下载的时候,其他的都得在那等着,那前面新建的3个核心线程,被你同步成一个,我说怎么看到这个加载图片这么整齐,一个个出现。

  发现了问题,问下为什么,他这么做的原因是什么,其实就是为了那个DiskLruCache的日志文件,不允许多个线程同时操作,否则日志会错乱,就没办法统计哪个文件是最久未被使用的。自己想试着改下锁的范围,发现有点困难,因为下载过程中对日志文件操作的太频繁了,哪位大牛有好的方法告诉下我,不胜感激。

  对使用bitmapfun或者afinal的一点建议,DiskLruCache慢的关键在于对日志文件(目录下journal文件)的要求太高了,日志文件的作用就是记录每一个文件的访问次数,所以它每一次读取和写入都要写入日志记文件,这样是可以更准确的统计出最久未被使用的文件,但是代价太高了(频繁的io操作和同步锁),记得上个版本的bitmapfun是不用日志文件的,直接从程序访问sdcard缓存开始计算访问时间,其实这样更合适一些,对性能更好。所以如果使用这个示例程序来加载图片,最好的方式就是使用上个版本的DiskLruCache或者自己想办法来实现日志文件的记录,有更好的方法包括日志文件的记录方法,记得告诉我哦!

附:老版本的bitmapfun,不想自己重写文件锁的同学可以把这里面的文件缓存移植进去。点击文件下载

加载全部内容

相关教程
猜你喜欢
用户评论