「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也会被回收
CollectionsSet是无序、非重复集合,键值对的Map转换Set也只是收集了key的集合,这也是为什么Map中value的泛型为Boolean
CollectionsSet的add、remove操作实际是Map操作默认了value而已。
正由于Set中是弱引用,null对象出现的概率就会很大
TargetTracker通过快照避免空指针异常
UtilRequestTracker
与TargetTracker的观察者相比,RequestTracker更像是个集合的管理类,控制着Request的变化
RequestTracker添加Request RequestTrackerpendingRequests这个变量无实际操作意义,但是有存在意义。
因为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
网友评论