背景
项目中构建接口请求，步骤比较繁琐，希望像retrofit一样。
这样能提高开发效率，减少维护成本。
解决方案
在研究了retrofit的技术方案后，采用相同的动态代理+注解技术方案
- 注解：帮助我们简化、规范接口请求的协议
- 动态代理：接口方法能直接解析使用，而不用手动创建对象。
结果
重构后，两步就能实现接口调用
1.声明
public interface Api {
Api ready = XLApiManager.ready().getApi(Api.class);
@POST("system/changeRole")
XLCall changeRole(
@Param("changeUserId") String changeUserId,
@Param("uniqueDeviceId") String uniqueDeviceId);
2.调用
Api.ready.changeRole(changeUserId, DeviceUtil.getDeviceId()).requestV2(...success...fail);
可以看到接口调用已经非常简单，和retrofit一致，符合我们重构的预期。
核心讲解
下面我们从使用者的角度出发，讲讲本项目是如何实现的。
1、接口里的方法为什么能方法直接用了？
我们可以看到链式调用，每一步他的调用主体都不一样，如下图
ready时，我们通过动态代理，创建了Api接口的动态对象，后续的changeRole方法被转发给了动态代理去执行。
那么动态代理是怎么被创建、又是怎么执行方法呢？
- 创建。用了享元模式，复用来避免动态代理重复创建浪费资源性能。同时引入了双重检查锁，避免多线程情况下重复创建对象。
Api ready = XLApiManager.ready().getApi(Api.class);
//getApi实现
public T getApi(Class api) {
T result = (T) apiClassCache.get(api);
if (result != null) {
return result;
}
synchronized (apiClassCache) {
result = (T) apiClassCache.get(api);
if (result == null) {
result = create(api);
apiClassCache.put(api, result);
}
}
return result;
}
- 执行
下面是动态代理的调用方法，我们Api.ready.xxx动态代理的方法，都交由invoke去解析执行
Proxy.newProxyInstance是java系统方法，核心是看invoke
private T create(final Class api) {
XLHttpUtils.validateApiInterface(api);
return (T) Proxy.newProxyInstance(api.getClassLoader(), new Class[]{api}, new InvocationHandler() {
@Override
public Object invoke(Object proxy, Method method, Object... args) throws Throwable {
//1.解析函数、注解等信息
ApiMethod apiMethod = loadApiMethod(method);
//2.设置函数的入参
apiMethod.setArgs(args);
// 3. 以此构建一个接口请求
return new ApiCallV2(XLApiManager.this, apiMethod);
}
});
}
-
loadApiMethod负责解析出函数的协议，包括路径、参数名、返回类型等 -
setArgs负责解析函数的入参值 - 一个请求所有的基本要素已经准备好，最后一步负责创建一个请求对象。
以上就是Api.ready.changeRole(changeUserId, DeviceUtil.getDeviceId())主体变化的全过程了。
此时创建好了请求对象，我们就可以发起请求，并提供解析回调了.requestV2(...success...fail)
2、入参里注解的参数，最终怎么传递给服务端？
举个请求例子：
/**
* 教师 – 作业 – 学生 – 提醒交作业
*/
@POST("teacherWork/v3/remindWork")
XLCall remindWork(
@Param("workId") String workId,
@Param("classId") String classId);
在第一个问题，我们提到了，Api函数的调用都被转发到了代理的invoke方法里
@Override
public Object invoke(Object proxy, Method method, Object... args) throws Throwable {
//1创建方法对象
ApiMethod apiMethod = loadApiMethod(method);
//2刷新入参
apiMethod.setArgs(args);
return new ApiCallV2(XLApiManager.this, apiMethod);
}
}
在1、loadApiMethod里，通过parseParameterAnnotation，把注解的参数名记录下来
在 2、setArgs刷新入参，把invoke拿到的入参参数值，记录下来
通过1、2步，我们拿到了一个包含入参名、值的数组。
最后为了性能考虑，入参加密步骤，我们延迟在实际使用的时候，通过
ParamSignUtils.signParams生成了加密信息数据
3、请求返回值为啥能自动解析成 DTO
1、返回类型怎么保存
通过FAQ第一个问题，我们知道了：接口对象所有的方法调用，都转发到了InvocationHandler的invoke方法。
在invoke方法里，通过resolveResponseType拿到了方法的返回值XLCall；再通过getParameterUpperBound()拿到了泛型里的类RE_Result
至此，请求函数已经知道了okHttp返回的数据流要解析成什么对象
2、怎么解析成返回类型
拿到okHttp返回的Body。先解析成String再转换成对应的类型
String bodyString = new String(bodyBytes, getCharset(rawResponse.body()));
T bean = new ResponseConverter(apiMethod.responseType).convert(bodyString);
@Override
public T convert(String result) {
Class clazz = (Class) responseType;
if (clazz == String.class.getClass()) {
//noinspection unchecked
return (T) result;
}
return (T) JsonUtil.jsonToObject(result, clazz);
}
4、异步请求生命周期自动管理
我们使用JetPack的LifecycleOwner来自动监听载体生命周期
在ApiCallV2里，监听载体销毁的事件
@OnLifecycleEvent(Lifecycle.Event.ON_DESTROY)
public void destroy() {
mIsDestroy = true;
unRegisterLifeCircleCall();
if (!isCanceled()) {
cancel();
}
}
对于调用方来说是重载了requestV2，多了LifecycleOwner参数
Api.ready.changeRole(changeUserId, DeviceUtil.getDeviceId()).requestV2(...success...fail);
改成
Api.ready.changeRole(changeUserId, DeviceUtil.getDeviceId()).requestV2(...success...fail,LifecycleOwner);