一、序
Doodle是我几年前发布的一个图片加载框架。
写Doodle的初衷：早期对包大小之类的还是很看重的，当时觉得Glide依赖包比较大，而我们需要的功能又比较简单，然后Picasso又不支持GIF，于是我就自己写了一个图片加载库。
也由于当时的需求比较简单，所以功能实现得比较保守，比如不支持加载视频缩略图，不支持自定义解码等。
时过境迁，如今大家对包大小已不太在意了，秉着有始有终的想法，我一直想完成一个更完善的版本
其实去年就重构得差不多了，但又想着要丰富一下测试场景，于是补了一些用例，包括网络图片列表加载，以及一个相册组件。
如今终于完成并发布了。
二、简单对比
网上流行的图片加载框架不少，有Universal-Image-Loader，Picasso, Glide, Fresco, Coil等，各有千秋。
- Universal-Image-Loader： 名字取的很直白，最早的图片加载框架，很久之前就停止维护了。
-
Picasso： 最“轻量”， 但功能也最弱，也接近停止维护的状态了。
- 不支持GIF，不支持解码视频缩略图，不支持自定义解码。
- 磁盘缓存完全委托给OkHttp, 只缓存原文件，不缓存解码后的图片到磁盘，相比于Glide, 再次从磁盘加载的要慢得多。
- 有的图片无法正确地降采样，有的图片无法处理图片方向。
- 不支持生命周期（Activity结束时取消加载）。
- Glide： 很全面，基本上挑不出问题。非要吹毛求疵的话，就是代码比较复杂，网上很多源码分析的文章，没几篇捋的清楚。
- Fresco: 解码支持全面，功能强大，除了常规的功能之外，还有渐进式JPEG这种绝活。但代价就是依赖包比较大（Fresso依赖包比较多，我没有一个个去统计，问了ChatGPT, 得到3.5M的回答）。
- Coil: 基于Kotlin实现，依赖AndroidX Lifecycles, OkHttp, Coroutines等，实现了一些对ImageView的扩展函数，语法糖甜度饱和。Coil的Github主页声称库比较“轻量"，并举例其方法数大约2000，“和Picasso相当，远小于Glide/Fresco”。方法数没有虚报，但“和Picasso相当”就比较有水分了, 事实上无论是包大小还是方法都是接近Glide而远多于Picasso。
特别提一下，关于方法数，新入行的朋友可能已经不太听说了。
早期的Android版本运行Dalvik虚拟机，最多支持64K方法，安装包总方法数超过64K需要做适配，可以参考：https://developer.android.com/studio/build/multidex?hl=zh-cn
统计方法数可以用这个插件：https://github.com/KeepSafe/dexcount-gradle-plugin
目前很多APP支持的最低版本都在Android 5.0以上，方法数多少已不重要，但可作为综合衡量代码复杂程度的因素之一吧。
各图片加载框架简要信息如下：
| 版本 | 包大小 | 方法数 | |
|---|---|---|---|
| Picasso | 2.8 | 106k | 527 |
| Glide | 4.15.0 | 809k | 3746 |
| Fresco | 2.6.0 | 3.5M | 5923 |
| Coil | 2.2.2 | 505k | 2000 |
| Doodle | 2.1.0 | 93k | 476 |
Doodle如今发布2.0版本，依然不改初衷，维持了简洁的实现。
Doodle不依赖第三方库，不需要注解和配置混淆，开箱即用。
三、特性
Doodle虽然只有几百个方法，不到百K的大小，但“麻雀虽小，五脏俱全“。
其实现的功能包括但不限于以下列表：
- 支持加载File, Uri, Resource(raw/drawable), assets, http等形式的文件；
- 支持静态图片，动态图片，视频缩略图；
- 支持加载媒体文件缩略图的加速（读取系统的thumbnail)；
- 支持自定义数据加载；
- 支持自定义解码实现；
- 支持加载结果到自定义的View;
- 支持自定义图片变换（内置圆形和圆角剪裁）；
- 支持监听生命周期，并做对应处理（如页面结束时取消加载）；
- 支持暂停/恢复加载；
- 支持磁盘缓存（包括缓存原文件和解码结果）；
- 支持内存缓存（包含LRU缓存和弱引用缓存）；
- 支持占位图，动画；
- 支持降采样/上采样，剪裁……
BitmapFactory本身可以解码JPG, PNG, WEBP, 静态GIF等图片格式，高版本Android还支持HEIF格式。
通过自定义解码，可以实现处理任意格式的文件。
本项目的测试用例中实现了动态GIF, SVG, PAG以及动态WEBP等格式的解码。
Doodle 2.0在功能方面可以说是很接近Glide了；
性能上，我对比了下Doodle和Glide在加载本地媒体文件的速度，基本持平（每次测量结果两者都有浮动，综合来看耗时差不多）。
四、后序
本文并不是要建议大家改用Doodle什么的，相反，在没有十分必要的情况下，不建议变更框架。
所在项目就做过一次从Glide迁移到Fresco，数据劣化，一时半会不好找原因，但项目进度不等人，于是又匆匆回滚到Glide……
已经上线的项目，不建议迁移到Doodle；如果是要开新项目，可以考虑一下。
同时也欢迎各位朋友提PR或者建议。
Github地址： https://github.com/BillyWei01/Doodle
Doodle的用法和实现细节，就不放在这篇文章里了，另外开了两篇做具体讲述。
（二）Doodle - 精简的图片加载框架 - 原理篇
（三）Doodle - 精简的图片加载框架 - 用法篇
