网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。
一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！
通过原型模式，我们可以根据一个现有对象创建出新的对象，并且可以灵活地修改新对象的属性，而不会影响原始对象。这样可以避免重复创建相似的对象，提高性能和代码复用性。克隆细分又分深拷贝和浅拷贝。听君一席话，如听一席话，我们看下Glide怎么做的。
Glide 哪里用到了原型模式呢？ 在构建请求对象的请求参数就用到了，如下。
为什么要用clone，对应什么场景？其实就这个问题我也思考良久，让我们自己写图片加载框架估计就直接new 请求参数，然后把请求参数都塞进去，又不是不能用，这样确实是能用并且一点问题都没有。但是作为一个有梦想的程序员肯定是代码能优化地方就要优化的。例如下面这个场景
把一张图片加载到多个imageView 上面去，这种需求还是很常见的。这种情况下请求参数大部分信息都是可以共用的，就imageView不一样而已，我clone 一个出来复用大部分相同的请求参数信息，性能和内存不都优化了？何乐而不为，然后不同的部分 deep copy一下就行了。
行为型设计模式
观察者设计模式
glide 通过添加透明Fragment来监听activity /framgent 生命周期，这里提一下Glide为什么在子线程使用不会去监听生命周期，因为可能会导致内存泄露。在生命周期onDestroy 清理加载请求、onStop加载暂停、onStart恢复图片加载请求，用到了观察者设计模式。与之相关两个接口定义如下
LifecycleListener 是抽象观察者，方法有onStart/Stop/Destory，Lifecycle是抽象被观察者，方法有add/removeListener。RequestManager 作为具体观察者，实现了LifecycleListener。除了RequestManager实现了观察者接口是观察者外，还有ConnectivityMonitor ，TargetTracker，Target 都继承/实现LifecycleListener都是观察者，观察者比较简单不多讲了。
接下来讲讲glide 核心代码所用的责任链设计模式，通过责任链设计模式使多个对象都有机会处理请求，从而避免请求的发送者和接收者之间的耦合关系。将这些对象连成一条链，并沿着这条链发送该请求，直到有一个对象处理它为止。
责任链设计模式
如下 ， ResourceCache（不需要解码和变换直接可以显示） ，DataCache（需要解码和变换） ， Source 分别对应三个Generator，前两个从本地磁盘缓存中获取的图片数据，后面则直接从源（网络或者app本地资源文件中）Glide 按照配置依次从中获取图片加载数据。
这是责任链模式？怎么看都不像啊，责任链定义不是要将这些对象连成一条链，并沿着这条链发送该请求，直到有一个对象处理它为止。也就是说责任链模式都要有请求参数，就glide 而言这里给Generator的请求参数decodeHelper早在Generator初始化就传入了，就不用在startNext()方法中传入decodeHelper了。
代码都是死的，但是思想都是一样的，其实上面的代码也可以改成标准责任链模式。责任链设计模式有什么好处？责任链设计模式能够解耦请求发送者和接收者，简化对象之间的交互，提供灵活的处理顺序，使得系统更加灵活、可扩展和易于维护。它适用于需要动态组合和处理多个相关对象的场景，特别是在处理复杂的业务逻辑时，可以将复杂性分解成简单的处理步骤。
就Glide 而言，将解码请求发送者DecodeJob 高层对象和各种解码具体处理对象ResourceCacheGenerator等解耦，以及具体请求对象之间都通过责任链模式解耦了，DecodeJob作为高层对象无需关注解码细节，只需关注解码的整体流程就行。除了解耦之外还提供良好的扩展性，比如不需要从磁盘缓存中获取已解码的图片缓存， 只需要去掉return new ResourceCacheGenerator就行了，如下。
策略模式
glide 用于判断支不支持从磁盘缓存中获取图片就用到了策略模式
DiskCacheStrategy 有几个子类ALL 表示全部支持， NONE 什么都不支持。默认使用 AUTOMATIC 只有从网络才支持Data 缓存，并且从网络获取中如果使用了Data 缓存则不支持ResourceCache。我们要改缓存策略的话可以在请求参数中修改DiskCacheStrategy。
另外还有解码的时候向下采样也用到了策略模式，根据imageView 的scaleType 分别对应了几种策略。
结构型设计模式
装饰模式
通过装饰者模式我们可以在运行时动态地给对象添加额外的功能，而不需要改变原始对象的结构。这使得我们可以灵活地组合对象并添加所需的功能，从而满足不同的需求，接下来我们看下glide 中怎么使用的。
Glide 从moedl -> data 这个过程就用到了装饰者设计模式，与之相关的接口是 ModelLoader<Model, Data> 以及实现此接口的子类。假设model 为string情况 ，这种情况对应的有表示网络请求的url ，本地文件 uri ，asset uri ，图片文件路径等，此时ModelLoader 具体实现类为StringLoader。
StringLoader 为被装饰者，构造中传入装饰者uriLoader ，uriLoader装饰者给StringLoader动态扩展功能，但又不会修改和影响StringLoader整体结构。uriLoader给StringLoader 扩展了什么功能呢？比如支持从网络中获取图片的HttpGlideUrlLoader ，支持从ContentResolver 获取图片的UriLoader，以及支持从 Asset目录下获取图片的AssetUriLoader等等。如果不使用装饰者设计模式，把这些功能实现都写在StringLoader 中，可想而知StringLoader 中代码量有多大，有多难维护了。
除了装饰设计模式其实ModelLoader还用到了组合设计模式。
组合设计模式
前面说到StringLoader 要动态新增功能使用了装饰设计模式，思考一下如果新增那么多功能是不是要给每个功能都建立一个装饰类？如果一两个功能还好，但是类多的话就爆炸了，有没有更好的办法去解决呢？
glide使用组合模式来规避了这个问题，引入一个MultiModelLoader ，顾名思义这个里面可以放很多个ModelLoader，把那些装饰StringLoader的装饰者都放在MultiModelLoader里，MultiModelLoader 把这些装饰者组合起来，这样可以避免类爆炸的问题。
有些人会认为你把这些装饰者都放一起这不是严重耦合？不符合六大法则啊，程序设计讲究高内聚低耦合，你这耦合这么严重以后怎么维护啊，你这代码不保熟啊。
看代码其实就知道并不是这样的，MultiModelLoader只是依赖了各种装饰者的抽象，并没有依赖各个装饰者的具体实现，具体装饰者的代码修改完全不影响MultiModelLoader 。从依赖倒置原则来看，MultiModelLoader 作为client 高层对象依赖抽象ModelLoader ，各个具体装饰者如HttpGlideUrlLoader 也依赖抽象ModelLoader ，MultiModelLoader和HttpGlideUrlLoader通过ModelLoader 抽象实现了依赖倒置。从里氏替换原则来，ModelLoader抽象可以出现的地方，ModelLoader的各种子类装饰者也可以出现在MultiModelLoader中。从迪米特法则和单一职责来看，MultiModelLoader只用于管理统筹多个ModelLoader，不耦合具体实现 。
享元设计模式
每次去加载图片都要一个DecodeJob 去执行图片加载任务，如果一段时间内执行成百上千个图片加载请求，有可能会造成内存抖动，有没有可以优化的地方呢？glide使用享元模式来复用DecodeJob对象，优化和节省内存的使用，如下。
在DecodeJob release的时候将其放入池子中回收。
glide 中不止DecodeJob对象用了享元模式来复用对象优化内存， 还有很多对象比如EngineJob，Bitmap等都是用池子来复用的。
这里提出个问题，为什么每次去加载图片基本都会新建一个Request ，为什么Request 没有用享元模式呢？
glide 中用到的设计模式还有优秀的设计思想远远不止此文所述，一篇文章终究是难以说清，但学习方法都是一样的，就是read the fuck glide source code ，把glide 的皮一层一层拨开。
Android 学习笔录
深知大多数程序员，想要提升技能，往往是自己摸索成长，但自己不成体系的自学效果低效又漫长，而且极易碰到天花板技术停滞不前！
既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，涵盖了95%以上鸿蒙开发知识点，真正体系化！
由于文件比较多，这里只是将部分目录截图出来，全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、讲解视频，并且后续会持续更新
盖了95%以上鸿蒙开发知识点，真正体系化！**
由于文件比较多，这里只是将部分目录截图出来，全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、讲解视频，并且后续会持续更新
277
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
