尝试了使用git上的一个开源项目afinal(bitmapfun的封装版)来加载图片，但是在测试的时候发现了一个问题，新的图片加载器(bitmapfun)比之前用的ImageDownloader要慢很多，特别是在网络状况不好的时候，那简直是太让人无语了
在Android应用开发中，高效加载图片是一个至关重要的任务，因为它直接影响到用户体验。在这个问题中，开发者尝试使用了一个基于Git的开源项目Afinal的封装版BitmapFun来加载图片，但遇到了性能问题，尤其是在网络条件较差的情况下，加载速度明显变慢。
Android官方提供了关于“如何更有效地加载图片”的开发指南，该指南详细解释了如何处理大图像，避免内存溢出（OOM）错误，并介绍了内存和磁盘缓存的最佳实践。然而，当项目中采用BitmapFun作为新的图片加载器时，对比先前使用的ImageDownloader，发现其性能下降，特别是在网络不稳定时，加载延迟显著增加。
问题的根源在于BitmapFun的实现中，使用了DiskLruCache作为磁盘缓存。DiskLruCache为了保证日志文件的正确性，采取了全局同步锁，导致在多线程下载图片时，只有一个线程能执行下载操作，严重影响了并发性能。日志文件用于记录每个文件的访问次数，以追踪最长时间未使用的文件，但这导致了大量的I/O操作和同步锁，使得性能降低。
为了解决这个问题，开发者首先尝试将下载方法替换为之前的HTTP客户端实现，但并未根本解决问题。通过比较两种加载器在不同阶段（内存缓存查找、网络加载、存储到内存和SD卡缓存）的耗时，发现BitmapFun的`processBitmap`方法中的下载过程是性能瓶颈，特别是其中的同步锁等待时间过长。
开发者考虑限制同步锁的作用范围，减少对日志文件的I/O操作，以提高并发性能。旧版本的BitmapFun没有使用日志文件，而是直接通过程序访问SD卡缓存来计算访问时间，这种方式可能更有利于性能优化。因此，开发者建议要么使用旧版的DiskLruCache，要么寻找一种既能保证日志准确性又不牺牲性能的解决方案。
对于那些不想自己重写文件锁的开发者，可以考虑将旧版本BitmapFun中的文件缓存部分移植到新版本中。同时，开发者也鼓励社区中的其他开发者分享更好的日志记录方法或优化策略，以提升图片加载效率。
Android应用在加载图片时，必须平衡性能和资源管理，尤其是当涉及磁盘缓存和多线程时。选择合适的缓存策略，优化同步机制，以及减少不必要的I/O操作，都是提高图片加载速度的关键。开发者需要不断探索和改进，以提供最佳的用户体验。
