一、序

Doodle是我几年前发布的一个图片加载结构。
写这个库的初衷：早期对包大小之类的仍是很看重的，其时觉得Glide依靠包比较大，而咱们需要的功用比较简单，然后Picasso又不支撑GIF，所以我就自己写了一个图片加载库。
也由于其时的需求比较简单，所以功用完成得比较保守，比如不支撑加载视频缩略图，不支撑自定义解码等。
时过境迁，现在我们对包大小已不太在意了，但我仍然想完结一个更完善的版别。
其实去年就重构得差不多了，不过想要丰富一下测试场景，所以补了一些用例，包括网络图片列表加载，以及一个相册组件。
现在终于完结并发布了。

二、简单对比

网上流行的图片加载结构不少，有Universal-Image-Loader，Picasso, Glide, Fresco, Coil等，各有长短。

• Universal-Image-Loader：名字取的很直白，最早的图片加载结构，很久之前就中止保护了。
• Picasso：很轻量，但短板也很明显，也挨近中止保护的状态了。
  1. 不支撑GIF，不支撑解码视频缩略图，不支撑自定义解码。
  2. 磁盘缓存完全托付给OkHttp, 只缓存原文件，不缓存解码后的图片到磁盘，相比于Glide, 再次从磁盘加载的要慢得多。
  3. 有的图片无法正确地降采样，有的图片无法处理图片方向。
  4. 不支撑生命周期（Activity结束时取消加载）。
• Glide： 很全面，根本上挑不出问题。非要吹毛求疵的话，就是代码比较复杂，网上很多源码剖析的文章，没几篇捋的清楚。
• Fresco: 解码支撑全面，功用强大，除了常规的功用之外，还有渐进式JPEG这种绝活。
  但价值就是依靠包比较大（Fresso依靠包比较多，我没有一个个去计算，问了ChatGPT, 得到3.5M的答复）。
• Coil: 基于Kotlin完成，依靠AndroidX Lifecycles, OkHttp, Coroutines等，完成了一些对ImageView的扩展函数，语法糖甜度饱满。
  Coil的Github主页声称库比较轻量，并举例其方法数大约2000，“和Picasso适当，远小于Glide/Fresco”。
  方法数没有虚报，但“和Picasso适当”就比较有水分了, 事实上无论是包大小仍是方法都是挨近Glide而远多于Picasso。

关于方法数,计算方法数可以用这个插件：github.com/KeepSafe/de… 。

各图片加载结构扼要信息如下：

Doodle现在发布2.0版别，仍然不改初衷，维持了简练的完成。
Doodle不依靠第三方库，不需要注解，不需要装备反混杂，开箱即用。

三、特性

Doodle尽管依靠包很轻，但“麻雀虽小，五脏俱全“。
其完成的功用包括但不限于以下列表：

• 支撑加载File, Uri, Resource(raw/drawable), assets, http等方式的文件；
• 支撑静态图片，动态图片，视频缩略图；
• 支撑加载媒体文件缩略图的加速（读取系统的thumbnail)；
• 支撑自定义数据加载；
• 支撑自定义解码（比如经过注入解码器完成SVG, GIF等格式的支撑）；
• 支撑加载成果到自定义的View;
• 支撑自定义图片改换（内置圆形和圆角取舍）；
• 支撑监听生命周期，并做对应处理（如页面结束时取消加载）；
• 支撑暂停/康复加载；
• 支撑磁盘缓存（包括缓存原文件和解码成果）；
• 支撑内存缓存（包括LRU缓存和弱引证缓存）；
• 支撑占位图，动画；
• 支撑降采样/上采样，取舍；

Doodle以不到100K的依靠包大小，完成了挨近于Glide的功用。
性能上，我对比了下Doodle和Glide在加载本地媒体文件的速度，根本持平（每次测量成果两者都有起浮，综合来看耗时差不多）。

四、后序

Doodle的用法和完成细节，就不放在这篇文章里了，另外开了两篇做具体讲述。
（二）Doodle – 精简的图片加载结构 – 原理篇
（三）Doodle – 精简的图片加载结构 – 用法篇

原理篇是在之前的发布的文章上修改的，原文名为《怎么完成一个图片加载结构》。
尽管讲的不是干流的图片加载库，但图片加载相关的要点其实是相通的，读完原理篇关于剖析其他图片加载库也是有所帮助的。

项目已经发布Github, 欢迎各位朋友提PR或者建议。
地址：github.com/BillyWei01/…