android中bitmapfun高效加载图片到底有多坑爹

　　在android的开发指南上有这样一篇文章，如何更有效率的加载图片，这篇文章详细地介绍了如何加载高清图到内存，同时避免系统报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或者自己想办法来实现日志文件的记录，有更好的方法包括日志文件的记录方法，记得告诉我哦!

　　以上就是爱站技术频道小编为大家整理的基于android示例程序(bitmapfun) 高效加载图片让人无语地方，相信无论是谁遇到这样的问题都会忍不住骂人了吧。