「Glide」中的跟踪者
「Glide」源码解析系列
承前启后
RequestBuilder
有了图片资源信息的RequestBuilder和展示图片的目标Target
RequestBuilder对象通过构建者模式构建出了Request对象并绑定到了Target对象上，至此RequestBuilder的使命已经达成了
剩余的工作就交给了跟踪者Tracker，由它控制着Target和Request对象
RequestManager
此节涉及到的类有
TargetTracker
RequestTracker
TargetTracker
TargetTracker
源码不过40+行，总共两个方面：
- 跟踪或取消跟踪Target对象
- 状态变化时通知被跟踪者
说白了就是观察者模式中的观察者，与它直接相连的被观察者是RequestManager，但最终的被观察者是Glide附加在页面上的fragment，只有它才能够响应LifecycleListener。【这里的观察者与被观察者都是相对的；如：相对于fragment来说，RequestManager就是观察者】
这里Glide源码考虑的很周全，由于响应事件的对象是Target，且Target存在生命周期，就会出现发生事件时Target已失效的状况，因此源码用了弱引用。
TargetTracker
如何将传入的Target强引用转为弱引用放入Set，这里起了很好的代码示范作用
这里不是重点捎带着过下集合工具类的源码。
Weak Set
提醒：弱引用在每次GC时会被回收
WeakHashMap
源码大概释义：当key被回收后，value也会被回收
Collections
Set是无序、非重复集合，键值对的Map转换Set也只是收集了key的集合，这也是为什么Map中value的泛型为Boolean
Collections
Set的add、remove操作实际是Map操作默认了value而已。
正由于Set中是弱引用，null对象出现的概率就会很大
TargetTracker
通过快照避免空指针异常
Util
RequestTracker
与TargetTracker的观察者相比，RequestTracker更像是个集合的管理类，控制着Request的变化
RequestTracker添加Request
RequestTracker
pendingRequests这个变量无实际操作意义，但是有存在意义。
因为requests为弱引用集合，稍不留神就被GC了，pendingRequests是为了防止正在运行的request被GC而加的强引用。
RequestTracker
剩余的public方法就是供RequestManager接收回调后调用的
总结
一个附加的Fragment上有一个RequestManager
一个RequestManager上有多个RequestBuilder
一个RequestBuilder上有一个Target
一个Target上有一个Request
一个RequestManager上有多个Target和多个Request
RequestManager接收Fragment回调的生命周期后，通过TargetTracker和RequestTracker分别分发生命周期的回调到各个Target和Request上
一个Glide上有所有的RequestManager
