写这篇文章时候，Jake Wharton 已经从 Square 离职半个月，令人唏嘘不已，追求更广阔的诗和远方想必都是大神们的宿命。当然，开源的价值不会随着你的地位、职业、企业的改变而消失或是贬值，这正是开源的魅力所在。
Picasso 延续了 Jake Wharton 和 Square 开源库的风格，即小而美，且命名诗情画意。从三把刀（ButterKnife、Dagger 1、Scalpel）、Java 诗人（JavaPoet）到西班牙画家毕加索（Picasso），这些库的命名处处体现着技术和人文的结合。这些命名之下，理性的代码们显得感性且有温度。
你将收获
通过本文和 Picasso 源码，你将收获：
- 图片框架的实现套路
- 缓存策略的应用
- 熟悉 HandlerThread 的应用场景
Picasso 总览
简介
Picasso 、Glide、Freso 等是常用的图片加载库，在这三者中，Picasso 的优势是小，不到120K，以下是常用 api ：
// 注：最新的代码中已经可以不用传递 context 参数
Picasso.with(context).load(url).placeholder(R.mipmap.ic_default).into(imageView);
//预加载
Picasso.with(context).load(url).fetch();
//同步加载
Picasso.with(context).load(url).get();
Picasso 源码地址为：https://github.com/square/picasso 。
图片框架的用例
一个图片框架，一般都会包含缓存、图片下载、图片处理（压缩、解码、变换、加载、显示）、统计等四大模块，Picasso 也不例外。
如何阅读 Picasso 源码
Picasso 对图片开始请求加载到显示的每个阶段均做了完整的日志记录，以官方 Demo 为例，启动日志开关后，打开图片详情页：
由于此时为该图片的第一次加载，因此涉及到图片的下载、缓存和显示等不同阶段，日志如下：
Picasso: Main created [R333] Request{http://i.imgur.com/zkaAooq.jpg resize(984,984)}
Picasso: Dispatcher enqueued [R333]+20ms
Picasso: Hunter executing [R333]+20ms
Picasso: Hunter decoded [R333]+28ms
Picasso: Hunter transformed [R333]+36ms
Picasso: Dispatcher batched [R333]+43ms for completion
Picasso: Dispatcher delivered [R333]+260ms
Picasso: Main completed [R333]+260ms from DISK
日志中反应了三个不同的角色，及他们所负责的任务：
- Main：主线程，负责发起图片加载的请求，最终完成加载。
- Dispatcher：分发器，负责将图片加载的请求入队、打包、分发。
- Hunter：工作线程，负责图片的下载、解码、转换。
第一次加载时，没有任何内存和磁盘缓存，第二次加载时，主线程直接从缓存中读取图片即可，日志如下：
Picasso: Main created [R341] Request{http://i.imgur.com/zkaAooq.jpg resize(984,984)}
Picasso: Main completed [R341] from MEMORY
跟随日志阅读 Picaasso 源码，方可事半功倍。
核心类
- Picasso：门面类，提供 Picaaso 单例的创建，预置了默认的现线程池、内存缓存和磁盘缓存策略。
- Request：封装了图片加载请求的信息，如图片的Uri、Resource ID、宽高、scaleType 等。
- RequestCreator：用于创建 Request 对象。
- RequestHandler
- 图片加载请求的处理器，定义了不同类型来源的文件请求如何处理，最终将返回 Source 类型，可以理解为文件字节流。
- 图片来源类型包括：Assets 资源、SD 卡图片、网络图片、联系人照片、其他内容服务提供者、多媒体资源等。因此该抽象类有多个具体的子类。
- 这些子类将以集合的形式，存在于 Picasso 单例中，当 Request 符合 RequestHandler 的处理规则时，便以该 Hander 进行处理。
- 返回的字节流将经过一系列的解码、变换后，变成最终的 Bitmap 对象。
- Dispatcher：分发器，负责分发和处理图片加载的不同阶段，如提交（入队）、取消、暂停、继续、完成、重试、网络状态变化等，并内置了 HandlerThread 来处理大部分无需主线程处理的任务，有了分发器的存在，代码结构更清晰。
- BitmapHunter：图片处理的工作线程，图片的下载、解码、变换等耗时任务均在该线程中执行。
- Action：如果 RequestHandler 是图片加载的开始阶段，Action 则是结束阶段，Action 是抽象类，他决定了图片的最后一个环节：如何将图片渲染在目标容器中（如 ImageView 和 RemoteViews 等），由于目标容器有多种情况，因此也有多个子类。
- Download：图片下载器，内置了实现类 OkHttp3Downloader 和磁盘缓存策略，可自定义实现类进行扩展。
- PicassoExecutorService：内置的线程池，容量定义策略见下文分析。
- Cache：内存缓存接口，内置了缓存策略实现类 LruCache，可自定义实现类进行扩展。
- Transformation：图像的变换接口，如果需要对图片进行范围裁切或几何变换均可实现该接口进行自定义，也可参考 picasso-transformations 。
- Stats：统计图片加载过程中的数据，如缓存命中数、命中率、图片下载大小，经过变换的图片大小等信息。
线程和线程池
Picasso 中的主要线程有四类，分别是：
- 负责下载、解码、转换图片的工作线程——
BitmapHunter，这类线程由线程池PicassoExecutorService进行统一调度。 - 负责分发图片在加载过程中的不同阶段的行为指令（如 submit、cancel、pause、resume、retry 等）——
Dispatcher.dispatcherThread，其类型为HandlerThread。 - 负责统计（如缓存命中数、命中率、缓存大小等）的线程——
Stats.statsThread，其类型为HandlerThread。 - 负责加载图片的线程——主线程。
这是一个 HandlerThread 的典型应用场景，主线程仅负责跟 UI 相关的工作，其他无关的工作均在工作线程或 HandlerThread 中进行处理，如线程之间需要通讯，则通过相应的 Handler 进行通讯，大大减轻了主线程的负担。
Picasso 中的线程池大小会根据网络状态而改变，其规则是 Wifi 状态下，线程池个数为4，4G/3G/2G 状态下分别为3/2/1，这种定义线程池大小的策略可以作为我们有类似应用场景的参考。
缓存
内存和磁盘缓存策略及实现是图片框架必不可少的部分。Picasso 中的两级缓存都采用了 LRU 的缓存策略。
内存缓存
LruCache 为 Picasso 中的缓存实现，该类的主要实现与 Android 默认提供的基本一致，区别有两点：
- 前者重载了构造器，定制了缓存大小的计算，其计算逻辑为：应用所分配内存的 15% ，源码在
Utils.calculateMemoryCacheSize(context)中，缓存大小的申请比例也可以作为有类似应用场景时的参考。 - 抽象出接口
Cache，面向接口编程，如此一来，只要开发者提供实现类，便可扩展缓存策略。
磁盘缓存
当加载网络图片时，我们往往会将图片下载下来，缓存在磁盘中，因此会涉及到磁盘缓存。Picasso 内置了图片下载器 OkHttp3Downloader，本质上是使用自家的 OkHttp 进行图片下载，并内置了缓存策略 DiskLruCache，默认可缓存的文件大小总数为 50M 。值得一提的是，DiskLruCache 也是由 JakeWharton 提供的。
如果需要更换图片下载器和磁盘缓存策略，则可以自定义 Downloader 的实现类进行扩展。
以上所述的线程池、缓存策略等均是面向接口编程，因此都可以扩展，扩展的套路便是在 Picasso.Builder 中设置属性，这种建造者模式的写法我们见惯不怪，源码中的方法声明如下：
public Builder executor(@NonNull ExecutorService executorService){}
public Builder memoryCache(@NonNull Cache memoryCache){}
public Builder downloader(@NonNull Downloader downloader){}
值得注意的细节
Picasso 的所有代码均在一个 package 中，其好处是可以将大部分类和方法的访问权限均设置 default 的，对外隐藏，对内暴露，缺点则是代码分类略显杂乱，但相比优点和其代码量小的特点来说，缺点不值一提。
负责图片加载的
Action持有Target（一般是ImageView）的 WeakReference，当图片加载的生命周期更长时，确保 Target 能被回收而不会造成内存泄露。-
简洁而风格统一的日志设计。
Picasso.setLoggingEnabled(true)的方法可以启动日志打印，上文提到的日志反映出的图片加载的不同阶段均是在工具类Utils中定义的，如下图：
-
图片来源指示器。在开发阶段，我们可以通过
Picasso.setIndicatorsEnabled(true)启动图片指示器，标识图片的来源，这是对开发者非常友好的设计：
-
使用 ContentProvider 提供 Context对象供 Picasso 单例使用，此版本尚未发布，从 master 中可以看到此代码：
相应的，Picasso.with()不需要再传入 Context 对象：
这小技巧可以扩展我们提供 api 的思路，如果不需要特定的 Context，则可以通过 ContentProvider 来提供，方便使用。 该库的单元测试行覆盖率也高达 72% 。
总结
目前而言，虽然 Picasso 并非最主流的图片加载框架，但由于其体型娇小能量巨大，更容易入手阅读，通过它，我们可以了解图片框架的用例、实现套路、缓存策略的思路、复杂线程的处理等，也是非常值得一读的开源库。
参考文章
http://blog.csdn.net/chdjj/article/details/49964901
https://github.com/android-cn/android-open-project-analysis/blob/master/tool-lib/image-cache/picasso/README.md
