Android开发：从设计者角度看Retrofit原理(1)，2024年最新flutterpageview卡顿

前言

==============================================================

通常我不喜欢去写分析源码类的文章，流水线式的分析 枯燥乏味，但读完Retrofit源码后让我有了改变这种想法的冲动～～

一般来讲读源码的好处有两点：

• 熟悉代码设计流程，使用过程碰到问题可以更快速解决。说实话仅这一点无法激起我读源码的兴趣，毕竟以正确的姿态使用一个优秀的框架不应该出现这种问题。

• 一个优秀的框架必须要保证易用性、扩展性，所以作者定会引入大量的思考进行设计，如若我们能吸收一二，那何尝不是与作者进行了一次心灵交互呢!

今天我将带着我的理解，尝试从设计者的角度分析Retrofit原理，相信你认真读完再加以思考，当再被面试官问Retrofit时你的答复或许会让他眼前一亮

提示:Retrofit基于2.9.0。文中贴的源码可能会有部分缺失，这是我刻意为之，目的在于筛选掉无用信息增强可读性

目录

==============================================================

• 1. 什么是REST ful API？

• 2. 为什么将请求设置为(接口+注解)形式？

• 2.1. 迪米特法则和门面模式

• 2.2. 为什么通过门面模式设计ApiService？

• 3. 动态代理其实不是工具

• 3.1. Retrofit构建

• 3.2. 何为动态代理？

• 3.3. 动态代理获取ApiService

• 4. ReturnT、ResponseT做一次适配的意义何在？

• 4.1 创建HttpServiceMethod

• 4.2 如何管理callAdapter、responseConverter？

• 4.3 发起请求

1. 什么是REST ful API？

================================================================================

一句话概括REST ful API：在我们使用HTTP协议做数据传输时应当遵守HTTP的规矩，包括请求方法、资源类型、Uri格式等等…

不久前在群里看到某小伙伴提出一个问题：“应后端要求需要在GET请求加入Body但Retrofit 中GET请求添加Body会报错，如何解决？” 一时间讨论的好不热闹，有让把Body塞到Header里的，有让自定义拦截器、也有人直接怂恿改源码…但问题的本质不是后端先违反规则在先吗？两个人打架总不能把挨打的抓起来吧。

俗话说无规矩不成方圆，面对以上这种情况应当让错误方去修改，因为所有人都知道GET没有Body，否则一旦其他人接手你的代码很容易被搞懵。

Retrofit对REST ful API的兼容做的很优秀，不符合规范直接给你报错，强行规范你的代码。所以你们公司正在使用REST ful API而Retrofit将是你的不二选择

2. 为什么将请求设置为(接口+注解)形式？

===================================================================================

该小节为前置知识

2.1 迪米特法则和门面模式

==========================================================================

迪米特法则：也称之为最小知道原则，即模块之间尽量减少不必要的依赖，即降低模块间的耦合性。

门面模式：基于迪米特法则拓展出来的一种设计模式，旨在将复杂的模块/系统访问入口控制的更加单一。举个例子：现要做一个获取图片功能，优先从本地缓存获取，没有缓存从网络获取随后再加入到本地缓存，假如不做任何处理，那每获取一张图片都要写一遍缓存逻辑，写的越多出错的可能就越高，其实调用者只是想获取一张图片而已，具体如何获取他不需要关心。此时可以通过门面模式将缓存功能做一个封装，只暴露出一个获取图片入口，这样调用者使用起来更加方便而且安全性更高。其实函数式编程也是门面模式的产物

2.2 为什么通过门面模式设计ApiService？

======================================================================================

用Retrofit做一次请求大致流程如下:

interface ApiService {

/**

* 获取首页数据

*/

@GET(“/article/list/{page}/json”)

suspend fun getHomeList(@Path(“page”) pageNo: Int)

: ApiResponse

}

//构建Retrofit

val retrofit = Retrofit.Builder().build()

//创建ApiService实例

val apiService =retrofit.create(ApiService::class.java)

//发起请求(这里用的是suspend会自动发起请求，Java中可通过返回的call请求)

apiService.getHomeList(1)

然后通过Retrofit创建ApiService类型实例调用对应方法即可发起请求。乍一看感觉很普通，但实际上Retrofit通过这种模式(门面模式)帮我们过滤掉了很多无用信息

tips：我们都知道Retrofit只不过是对OkHttp做了封装。

如果直接使用OkHttp，当在构造Request时要做很多繁琐的工作，最要命的是Request可能在多处被构造(ViewModel、Repository…)，写的越分散出错时排查的难度就越高。而Retrofit通过注解的形式将Request需要的必要信息全依附在方法上(还是个抽象方法，尽量撇除一切多余信息)，作为使用者只需要调用对应方法即可实现请求。至于如何解析、构造、发起请求 Retrofit内部会做处理，调用者不想也不需要知道，

所以Retrofit通过门面模式帮调用者屏蔽了一些无用信息，只暴露出唯一入口，让调用者更专注于业务开发。像我们常用的Room、GreenDao也使用了这种模式

3. 动态代理其实不是工具

==========================================================================

看过很多Retrofit相关的文章，都喜欢上来就抛动态代理，关于为什么用只字不提，搞的Retrofit动态代理像是一个工具(框架)一样，殊不知它只是代理模式思想层面的一个产物而已。本小结会透过Retrofit看动态代理本质，帮你解除对它的误解

3.1 Retrofit构建

==========================================================================

Retrofit构建如下所示：

Retrofit.Builder()

.client(okHttpClient)

.addConverterFactory(GsonConverterFactory.create())

.addCallAdapterFactory(RxJava2CallAdapterFactory.create())

.baseUrl(ApiConstants.BASE_URL)

.build()

很典型的构建者模式,可以配置OkHttp、Gson、RxJava等等，最后通过build()做构建操作，跟一下build()代码：

#Retrofit.class

public Retrofit build() {

//1.CallAdapter工厂集合

List<CallAdapter.Factory> callAdapterFactories = new ArrayList<>(this.callAdapterFactories);

callAdapterFactories.addAll(platform.defaultCallAdapterFactories(callbackExecutor));

//2.Converter工厂集合

List<Converter.Factory> converterFactories =

new ArrayList<>(

1 + this.converterFactories.size() + platform.defaultConverterFactoriesSize());

converterFactories.add(new BuiltInConverters());

converterFactories.addAll(this.converterFactories);

converterFactories.addAll(platform.defaultConverterFactories());

return new Retrofit(

callFactory,

baseUrl,

unmodifiableList(converterFactories),

unmodifiableList(callAdapterFactories),

callbackExecutor,

validateEagerly);

}

将一些必要信息注入到Retrofit并创建返回。注释1、2处两个集合非常重要，这里先埋个伏笔后面我们再回来看

3.2 何为动态代理？

=======================================================================

什么是代理模式？

代理模式概念非常简单，比如A想做一件事可以让B帮他做，这样做的好处是什么？下面通过一个例子简要说明。需求：每一次本地数据库CRUD都要做一次上报

最简单粗暴的方式就是每次CRUD时都单独做一次记录，代码如下

//业务层方法test1

fun test1{

//数据库插入操作

dao.insert()

//上报

post()

}

//业务层方法test2

fun test2(){

//数据库更新操作

dao.update()

//上报

post()

}

以上这种方式存在一个问题：

上报操作本身与具体业务无关，一旦需要对上报进行修改，那就可能影响到业务，进而可能造成不可预期的问题产生

面对以上问题可以通过代理模式完美规避，改造后的代码如下：

class DaoProxy(){

//数据库插入操作

fun insert(){

dao.insert()

//上报

post()

}

//数据库更新操作

fun update(){

dao.update()

//上报

post()

}

}

//业务层方法test1

fun test1{

//数据库插入操作

daoProxy.insert()

}

//业务层方法test2

fun test2(){

//数据库更新操作

daoProxy.update()

}

新增一个代理类DaoProxy，将dao以及上报操作在代理类中执行，业务层直接操作代理对象，这样就将上报从业务层抽离出来，从而避免业务层改动带来的问题。实际使用代理模式时应遵守基于接口而非实现编程思想，但文章侧重于传授思想，规范上可能欠缺

此时还有一个问题，每次CRUD都会手动做一次上报操作，这显然是模版代码，如何解决？下面来看动态代理：

什么是动态代理？

java中的动态代理就是在运行时通过反射为目标对象做一些附加操作，代码如下：

class DaoProxy() {

//创建代理类

fun createProxy(): Any {

//创建dao

val proxyAny = Dao()

val interfaces = proxyAny.javaClass.interfaces

val handler = ProxyHandler(proxyAny)

return Proxy.newProxyInstance(proxyAny::class.java.classLoader, interfaces, handler)

}

//代理委托类

class ProxyHandler(private val proxyObject:Any): InvocationHandler {

//代理方法，p1为目标类方法、p2为目标类参数。调用proxyObject任一方法时都会执行invoke

override fun invoke(p0: Any, p1: Method, p2: Array): Any {

//执行Dao各个方法(CRUD)

val result = p1.invoke(proxyObject,p2)

//上报

post()

return result

}

}

}

//此处规范上应该使用基于接口而非实现编程。如果要替换Dao通过接口编程可提高扩展性

val dao:Dao = DaoProxy().createProxy() as Dao

dao.insert()

dao.update()

其中Proxy是JDK中用于创建动态代理的类，InvocationHandler是一个委托类， 内部的invoke（代理方法）方法会随着目标类(Dao)任一方法的调用而调用，所以在其内部实现上报操作即可消除大量模版代码。

动态代理与静态代理核心思想一致，区别是动态代理可以在运行时通过反射动态创建一个切面(InvocationHandler#invoke),用来消除模板代码。喜欢思考的同学其实已经发现，代理模式符合面向切面编程(AOP)思想，而代理类就是切面

3.3 动态代理获取ApiService

================================================================================

2.2小节有提到可以通过retrofit.create()创建ApiService，跟一下retrofit的create()

#Retrofit.class

public  T create(final Class service) {

//第一处

validateServiceInterface(service);

return (T) Proxy.newProxyInstance(

service.getClassLoader(),

new Class<?>[] {service},

new InvocationHandler() {

//第二处

@Override

public @Nullable Object invoke(Object proxy, Method method, @Nullable Object[] args)

throws Throwable {

…

return platform.isDefaultMethod(method)

? platform.invokeDefaultMethod(method, service, proxy, args)

: loadServiceMethod(method).invoke(args);

}

});

}

create()大致可以分为两部分：

• 第一部分为validateServiceInterface()内容，用来验证ApiService合法性，比较简单就不多描述，感兴趣的同学可自行查看。

• 第二部分就是invoke()，通过3.2小节可知这是一个代理方法，可通过调用ApiService中的任一方法执行，其中参数method和args代表ApiService对应的方法和参数。返回值中有一个isDefaultMethod，这里如果是Java8的默认方法直接执行，毕竟我们只需要代理ApiService中方法即可。经过反复筛选最后重任落在了loadServiceMethod，这也是Retrofit中最核心的一个方法，下面我们来跟一下

#Retrofit.class

自我介绍一下，小编13年上海交大毕业，曾经在小公司待过，也去过华为、OPPO等大厂，18年进入阿里一直到现在。

深知大多数Android工程师，想要提升技能，往往是自己摸索成长或者是报班学习，但对于培训机构动则几千的学费，着实压力不小。自己不成体系的自学效果低效又漫长，而且极易碰到天花板技术停滞不前！

因此收集整理了一份《2024年Android移动开发全套学习资料》，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友，同时减轻大家的负担。

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，基本涵盖了95%以上Android开发知识点，真正体系化！

由于文件比较大，这里只是将部分目录大纲截图出来，每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频，并且后续会持续更新

如果你觉得这些内容对你有帮助，可以添加V获取：vip204888 （备注Android）

推荐学习资料

---

• 脑图
  
  
  

一个人可以走的很快，但一群人才能走的更远。不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎扫码加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！

868a3f0fd6ac81d625c.png)

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，基本涵盖了95%以上Android开发知识点，真正体系化！

由于文件比较大，这里只是将部分目录大纲截图出来，每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频，并且后续会持续更新

如果你觉得这些内容对你有帮助，可以添加V获取：vip204888 （备注Android）
[外链图片转存中…(img-1KK37U15-1712693097788)]

推荐学习资料

---

• 脑图
  [外链图片转存中…(img-HWntDDke-1712693097788)]
  [外链图片转存中…(img-thThUE2R-1712693097788)]
  [外链图片转存中…(img-oRV7jmVu-1712693097788)]

一个人可以走的很快，但一群人才能走的更远。不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎扫码加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！
[外链图片转存中…(img-Ydzuu0KB-1712693097789)]