使用YTKRequest避免控制器退出后不马上被释放的问题
2017-08-21 18:03
232 查看
我们项目中的网络请求基类SomeRequest是封装自YTKRequest的,然后各个API再继承自这个基类,在控制器里面调用API的时候典型是这样写的:
并没有做任何别的处理。
这样的写法在有些情况下会造成控制器离开后,没有被释放。比如,网络很慢的情况,用户进入一个界面,开始执行一个api请求,然后,等了一会没看到请求数据,就返回退出界面。这时候,控制器的dealloc方法是不会走的,也就是控制器没有在退出后马上被释放,而是被api的success或failure的block引用着,等网络请求完成,调用完这这两个blocks之一后,才会走dealloc方法,释放控制器。这不是我们想要的结果,我们要在控制器退出离开后,就马上释放它。
既然,控制器是被api的blocks引用着才没有马上释放,那么在退出离开时要把这些blocks置为nil,它们就不会引用控制器了,也不会再被api请求完成后执行了。
针对YTKRequest的情况,具体做法分两步:
一,在控制器.m文件里面定义一个属性引用api对象。
二,针对返回退出的情况,在控制器的viewWillDisappear方法里面调用YTKRequest的stop方法。
测试证明,以上的写法保证了api无论有没有请求完成,在退出离开控制器时,控制器的dealloc方法都会被执行。
- (void)exeXXXApi{ xxxApi = [[XXXAPI alloc] initWithXXX]; [xxxApi startWithCompletionHandlerWithSuccess:^(__kindof ETopBaseRequest *_Nonnull request, id _Nonnull response) { }failure:^(__kindof ETopBaseRequest *_Nonnull request, NSInteger code, NSString *_Nonnull errorMsg) { }]; }
并没有做任何别的处理。
这样的写法在有些情况下会造成控制器离开后,没有被释放。比如,网络很慢的情况,用户进入一个界面,开始执行一个api请求,然后,等了一会没看到请求数据,就返回退出界面。这时候,控制器的dealloc方法是不会走的,也就是控制器没有在退出后马上被释放,而是被api的success或failure的block引用着,等网络请求完成,调用完这这两个blocks之一后,才会走dealloc方法,释放控制器。这不是我们想要的结果,我们要在控制器退出离开后,就马上释放它。
既然,控制器是被api的blocks引用着才没有马上释放,那么在退出离开时要把这些blocks置为nil,它们就不会引用控制器了,也不会再被api请求完成后执行了。
针对YTKRequest的情况,具体做法分两步:
一,在控制器.m文件里面定义一个属性引用api对象。
@interface SomeController() @property (nonatomic, strong) SomeRequest *api; @end @implimentation SomeController - (void)exeXXXApi{ self.api = [[XXXAPI alloc] initWithXXX]; [self.api startWithCompletionHandlerWithSuccess:^(__kindof ETopBaseRequest *_Nonnull request, id _Nonnull response) { }failure:^(__kindof ETopBaseRequest *_Nonnull request, NSInteger code, NSString *_Nonnull errorMsg) { }]; } @end
二,针对返回退出的情况,在控制器的viewWillDisappear方法里面调用YTKRequest的stop方法。
- (void)viewWillDisappear:(BOOL)animated{ // 导航后退离开界面 if (![[self.navigationController viewControllers] containsObject: self]) { // 离开界面调用这个方法,哪怕api的block与self之间有循环引用,也会释放self [self.api stop]; } [super viewWillDisappear:animated]; }
测试证明,以上的写法保证了api无论有没有请求完成,在退出离开控制器时,控制器的dealloc方法都会被执行。
相关文章推荐
- 关于GDI资源使用后未释放,导致GDI对象猛增,程序花屏,异常退出的问题
- 程序退出,阴魂不散?――解决Firebird嵌入式数据库无法正常释放的问题
- 上下文“0x20b1a0”已断开连接。正在从当前上下文(上下文 0x20ac98)释放接口。这可能会导致损坏或数据丢失。要避免此问题,请确保在应用程序全部完成 RuntimeCallableWrapper (表示其内部的 COM 组件)之前
- "无法使用前导.. 在顶级目录上退出"问题的解决
- 避免使用count(*)获得表的记录数,解决其延迟问题
- KILL SESSION 还存在而不马上释放得问题
- Vs2003使用时出现这个问题,正在郁闷中,网上找了好久,居然看到同样问题,马上拷贝来:)开心中
- 关于android应用程序使用ActivityManager退出的问题
- 使用pthread 线程退出时自动释放资源
- 使用NSKeyedArchiver保存数据导致程序退出问题
- android eclipse 解决使用布局查看器自动退出 的问题
- 使用JSP和Struts正确的解决用户退出问题
- 动态规划:0-1背包问题(使用迭代方法,避免重复计算)
- 避免使用count(*)获得表的记录数,解决其延迟问题
- 自动资源释放-使用对象管理资源,解决资源泄露问题
- 使用JSP和Struts正确的解决用户退出问题
- 解决问题:FileStream 将不会打开Win32设备(如磁盘分区和磁带机)。请避免在路径中使用“\\.\”
- 遇到了urlrewriter的:"无法使用前导.. 在顶级目录上退出"问题
- Android中application 全局变量 && 使用TAB页不能退出的问题
- 使用定时器解决对象事件中自释放的问题