前言
之前的文章 从源码角度看Retrofit2实现原理 已经介绍过Retrofit2源码和原理了，本文试图站在更高的角度去解析这个框架到底好在哪里？以及从架构思想方面去思考它值得学习／借鉴的地方。
1、为什么要选择Retrofit2？相比其它网络请求框架，它的优势在哪里？
在说Retrofit2优势之前，我们先来思考一下网络库都做了哪些共同的事情？
在Retrofit2之前已经有了很多网络库，比如说OkHttp、Volley、XUtils等，它们在设计、使用、性能上都有所不同，但是它们的核心流程确是一样的。
业务层发起请求--->网络层处理请求
网络层：构造Request请求（包括header、body）--->发起请求--->解析响应结果（根据response code作出不同的解析结果）--->回调响应结果
1.1 从流程角度看Retrofit2的优势
答案就是2个字：简洁。
- 首先构造Request更容易了，当你使用
OkHttp时，需要通过builder来构造Request，而Retrofit2通过几个简单的注解就可以完成。使用注解还可以动态改变参数，不用在代码做大量的修改； - 发起请求，如果是
Call类型，那和OkHttp是一样的，如果是Observable类型，在内部就自动调用了请求； - 解析响应结果，
OkHttp是需要在回调中根据response做判断手动解析的，而Retrofit2可以在构建Retrofit对象时，配置一次Convert就能将结果转换成可以直接使用的对象； - 回调直接在主线程，刚好满足请求更新UI的需求。
1.2拓展性强
- 比如说可以配置不同的http client，当然在
Retrofit2中只有OkHttp了； - 配置不同的数据转换器
json、xml、protoBuffer等 - 适配器，比如支持
RxJava2的RxJava2CallAdapterFactory
1.3解耦、安全、高效
- 因为
retrofit是不直接接触网络请求的，而是交给内部的okhttp3来完成； - 安全是注解在编译器直接注入了代码，防止反编译；
- 这里的高效并不是说效率上的，因为内部用了反射、转换器也不可能高效，这里是说使用的时候。
1.4无缝对接RxJava
把它单独拿出来讲，足以说明retrofit和RxJava是多么般配。如果你使用的是Call方式，你觉得它比使用okhttp3更方便吗？我认为在使用方面是没有多大优势的，因为client配置和发起请求、callback回调都是一样的，也就是构建请求有所区别；但是如果你用的是Observable就不一样了，因为配合RxJava2强大的操作符和线程调度器可以让你更简洁的处理复杂的网络情况，比如说嵌套请求、合并请求、轮训等等。
2、从架构角度看Retrofit2设计思想
2.1 Retrofit到底那里牛逼？
在最开始使用Retrofit的时候，没觉得它有多牛逼，甚至一度认为它蹭了okhttp 、rxjava的热点,直到对它的源码反复阅读之后，才发现它是真香。
Retrofit2到底做了什么事情，让人觉得它真香？
答案是没有，我查看了它源码的大部分，确实没找到哪一个地方特别亮眼，值得吹捧。你不信，我举例给你看，比如说接口中的注解，有人觉得很nb，实际上这种依赖注入的方式，应用已经很广泛了，比如ButterKnife Dagger AOP等等；比如说源码中的动态代理、适配器模式（还有比较简单的工厂模式、建造者模式等），这些东西在其它框架内部应用就更多了，也算不得多nb。如果你有其它想法，请在下方留言交流
但就是这些“普通”的东西组合在一起，却让Retrofit变得很牛逼。
我心目中的Retrofit是一个调度器，它合理的运用设计模式把其它几个框架整合在一起，在实现解耦的同时也提供了高拓展性。它不做网络请求，而是利用okhttp3做网络请求；利用Gson等做数据解析；利用rxjava做异步任务。
2.2 单一职责原则和分层思想
Retrofit在这2方面是做的真好，比如说OkHttpCall就负责网络调用；ServiceMethod就负责方法解析，构建Request；扩展方面就通过Retrofit的建造者模式去实现；内部做了大量默认的实现，用户可以选择简单的配置调用，也可以自定义；
2.2 设计中的变量与不变量
网络请求中的变量是报文，不变量是一个封装网络请求任务的对象，比如说okhttp3中的Call对象，而Retrofit中用依赖倒置原则定义了自己的retrofit.call接口和实现类OkHttpCall;针对网络变量，通过动态代理、反射和具体的ServiceMethod去动态获取，也可以在okhttpclient中做一些变量设置;针对业务层面的变量，提供了CallAdapterFactory和Convert来扩展。
网友评论