「Glide」中的跟踪者

「Glide」源码解析系列

  • 「Glide」一切的开始
  • 「Glide」目标的确定
  • 「Glide」中的跟踪者
  • 「Glide」请求的生成
  • 「Glide」请求的开始
  • 「Glide」中的Engine
  • 「Glide」中的Job

承前启后

「Glide」中的跟踪者_第1张图片
RequestBuilder

有了图片资源信息的RequestBuilder和展示图片的目标Target

RequestBuilder对象通过构建者模式构建出了Request对象并绑定到了Target对象上,至此RequestBuilder的使命已经达成了

剩余的工作就交给了跟踪者Tracker,由它控制着Target和Request对象

RequestManager

此节涉及到的类有
TargetTracker
RequestTracker

TargetTracker

「Glide」中的跟踪者_第2张图片
TargetTracker

源码不过40+行,总共两个方面:

  • 跟踪或取消跟踪Target对象
  • 状态变化时通知被跟踪者

说白了就是观察者模式中的观察者,与它直接相连的被观察者是RequestManager,但最终的被观察者是Glide附加在页面上的fragment,只有它才能够响应LifecycleListener。【这里的观察者与被观察者都是相对的;如:相对于fragment来说,RequestManager就是观察者】

这里Glide源码考虑的很周全,由于响应事件的对象是Target,且Target存在生命周期,就会出现发生事件时Target已失效的状况,因此源码用了弱引用。

TargetTracker

如何将传入的Target强引用转为弱引用放入Set,这里起了很好的代码示范作用

这里不是重点捎带着过下集合工具类的源码。

Weak Set

提醒:弱引用在每次GC时会被回收

「Glide」中的跟踪者_第3张图片
WeakHashMap

源码大概释义:当key被回收后,value也会被回收

Collections

Set是无序、非重复集合,键值对的Map转换Set也只是收集了key的集合,这也是为什么Map中value的泛型为Boolean

「Glide」中的跟踪者_第4张图片
Collections

Set的add、remove操作实际是Map操作默认了value而已。

正由于Set中是弱引用,null对象出现的概率就会很大

TargetTracker

通过快照避免空指针异常

「Glide」中的跟踪者_第5张图片
Util

RequestTracker

与TargetTracker的观察者相比,RequestTracker更像是个集合的管理类,控制着Request的变化

「Glide」中的跟踪者_第6张图片
RequestTracker添加Request
RequestTracker

pendingRequests这个变量无实际操作意义,但是有存在意义。

因为requests为弱引用集合,稍不留神就被GC了,pendingRequests是为了防止正在运行的request被GC而加的强引用。

「Glide」中的跟踪者_第7张图片
RequestTracker

剩余的public方法就是供RequestManager接收回调后调用的

总结

一个附加的Fragment上有一个RequestManager

一个RequestManager上有多个RequestBuilder

一个RequestBuilder上有一个Target

一个Target上有一个Request

一个RequestManager上有多个Target和多个Request

RequestManager接收Fragment回调的生命周期后,通过TargetTracker和RequestTracker分别分发生命周期的回调到各个Target和Request上

一个Glide上有所有的RequestManager

你可能感兴趣的:(「Glide」中的跟踪者)