- 存在的问题
最近在做项目的过程中，发生APP启动的时候，有些接口会在短时间（例如1s）之内重复调用多次，在APP执行某些操作时，也时不时出现一个接口短时间内调用多次的情况。究其原因，有些请求重复是因为在不同的时机点都需要请求这个接口，但是有时候这些不同时机点，在短时间内会一起发生，例如如下这种情况：
- (void)applicationDidBecomeActive:(UIApplication *)application {
// 请求接口
}
// 首页控制器
- (void)viewDidLoad {
// 请求接口
}
我需要在app回到前台时请求接口，在首页控制器加载完后也需要请求接口，这两个不同的时机，会在APP启动时短时间内都发生，导致接口重复请求了。虽然可以针对这种情况写一些判断代码，当每发生类似情况都写一次判断就不优雅了。
还有些重复请求的情况是代码一开始设计没有考虑那么完善，后面代码迭代，就会导致有些逻辑重复走几次，接口也重复请求了。这种改起来就要小心翼翼了，一不小心就容易改出bug。
- 解决问题的思路
所以仔细思考后，还是决定统一处理，从请求的底层下手，在请求的底层做重复请求的管理，提供一个过滤方法给业务层，业务层只需要把原来的请求接口的方法替换成有过滤功能的方法就可以了，不需要改动业务逻辑。
那么应该如何设计这个对外提供的方法呢，我这里设计为方法会提供一个参数，可以设置过滤时间，在过滤时间范围内，相同的请求只会发出去一次：
@interface EPRequest : YTKRequest<NSCoding>
// url
@property (nonatomic, copy) NSString *url;
// 请求方法
@property (nonatomic, assign) YTKRequestMethod method;
// 请求参数
@property (nonatomic, copy) NSDictionary *parameters;
...
// 原来的请求方法
- (void)startWithCompletedBlock:(EPRequestCompletedCallBack)callBack;
// 带过滤功能的请求方法
- (void)startWithFilterDuplicateRequestInDuration:(NSTimeInterval)duration completedBlock:(EPRequestCompletedCallBack)callBack;
...
@end
EPRequest对象，表示一个请求。如果调用了第二个方法，内部就会判断当前的请求是否已经开启了过滤，如果没开始，就发出这个请求，并且开启过滤；如果已经开启了过滤，就根据当前所处的过滤状态做相应的处理。
这里应该注意的是开启过滤之后，又调用相同url请求的 startWithFilterDuplicateRequestInDuration 方法时，不是直接过滤，当做没调用，因为原来的请求方法调用之后是有block回调的，会返回调用结果，如果带过滤功能的请求方法直接无视，岂不是block里面的逻辑没执行了。此时的设计应该是内部会过滤请求，但是对于业务层来说，是无感知的，我们还是要返回正常结果。这个结果从哪里来呢，来自一开始的url请求，我们会把请求回来后的结果记录下来，供过滤掉的请求回调使用。
所以，根据过滤时间设置的定时器时间是否已结束，以及一开始发出的请求结果是否已经返回，我们可以梳理出在请求开启过滤时，可能存在的四种状态：
（1）定时器未结束，结果未返回
（2）定时器未结束，结果已返回
（3）定时器已结束，结果未返回
（4）定时器已结束，结果已返回
对于状态（1），有需要过滤的请求过来时，应该把这个请求记录下来，等待第一个发出的请求结果的返回，然后这个结果就可以直接给该过滤的请求，让它返回给外部了。
对于状态（2），有需要过滤的请求过来时，由于此时第一个发出的请求的结果已经返回，我们只需要把这个结果返回给该过滤请求的回调就可以了；对于业务层来说，相当于调用了接口立即有了结果。
对于状态（3），虽然此时定时器已结束，但这里我还是设计为如果一开始的请求结果未返回，还是视为过滤流程没有结束（因为此时可能由于网络或者服务器原因而没有返回，短时间内再发一次也是徒劳，至少也要等超时结果返回再发）；此时也会记录该请求，等待第一个发出的请求结果返回，然后这个结果给该过滤的请求（超时结果也算返回的结果），然后就进入了状态（4）。
对于状态（4），显然状态（1）（2）（3）最后都会进入状态（4），表示这个过滤流程已经结束了。此时有需要过滤的请求过来时，说明这是第一个请求，不需要过滤，这是一个真正会发出的请求，并且设置了定时器，开启了过滤的流程。
根据如上的状态分析，以及每个状态需要什么操作，画出的三个流程图如下所示：
image.png
image.png
这样这个过滤请求功能的整体设计就出来了。但是这里有一点需要注意，就是外部调用过滤请求的方法时，可能处于不同的线程，也就是说在内部代码的处理上，会涉及到线程安全的处理。具体来说，我们应该在改变状态的代码上加一个锁。为什么呢，以状态（3）和流程3来举例，假如有一个过滤请求进来，判断处于状态（3），此时这个请求会被记录，等待结果返回时应用该结果，但此时流程3在并行执行；该操作（请求结果返回并将所有记录的请求取出，将请求结果回调给它们)发生在过滤请求的状态（3）判断之后，请求被记录之前，那么就会导致这个请求虽然被记录，但是永远不会有回调的时候。
所以，状态判断的相关代码是可以在多个线程同时执行的，但是状态变更的代码跟状态判断代码，状态变更代码是互斥的；这个锁应该是一个多读单写的锁。
CGD有一个锁可以实现该功能：
// 初始化队列
dispatch_queue_t queue = dispatch_queue_create("rw_queue", DISPATCH_QUEUE_CONCURRENT);
// 读
dispatch_async(queue, ^{
});
// 写
dispatch_barrier_async(queue, ^{
});
注意 dispatch_barrier_async 传入的队列必须是一个自己创建的并发队列，不能是全局的并发队列（如果传入全局的并发队列，效果等同于调用了dispatch_async）。
至此，整个设计思路就是这样了，由于具体实现代码是根据我们的项目的请求类定制的，所以就不贴出来了。功能完成后，上线1个月，完美运行hahaha~。
网友评论