大家都知道,当一个网络请求发出去之后,如果不管不顾,有可能出现以下情况:
进入某个页面,做了某种操作(退出页面、切换某个tab等等)导致之前的请求变成无用请求,这时候有可能出现虽然页面已经销毁了,但是网络请求还在外面飞的情况,如果放任不管,那么这个请求既浪费流量,又浪费性能,尤其是在网络比较差时,一个超时的无用请求更让人不爽。这时候,我们最好的办法是cancel掉这些无用的请求。
传统的cancel方式是这样的:
1.在类里面需要持有请求对象
@property (strong/weak, nonatomic) XXRequest *xxrequest1;
属性具体用strong还是weak取决于你的网络层设计,有些网络层request是完全的临时变量,出了方法就直接销毁的需要用strong,有些设计则具有自持有的特性,请求结束前不会销毁的可以用weak。
2.在请求发起的地方,赋值请求
xxrequest1 = xxx;
self.xxrequest1 = xxrequest1;
[xxrequest1 start];
3.在需要销毁的地方,一般是本类的dealloc里面
[self.xxrequest1 cancel];
可以看到为了cancel一个request,我们的请求对象到处都是,如果再来几个请求,那处理起来就更恶心了。。
有没有什么方式可以让我们省心省力呢?
目标:
我们希望可以控制一部分请求,在页面销毁、manager释放等时机,自动的cancel掉我们发出去的请求,而不需要我们手动去写上面这种到处都是的代码
方案:
监听类的dealloc方法调用,当dealloc执行时,顺带着执行下request的cancel方法
很快,我们就发现了问题:
ARC下不允许hook类的dealloc方法,所以hook是不行的。那还有别的方式可以知道一个类被dealloc了吗?
其实我们可以采用一些变通的方案得到,我们知道associated绑定的属性,是可以根据绑定时的设置,在dealloc时自动释放的,所以我们可以利用这一点做到监听dealloc调用:
- 构建一个中间类A,该类在销毁执行dealloc时,顺便执行请求的cancel方法
- 通过asso