因为公司开启了一个新的iOS项目, 所以近期比较忙, 没有更新博客,今天打算总结一下关于UI布局及屏幕适配的一些实战技巧,尤其使用纯代码,会对提升效率及代码易于维护等方面有明显帮助,这里提到的没有使用任何Xib, 如果不是在外包公司,也推荐大家多使用甚至完全使用纯代码布局UI,优缺点下面会说明,本文布局使用masonry。货不太干,只是工作中的一点点小技巧与基础知识,大家可以来分享更多的技巧。
提纲:
1. 关于xib/storyboard 与 纯代码的对比
2. 一条规范(又提了一点关于命名的)
3. UI工厂类 与 代码块
4. 懒加载, View使用strong还是weak
5. 复杂界面要会分区,要会障眼法
6. masonry均布View,及其布局时约束依赖关系
7. 关于屏幕适配的一点技巧
1. 关于xib/storyboard 与 纯代码的对比
a. xib快,纯代码慢,但是在纯代码熟练的情况下, 并不会慢很多
b. xib不易于修改,怎么修改,就是今天让一个View上的元素这么排布,明天就要换种排布方式,后天又要加些东西。。。
c. xib不灵活,什么叫灵活,一个View上有10个元素, 其中5个都是不一定出现的,并且它们不是集中的布局在哪个位置, 乱七八糟的,多一个少一个布局还都有点影响,这就知道灵活的重要性了
d. xib不利于屏幕适配,怎么适配,5s上一个View距左10像素,产品说6p上就要距左20才协调,xib上拖线布局怎么搞,约束拖出来改变它吗,复杂View有10个需要这样处理的地方呢。。。
e. xib写多了纯代码手生,当然纯代码写多了,拖线也有点不熟练,这个不作为纯代码更好的原因。。。
f. 但是!面试的时候如果你说我xib用的多,纯代码布局有点不熟练, 不好意思, 拜拜(本人经历过),你说我都是纯代码布局的, xib会,不熟,大多公司听到以前都是纯代码,那没问题,因为他们公司也不用xib。。。
2. 一条规范(又提了一点关于命名的)
“ .h 和 .m 的类扩展里面不要随便加东西,尤其 .h 里的东西一定要是必须放在这里,放在别处不行,实在有不太重要还必须放在这的,打好注释 ”
这个东西无数次在项目中见到过随意在这加东西的做法, 刚写完当时还好, 一个月以后再看, 瞬间懵逼。。。
这是什么鬼。。。
当时为啥要写这个量。。。
这怎么还有个没用过的量。。。
这个东西要不要传, 为啥A类用的时候穿了, B类就不传了。。。
再提一下另外一个规范, “名字不要随便起,弄个坑爹名字,自己隔天都不知道啥意思,是跟公司结了仇了还是怕泄露天机”
![](http://upload-images.jianshu.io/upload_images/2162015-9c415a7de4ecd20c.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
为什么说这些命名不是特别不规范, 因为这里面虽然有些vBack啦, lbl啦, tbl啦, 不是那么容易理解, 但是好歹是lbl,都用lbl了,不过为啥非得把Label放前面,官方命名的时候比如btn.titleLabel,Label也是放在后面的啊, 也没缩写成什么lbl,我们就简简单单的叫nickNameLabel不行吗。。。
说到命名就再多说一点, 如果一个复杂View内部布局的时候需要分割成几部分,在能想出名字的情况下最好不要按位置命名,比如topView,midView之类,明天产品说把位置调一下,最下面的部分比较重要提到最上面,这怎么办, 尽量想一想这部分大概负责什么,要表达个什么意思
3. UI工厂类 与 代码块
UI工厂类: 其实代码很简单,就是把对Label, Button等控件的属性赋值封装一下, 做到一行代码就能创建一个VIew, 如下图, 虽然这一句代码有点长, 但是习惯之后写个View是真心快
![](http://upload-images.jianshu.io/upload_images/2162015-4724f8b0b1058e9e.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
![](http://upload-images.jianshu.io/upload_images/2162015-752f5478446f364c.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
代码块: 代码块就是下图的东西, 应该没人不知道,不会添加隔壁百度
![](http://upload-images.jianshu.io/upload_images/2162015-86b1e18f9c7557e6.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
这个东西不光是UI布局用, 很多位置都比较方便, 我常用的有这样几个
![](http://upload-images.jianshu.io/upload_images/2162015-bb6bc82c0cc1e261.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
![](http://upload-images.jianshu.io/upload_images/2162015-0b45d4237662c234.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
![](http://upload-images.jianshu.io/upload_images/2162015-2e9ed2d4d6b945e8.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
尤其是纯代码masonry布局, 这样的代码块会让你布局的速度直逼甚至超越拖线, 只需要打出make就会出现已经定义好的各种约束, 比如要布局高度, 打出makeh, 回车, 就直接进入填空模式,tab切换填空即可
4. 懒加载, View使用strong还是weak
为什么要用懒加载, 有一种说法是用到的时候在创建,节省内存开销,这种说法固然没问题,但是对于大部分UI来说,基本迟早都会被创建。
所以,主要优点不在这里,本着<自己的事情自己做, 尽量不要影响他人>的做人原则,代码也该这样写,你既然是个View,那你就把自己解决好再来见我, 我要用你的时候只需要self.testView就可以了,下面两张图对比一下就会看到区别了,第二张为刚到公司时上一任的大作,这里选取了一种比较看的清的贴出来
![](http://upload-images.jianshu.io/upload_images/2162015-b2514e2773f669e8.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
上图注意:masonry的block没有进行copy,即当前对象没有引用这个block,是局部的引用,不会形成循环引用的,可以不用weakSelf
![](http://upload-images.jianshu.io/upload_images/2162015-806a6349e80af3e1.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
对比一下即可看出来, 由于上图使用中的控件均使用懒加载, 所以布局方法里连addSubView都不用写了, 只需逐条布局即可, 下图中创建控件, 属性赋值, 添加到父视图的代码都混在一起, 并且还没有使用masonry, 用上之后只会更乱。。。
View使用strong还是weak: 关于这个问题,其实还是有很多可以说一下的地方
懒加载写法:
@interface ViewController ()
@property (nonatomic, weak) UIView *weakView;
@property (nonatomic, strong) UIView *strongView;
@end
@implementation ViewController
/**
UI控件使用弱引用创建方法
1. UIView *weakView = [[UIView alloc] init]; 这句必须声明一个局部变量, 不能用_weakView,
因为用 _weakView = [[UIView alloc] init], 等号右侧创建了一个View之后,给了一个弱引用持有,相当于没有持有,直接就释放掉了
而 UIView *weakView = [[UIView alloc] init],等号左侧的weakView默认是一个强引用,会暂时持有保住它,但是生命周期就在这个懒加载的大括号内,所有会有其他代码配合, 使这个View存活下来, 不被释放
2. _weakView = weakView; 这句代码为属性赋值, 以后在其他位置不管通过self.weakView还是_weakView才能找到这个View,
基本作用可以说等同于强引用的 _strongView = [[UIView alloc] init];
3. [self.view addSubview:weakView], 第一条注释中说了,UIView *weakView 的生命周期就是在这个{}内,那么如何保证出了括号依旧存在,就是要给这个View加到一个不会被释放的View(不一定强引用弱引用)上,即self.view, 这样就不会被释放掉了
*/
- (UIView *)weakView {
if (!_weakView) {
UIView *weakView = [[UIView alloc] init];
_weakView = weakView;
weakView.backgroundColor = [UIColor redColor];
[self.view addSubview:weakView];
}
return _weakView;
}
- (UIView *)strongView {
if (!_strongView) {
_strongView = [[UIView alloc] init];
_strongView.backgroundColor = [UIColor greenColor];
}
return _strongView;
}
布局时区别:
- (void)configView {
WeakSelf(ws);
//弱引用由于懒加载直接加到父视图上,所以点语法完了直接调用masonry布局方法即可
[self.weakView mas_makeConstraints:^(MASConstraintMaker *make) {
make.centerX.equalTo(ws.view);
make.top.equalTo(ws.view).offset(100);
make.size.mas_equalTo(CGSizeMake(100, 100));
}];
[self.view addSubview:self.strongView];
[self.strongView mas_makeConstraints:^(MASConstraintMaker *make) {
make.centerX.equalTo(ws.view);
make.bottom.equalTo(ws.view).offset(-100);
make.size.mas_equalTo(CGSizeMake(100, 100));
}];
}
移除之后的区别(重点,涉及到理解强弱指针):执行上述代码后,屏幕上出现一上一下两个View, 点击空白区域, 移除掉两个View, 1秒后看一下,1秒后看是因为, 出了这个方法, 也就是运行到结束的括号之后, 才会把View移除掉, 注意看坐下控制台两个View,weakView为nil, 即已被释放, strongView还是存在, 因为即使从父视图上移除, self本身对其还有一个强引用, 不会释放掉,那么如果想把这个View释放掉需要怎么办, 就是在[_strongView removeFromSuperview]
后面加一句_strongView = nil;
![](http://upload-images.jianshu.io/upload_images/2162015-980f7f8b8d685aae.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
![](http://upload-images.jianshu.io/upload_images/2162015-9320e145dfabf97c.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
下面图解一下, 为什么不置空, strongView就不被释放
![](http://upload-images.jianshu.io/upload_images/2162015-df7686b7905e5f92.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
总结起来的话, 其实如果理解到位,使用强弱都没有问题,但是一般来说,由于弱引用会被及时的释放掉,所以需求允许的话,一般建议使用弱引用,那什么情况不能使用弱引用呢,这个要看具体需求,举个例子,如果一个View,需要从父View移除掉,但是之后还有可能加回来,还要保持移除之前的样子,这种情况强引用会更适合。
收集了一些意见:
- 懒加载不一定一定要, 这是完全没问题的,有人习惯把创建View,属性赋值,添加到父视图的代码写在一起,认为这样便于管理,顺着看更清晰,没问题。
- 如果View层次复杂,用懒加载弱引用View的时候注意层级关系,如果理解不到位,容易产生问题,因为addSubView写在懒加载里,极易造成层次不清晰,这时就要个人理解,用自己认为最适合的方法了。
- 我为什么喜欢将UI写成懒加载?aView就是aView,bLabel就是bLabel,每个控件做好自己事情,给自己颜色字号都弄好了,等我要用你的时候,比如要往父视图添加了,拿来直接加就好,所以在添加View这个方法里都是添加,无关代码没有,要修改aView背景色,去找aView(aView的懒加载里面改)啊
原文链接:http://www.jianshu.com/p/bb021d4acc35
著作权归作者所有,转载请联系作者获得授权,并标注“简书作者”。
上篇发出之后收集了一些反馈, 总结起来以下几点:
- 没有demo,代码没有全部粘上来。
我认为这篇的内容不需要,不能我写个弱引用的懒加载怎么写,还一定要把声明weak属性的代码放上来吧。 - 关于xib/strotyboard和纯代码
我是两种用过,实际工作中也基本都达到了熟练的程度,现在使用纯代码也不是公司要求,自己觉得更好,其他的就不说了,这就相当于两条路都行的通,任意一条走成老司机了另一条也没问题,但是新人工作中最好纯代码为主。 - 关于懒加载是否一定要
理解到位想怎么搞怎么搞,萝卜青菜各有所爱。
提纲:上篇说到第4条
1. 关于xib/storyboard 与 纯代码的对比
2. 一条规范(又提了一点关于命名的)
3. UI工厂类 与 代码块
4. 懒加载, View使用strong还是weak
5. 复杂界面要会分区,要会障眼法
6. masonry均布View,及其布局时约束依赖关系
7. 关于屏幕适配的一点技巧
8. 循环引用(上篇文章有人对循环引用不理解,虽然是基础,有人不理解还是说一下吧)
5. 复杂界面要会分区,要会用障眼法
分区:什么叫分区,其实就是封装,干啥其实都是一样,UI网络逻辑思路有相同的地方,就包括收拾东西,为啥很多人喜欢把各种东西用各种盒子装起来,假设现在要写一个aView,上面是这样的
![](http://upload-images.jianshu.io/upload_images/2162015-efdc94d979ae15c0.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
这个要怎么写, 直接挨个创建直接往aView上加吗, 这以后维护起来改点东西相信你死的心都会有的,一般这种元素有点多的都要适当的分一下区
![](http://upload-images.jianshu.io/upload_images/2162015-ccb67423dacd664c.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
这样分区后,如图所示,写UI的时候就先依次单独解决好上中下三部分,然后需要做的就是对上中下三部分的整体进行布局,这一级布局的时候就完全可以忽略他们内部的东西是什么样的,全部完成整体微调,该调里面就里面, 该调整体就整体
障眼法: 所谓障眼法就是投机取巧,当然可以有各种各样的方法,把一些复杂功能简化,不管用了什么方法,最终看起来像是实现了就可以。
下面举个例子, 这个例子是项目中的一个界面, 我简化了一下抽出来, 这是一个消费记录的界面, 有个tableview,每个cell如下所示,可以展开收起
![](http://upload-images.jianshu.io/upload_images/2162015-82aa4456a4c75494.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
![](http://upload-images.jianshu.io/upload_images/2162015-00452276a7a7b436.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
看到这样一个界面,首先不要考虑如何展开收起,就看一下展开的要怎么写,(演示Demo中的UI因为没有使用网络数据,也为了演示方便,做了简化,实际账单消费下面还有一部分如何消费,可获得什么等等的区域),参照上一条,这种一个View里元素较多的时候可以先分区如下:
![](http://upload-images.jianshu.io/upload_images/2162015-fbc1f350b3b24eb2.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
先假设展开状态已经写好了,下面要考虑如何收起,观察UI发现收起状态的信息是展开状态中的主要信息, 如图元素其实表达的是同样信息
![](http://upload-images.jianshu.io/upload_images/2162015-482fa761716dcf37.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
那么难道要打破布局,将这几个view找到重新布局,其他的隐藏掉吗?那再点击回到展开状态怎么办,在重新布局?想想就麻烦
所以,这时再搞一个summaryView,负责收起的信息展示,这个View内部的时间桌号等控件,跟展开状态的时间桌号虽然长的一样,但是实际是两个不同的UI对象。
![](http://upload-images.jianshu.io/upload_images/2162015-a2af4a685f8bca01.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
所以完成之后,这个View里会有如下几大块
- summaryView (收起的View)
- expendBgView(展开时的整体View)
- topView (这样命名不好)
- midView
如此布局,在点击了View要展开/收起的时候,只需要转换summaryView和expendBgView的隐藏状态,改变一下最外层View的底部约束即可
demo地址:https://github.com/CoderLXWang/LayoutViewDemo
6. masonry均布View,及其布局时约束依赖关系
均布View: 等间距布局 - 从0开始说一下masonry的使用
约束依赖关系:这个标题其实比较宽泛,也说不好,如何写约束本身就是比较灵活的,每个人的写法可能都不一样,下面举两个例子大概说一下,
示例1:
![](http://upload-images.jianshu.io/upload_images/2162015-755b27a5e77be2ab.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
这个很简单, 左右间距都是30,第二三四行View的左右约束该怎么写,都写下面的吗?这样写如果要改这个30,就瞎了
make.left.equalTo(父视图).offset(30);
make.right.equalTo(父视图).offset(-30);
因为这里的设计就是左右都要对其,所以下面都都依靠第一个布局即可,第二行两个不是左右都对其
make.left.right.equalTo(父视图).offset(第一个View);
代码少了一行是其次,主要是改的话只改一个,也可以透过代码看到这个地方的设计
注:这个示例很简单,勿喷,主要说这种做法,复杂布局也需要考虑到底依靠那个View布局,具体体况多体会,简单说就是要选取合适的依赖对象
示例2:
需求:
1.整体居中
2.宽度可变,看文字是否够一行,最宽左右内边距10
3.内部两个View的centerY对其
4.最小高度为图片高度,文字高度超度图片,就以文字高度为准
![](http://upload-images.jianshu.io/upload_images/2162015-a39675f6c7fb4451.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
![](http://upload-images.jianshu.io/upload_images/2162015-0ca92afac73c915d.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
![](http://upload-images.jianshu.io/upload_images/2162015-ee1654c03f4cef7e.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
直接上代码,只为说明约束,不要找别的毛病,具体自己看吧,这里Label和ImageView一定要作为一个整体(即放到同一个父视图中),内部因为图片相对固定,左右尺寸都不变,要先布局图片才可以,否则Label没有可以依赖的东西
@interface ViewController ()
@property (nonatomic, strong) UIView *containerView;
@end
@implementation ViewController
- (UIView *)containerView {
if (!_containerView) {
_containerView = [[UIView alloc] init];
_containerView.backgroundColor = [UIColor orangeColor];
UIImageView *imgView = [[UIImageView alloc] init];
imgView.image = [UIImage imageNamed:@"demo1.jpeg"];
[_containerView addSubview:imgView];
[imgView mas_makeConstraints:^(MASConstraintMaker *make) {
make.right.equalTo(_containerView).offset(0);
make.size.mas_equalTo(CGSizeMake(100, 100));
make.centerY.equalTo(_containerView);
}];
UILabel *label = [[UILabel alloc] init];
label.numberOfLines = 0;
label.text = @"这是阿三冲击红进口付出dsk红进口付出ds口付出dsk红进口付出dskjfhks口付kjfhks口付出dskj红进口付出dskjfhks口付出dskjjfhks口付出dskjfhd付出dsk红进口付出ds口付出dsk红进口付出dskjfhks口付kjfhks口付出dskj红进口付出dskjfhks口付出dskjjfhks口付出dskjfhdjfhdksjhfdk";
[_containerView addSubview:label];
[label mas_makeConstraints:^(MASConstraintMaker *make) {
make.right.equalTo(imgView.mas_left).offset(-20);
make.left.equalTo(_containerView).offset(0);
make.bottom.top.equalTo(_containerView).offset(0);
make.height.mas_greaterThanOrEqualTo(100);
}];
}
return _containerView;
}
- (void)viewDidLoad {
[super viewDidLoad];
[self.view addSubview:self.containerView];
[self.containerView mas_makeConstraints:^(MASConstraintMaker *make) {
make.top.equalTo(self.view).offset(200);
make.centerX.equalTo(self.view);
make.width.mas_lessThanOrEqualTo([UIScreen mainScreen].bounds.size.width-20);
}];
}
7. 关于屏幕适配的一点技巧
首先说一个屏幕适配到底是什么, 工作中很多人,甚至产品都搞错了
所谓屏幕适配,并不是大屏就要将UI变大,而是要显示更多的内容。
再说一个关于按钮的写UI原则
按钮设计的大没啥可说,如果设计的按钮很小,到程序员手里一定要让它看起来小,点起来大
KRATE :当然在这一基本原则下,有的时候大屏上的某些元素和小屏保持同样大小会有一些难看,这时还是要分别对待,如果以5s屏幕尺寸为基准(也有用6的尺寸做基准的,都一样,习惯问题),这里一般会定义这样一个宏
#define KRATE (SCREEN_WIDTH/320.0)
举个例子
![](http://upload-images.jianshu.io/upload_images/2162015-84a9afd136374c97.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
不做比例的适配,在6p上如图
![](http://upload-images.jianshu.io/upload_images/2162015-4e6071fc1d80a6ca.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
其实也没啥问题,看起来也没有很不协调的地方,但是注意看一下券左右两条竖直虚线,会发现大屏上左面券命和右面打印的宽度会比较小,中间区域显得过大,应该稍微匀一点给左右两边,两边看起来会不那么挤,同时右侧点击范围也会相应放大,做法就是将左右约束的值*KRATE
[self.leftLine mas_makeConstraints:^(MASConstraintMaker *make) {
make.left.equalTo(self.bgView).offset(80*KRATE);
make.top.equalTo(self.bgView).offset(15);
make.bottom.equalTo(self.bgView).offset(-15);
make.width.mas_equalTo(1);
}];
[self.rightLine mas_makeConstraints:^(MASConstraintMaker *make) {
make.right.equalTo(self.bgView).offset(-40*KRATE);
make.top.bottom.equalTo(self.bgView).offset(0);
make.width.mas_equalTo(1);
}];
乘上比例之后,效果如图
![](http://upload-images.jianshu.io/upload_images/2162015-1136273f9ff7cde3.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
为什么会有这种问题产生, 其实也是由于个人的布局习惯引起的,在布局这个UI时,我是先将左右两条虚线定位好,内部的东西根据虚线的位置确定,而虚线的位置就是一块白色背景左右给定值布局的,所以换到大屏会左右宽度不变,这种情况乘个KRATE就可以了。
麻烦有些人不要来喷啥你写就不会有这个问题,按比例分区怎样的,那是你的方法,你要是按比例分区不也要想到底给0.几的比例吗,要是竖直方向在scollView里也有这个问题呢
KKRATE:因为KRATE是用不同屏幕的宽度算出的一个系数,假设某个宽度5s上宽度为10,KRATE后6上则为10375/320=11.7, 也就是屏幕大1号之后原本为10的宽度增大了1.7, 那么这个宽度如果是40呢,40*374/320 = 46.9。
为了解决小宽度 ×KRATE基本没效果或者宽度大 ×KRATE 又过分了的问题,又定义了这样一个宏,给KRATE在乘一个自己制定的系数,感觉没效果就给KKRATE传个大于1的系数,感觉过分了就KKRATE(0.95),这里注意传入的系数小于0.86就反而大屏UI更小了,这里不想在里面继续写个三目运算符判断了,就这样了
/** 在屏幕比例基础上再次比例, 大于0.86, 否则反而变小 */
#define KKRATE(rate) (KRATE > 1 ? KRATE*rate : KRATE)
拿一个界面举个例子,如图
![](http://upload-images.jianshu.io/upload_images/2162015-1153e31e833c7062.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
这里左右看起来窄窄的间距用的都是6dp,6dp如果直接*KRATE基本没用,乘完也就加一个dp,效果基本就是如下,屏幕很大,间距很小气,也许你会说小屏上也小气,设计说了,你不懂,正好
![](http://upload-images.jianshu.io/upload_images/2162015-5a472b7eed866be1.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
如果将各处左右间距设置为
make.left.equalTo(ws.view).offset(6*KKRATE(1.8));
make.right.equalTo(ws.view).offset(-6*KKRATE(1.8));
效果如下
![](http://upload-images.jianshu.io/upload_images/2162015-fb8b3274df7bd3a2.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
明显大气了许多。。。
8. 循环引用(上篇文章有人对循环引用不理解,虽然是基础,有人不理解还是说一下吧)
这部分是计划外的,因为上篇有不少同学问起这个东西,发现不少人对看似简单的循环引用概念还是比较模糊,所以我就拿出来说一下,我会分别解释一下常见的循环引用,以及代理,block中的循环引用问题,这里只做理解解释,没有深入研究,大神直接略过吧。
先说一下内存管理,大家都知道内存管理在MRC下要手动写retain,release等代码,操作一个对象的引用计数,以此控制对象持有及释放,ARC下编译器会自动添加retain/release等代码,ARC的一个基本规则就是,只要某个对象被任一strong指针指向,那么它将不会被销毁。如果对象没有被任何strong指针指向,那么就将被销毁。
所以当前我们的代码基本都是ARC,当我们研究一个对象是否循环引用时,也就不考去考虑计数到底为几,什么时候retain,什么时候release,我们只需要按照ARC的基本原则关心指向这个对象的strong指针。
下面就按这个基本原则解释一下循环引用,观察是否释放在控制器打印dealloc方法即可
示例1:简单粗暴无逻辑演示
有一个控制器SampleRetainCycleController *retainVC
,retainVC.view
上面有个SampleRetainCycleView *testView
,testView
有个强引用指针,指向retainVC
,看起来貌似循环成一个圈了,这就是循环引用吗?貌似怪怪的,因为少了一个引用
![](http://upload-images.jianshu.io/upload_images/2162015-66cb1d3258d4f53f.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
实际上少了一个引用关系,没有考虑retainVC是那里来的,retainVC被创建之后加载nav导航栈里是被navController强引用的,这是我们就可以按ARC的原则分析了,就是看线,找实线,这里我们关心的是控制器会不会被正常释放,那我们就看控制器有几根实线,这时就会发现有两根,pop出去的时候,上面的那条nav的线断了,但是还有一条View的线,所以控制器就不会被释放
![](http://upload-images.jianshu.io/upload_images/2162015-333e5ce9a0c5e2b1.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
示例2:代理为什么用weak声明
如图就是代理为什么用弱引用,如果用强引用就变成示例1的情况了
![](http://upload-images.jianshu.io/upload_images/2162015-c7eba3908fdbfac7.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
示例3:一般使用block为什么注意循环引用,使用weakSelf
先说为什么block一定要用copy,既然会循环引用,那么就像代理一样,使用弱引用的指针不行吗?
详细看这篇文章吧 Block为什么使用copy修饰,
更详细可以看这篇谈Objective-C block的实现
总结起来就是为了使其存放在堆中,如果不copy一下,block是存放在栈中的,出了创建它的作用域,就可能被释放掉,但是用了copy,对这个block就是强引用,所以需要注意循环引用,使用weakSelf。
那什么是weakSelf,block默认对内部引用的外部变量是强引用,所以如果直接使用了self,则相当于block有一条实线(强指针)指向self,则self又有两条实线了
![](http://upload-images.jianshu.io/upload_images/2162015-cff4df60e9995356.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
示例4:什么样的block不会造成循环引用
最常见的就是系统的一些block与masonry,系统的比如:
[UIView animateWithDuration: animations:^{
}];
首先是self(假设是当前的控制器)并没有copy(强引用)这个block,其次这还是个类方法,类方法里不能对属性进行复制,即也不能强引用这个block,所以直接用self(即block对self强引用)也不会形成循环引用
再比如masonry
[self.containerView mas_makeConstraints:^(MASConstraintMaker *make) {
}];
看一下mas_makeConstraints是怎么写的
- (NSArray *)mas_makeConstraints:(void(^)(MASConstraintMaker *))block {
self.translatesAutoresizingMaskIntoConstraints = NO;
MASConstraintMaker *constraintMaker = [[MASConstraintMaker alloc] initWithView:self];
block(constraintMaker);
return [constraintMaker install];
}
只有第三行执行了一下这个block,并没有任何引用的代码(即类似self.xxblock = block),所以根据上面的几篇文章,这种block是存放在栈上的,出了作用域(即这个方法)就会被释放掉,既然block都被释放掉了,自然不会循环引用。
demo地址:https://github.com/CoderLXWang/RetainCycleDemo
上篇地址:关于如何写UI及屏幕适配的一些技巧(上)
原文链接:http://www.jianshu.com/p/0c1d76e7ea1a
著作权归作者所有,转载请联系作者获得授权,并标注“简书作者”。