前言:

好久没写文章了,近来先是重构IT恋、又重写IT恋中。

Sagit框架也不断的立异,调节,未来认为已到家了了相当的多。

今天不写教程,先容易分享一下工夫内容。

陈说Sagit.Framework消除:双向引用导致的IOS内部存款和储蓄器泄漏(上),sagit.frameworkios

1:见Block必有:#define WeakSelf __weak typeof(self) this = self;

 轶事要从那这里提及:

bwin必赢 1

那儿番完那代码后,开掘所在都有其一鬼东西,然后就去百度了须臾间,然后大体是为着:

前言:

好久没写小说了,近期率先重构IT恋、又重写IT恋中。

Sagit框架也持续的翻新,调治,以后倍感已圆满了了相当多。

前几日不写教程,先轻松分享一动手艺内容。

化解双向引用导致的内部存款和储蓄器不能够自由难题

简易的发挥如下:

self   强引用指向=》block;

block 也强引用批向=>self;

那会儿就出事了,化解的章程是,把在那之中贰个改成弱指向。

而WeakSelf的定义,就是让block改成弱引用,这样无论self是不是强引用的指向block都无关紧要了。

当然,更精致的做法是:先预判self有没有强引用指向block,没有,就不用WeakSelf定义了。

不过,一般新手搞不明白内涵,无法做出有效的预判,所以见block就有WeakSelf也就相随相生了。

1:见Block必有:#define WeakSelf __weak typeof(self) this = self;

 传说要从那这里说到:

bwin必赢 2

那时候番完那代码后,发掘内地都有其一鬼东西,然后就去百度了瞬间,然后大体是为着:

2:别的场景的双向援用:UIViewController与UIView的纠缠

 首先,暗中认可UIViewController有二个强援用指向了UIView,那是系统定义的,我们改不了:

bwin必赢 3

故此,要是UIView里再冒出strong或retain指回UIController,就能促成UIViewController和UIView双双不能自由难点。

以此主题素材,在自个儿刚写Sagit框架时,只在意效能,没在意那么些,就犯了那几个指鹿为马:

荒谬的写法是如此的:

bwin必赢 4

今后核对后的写法是这么的:

bwin必赢 5

缓慢解决双向引用导致的内部存款和储蓄器不能自由难点

简易的发布如下:

self   强引用指向=》block;

block 也强引用批向=>self;

此时就出事了,化解的法子是,把里面一个改成弱指向。

而WeakSelf的定义,就是让block改成弱引用,这样无论self是不是强引用的指向block都无关紧要了。

当然,更精致的做法是:先预判self有没有强引用指向block,没有,就不用WeakSelf定义了。

不过,一般新手搞不明白内涵,无法做出有效的预判,所以见block就有WeakSelf也就相随相生了。

3:事情并未有这么简单:UIView子控件绑定事件指向Controller

看一行Sagit的代码,关切前边的addClick:

[[[[sagit addButton:@"Login" title:@"登录" font:40] width:450 height:80] onBottom:@"pwdLine" y:149] addClick:@"loginClick"];

对那一件事件流程关于Sagit的前方几篇有说了,这里说一下框架的流程代码:

1:系统自动添加了一个UITapGestureRecognizer,并指定到一个固定的click方法;

2:将方法名称和target存到自身的NSDictionary的字典中(框架为每个UIView都扩展了一个Dictionary)(就是这里造成强引用了Controller).

3:事件点击时:先触发系统默认的click,然后click事件:从字典里取出方法名和target,找到SEL并动态执行。

PS:设计成动态执行的好处:可以在执行前处理一些其它事情:比如将addClick参数:loginClick改成AgeButton.click,这样可以分解参数后,去执行AgeButton上的事件

实行的代码是那样的,由于是动态实施,少不了还应该有贰个警戒:

bwin必赢 6

2:别的场景的双向援引:UIViewController与UIView的缠绕

 首先,私下认可UIViewController有叁个强引用指向了UIView,这是系统定义的,大家改不了:

bwin必赢 7

之所以,尽管UIView里再出现strong或retain指回UIController,就能形成UIViewController和UIView双双不或然自由难点。

本条标题,在本身刚写Sagit框架时,只在意功效,没在意那个,就犯了那些错误:

破绽百出的写法是那样的:

bwin必赢 8

前几天校对后的写法是这般的:

bwin必赢 9

接下去,就是怎么消灭事件里对Controller的强援引:

1:找了资料,发现有个NSMapTable,是弱引用的字典,于是把NSDictionary换成它,结果:参不忍睹,界面错乱。【大概是弱引用特别容易丢失数据】 

2:尝试用一个全局的第三方的字典来存,结果也悲哀了!

3:最后想到了一个方法,不直接存Controller,只存字符串:1和0 ,在最终执行的时候,再去找。

代码是那样的:

bwin必赢 10

真难为笔者如此驾驭,想着水到渠成,运转,释放了,成功了!!!

然后又伤心了:

bwin必赢 11

然后就动不动就到main含数了,让自个儿怎么猜?说好的大局断点呢?你咋不断呢?

搜了搜百度,想想要调治内部存款和储蓄器,那就多少个蛋腾,依旧靠猜吧。

后来,依照释放的逐个,和最后的主要性字,大约是这样猜的:

控制器被释放了,这时候UIView还没释放,然后系统又给UIView绑字的事件发消息,结果遇到野指针,悲伤的故事发生了。

于是,笔者做了贰个困难的支配,在UIController的deallow中写了那样的代码:

-(void)dealloc
{
    [self.view removeAllsubViews];//处理内存释放后的异常。
    NSLog(@"%@ ->UIViewControlelr relase", [self class]);
}

这实行dealloc前,究竟Controller依然活着的,那时候赶紧把UIView的东西给清了,然后,发掘完美,运维起来很6!

3:事情并没有如此简单:UIView子控件绑定事件指向Controller

看一行Sagit的代码,关心前边的addClick:

[[[[sagit addButton:@"Login" title:@"登录" font:40] width:450 height:80] onBottom:@"pwdLine" y:149] addClick:@"loginClick"];

对那件事件流程关于Sagit的前面几篇有说了,这里说一下框架的流程代码:

1:系统自动添加了一个UITapGestureRecognizer,并指定到一个固定的click方法;

2:将方法名称和target存到自身的NSDictionary的字典中(框架为每个UIView都扩展了一个Dictionary)(就是这里造成强引用了Controller).

3:事件点击时:先触发系统默认的click,然后click事件:从字典里取出方法名和target,找到SEL并动态执行。

PS:设计成动态执行的好处:可以在执行前处理一些其它事情:比如将addClick参数:loginClick改成AgeButton.click,这样可以分解参数后,去执行AgeButton上的事件

实践的代码是那样的,由于是动态施行,少不了还也有三个警戒:

bwin必赢 12

总结:

当自身很6的化解完上述难点后,就起来写小说了想享受一下了,然后写了开班,开掘:

嘿,好像UITableView和UITableViewCell,好像也会有双向援引难题。

因为本人给Cell加了个属性,指向Table,运维,果然,Shit,连Controller和父的UIView都释放了,你UITableView做为子UI居然不自由!!!!

没天理,继续折腾,然后UITableView搞释放了,又发掘UITableViewCell不自由了(那么些Cell日常又会是一大堆UI)。

再然后,开采Push两层回来,又挂Crash了。

当今正在大力抢救!!!解决完再来写下篇!!!

 

操,开采为了释放这一点内部存款和储蓄器的代价,折腾起来真惨过不自由算了〜〜〜〜

接下去,正是怎么消灭事件里对Controller的强援引:

1:找了资料,发现有个NSMapTable,是弱引用的字典,于是把NSDictionary换成它,结果:参不忍睹,界面错乱。【大概是弱引用特别容易丢失数据】 

2:尝试用一个全局的第三方的字典来存,结果也悲哀了!

3:最后想到了一个方法,不直接存Controller,只存字符串:1和0 ,在最终执行的时候,再去找。

代码是那般的:

bwin必赢 13

真难为本身这么精通,想着马到功成,运行,释放了,成功了!!!

接下来又难过了:

bwin必赢 14

接下来就动不动就到main含数了,让自家怎么猜?说好的大局断点呢?你咋不断呢?

搜了搜百度,想想要调治内部存款和储蓄器,那就四个蛋腾,依然靠猜吧。

新生,依照释放的次第,和尾声的入眼字,大约是如此猜的:

控制器被释放了,这时候UIView还没释放,然后系统又给UIView绑字的事件发消息,结果遇到野指针,悲伤的故事发生了。

于是乎,作者做了四个劳苦的主宰,在UIController的deallow中写了如此的代码:

-(void)dealloc
{
    [self.view removeAllsubViews];//处理内存释放后的异常。
    NSLog(@"%@ ->UIViewControlelr relase", [self class]);
}

那实行dealloc前,终归Controller如故活着的,那时候赶紧把UIView的东西给清了,然后,开采完美,运行起来很6!

总结:

当作者很6的消除完上述难题后,就起来写小说了想分享一下了,然后写了起来,开采:

哎,好像UITableView和UITableViewCell,好像也可能有双向引用难题。

因为本身给Cell加了个属性,指向Table,运营,果然,Shit,连Controller和父的UIView都放出了,你UITableView做为子UI居然不自由!!!!

没天理,继续折腾,然后UITableView搞释放了,又发掘UITableViewCell不自由了(这些Cell平常又会是一大堆UI)。

再然后,开采Push两层回来,又挂Crash了。

先天正在大力抢救!!!消除完再来写下篇!!!

 

操,开采为了释放那一点内部存款和储蓄器的代价,折腾起来真惨过不自由算了〜〜〜〜

http://www.bkjia.com/IOSjc/1261174.htmlwww.bkjia.comtruehttp://www.bkjia.com/IOSjc/1261174.htmlTechArticle讲述Sagit.Framework解决:双向引用导致的IOS内存泄漏(上),sagit.frameworkios
前言: 好久没写小说了,最近先是重构IT恋、又重写IT恋中。 Sa…

相关文章