为什么要使用策略模式引用？
在Android开发过程中，我们一般都会使用到第三方框架，随着框架层出不穷，随着项目的发展扩大，不排除会出现替换框架的情况，例如：日志框架，图片框架，网络框架等等；最初我在开发过程中会直接引用第三方框架，直到后来需要替换框架的时候，才发现这个过程的工作量是巨大并且没意义的，需要修改使用到框架的地方有几十处（如果项目大，远远不止这个数目），那时候我就醒悟，一定要培养架构思想，不能应付式的实现了功能就认为万事大吉。后来在学习过程中发现，使用策略模式可以很友好的解决框架更换的问题，并且可以通过一句代码就轻松切换整个项目的框架。
不使用策略模式封装也可以呀！
或许会有读者认为没必要使用策略模式这么麻烦，只需要将框架进行二次封装，待需要修改的时候也可以不影响其他代码。对于这种思路，我用图片框架Universal-Image-Loader作为例子简单描述一下，贴上简短的代码便于清晰。
image.png
封装好的工具类在Activity中的示范如下：
image.png
如果需要使用Glide框架替换现在的Universal-Image-Loader框架，直接修改ImageLoaderUtils工具类，这样亦可实现不需修改所有使用到框架Universal-Image-Loader的地方。
image.png
这样处理固然可以替换框架，并且工作量不算大，但我认为这种处理方式有一定的弊端，剔除了旧框架代码，万一日后新框架出现问题，处理工作就显得麻烦，说白了就是这种处理方式不能并存两种或两种以上的框架方案，如果项目中需要切换框架的话就明显感觉到不灵活，所以我认为引入策略模式是可取的。
有兴趣的加入Android工程师交流Q群：752016839 主要针对Android开发人员提升自己，突破瓶颈，相信你来学习，会有提升和收获
开启封装之路
关于策略模式，这里我就不详细描述，日后抽空写一篇关于“策略模式”的文章。
首先，我们定义一个策略接口，用于存放框架之间会共同使用的方法，例如：默认加载图片，加载GIf等等。
image.png
第二步：接下来写实现类，这里我使用Universal-Image-Loader为例，简单写一个实现类。
image.png
完成实现类后，最后写一个调用的工具类就完成了封装。
image.png
到此为止，就已经完成了初步的封装，使用方式：
image.png
完成了初步封装，但如何解决框架替换的问题好像还没提及到。兄弟不要急呀，车现在马上要开，扶稳了。假如项目现在要使用Glide框架，那我们需要先写一个简单Glide的实现类。如下：
image.png
搞定了Glide的实现类后，调用ImageLoaderUtils的setImageLoaderStrategy方法即可实现框架的替换，并且不影响其他代码。
image.png
主要思想大概就是这样，但实际项目中的封装并没有这么简单，为了描述这种思想，所以简单化，在此我贴上源码地址：
https://github.com/fansonq/ImageLoaderUtils，有兴趣的读者不妨下载阅读，更深的了解（源码有注释）。
看完图片框架的封装，大家不妨尝试封装日志框架进行理解并巩固，将这种思想融会贯通。
如果这篇文章写的有错漏，恳请留言提示纠正；如果有什么地方描述的不够清晰，留下评论，我看到会给予回复，一起交流
