关于如何写UI及屏幕适配的一些技巧

因为公司开启了一个新的iOS项目， 所以近期比较忙， 没有更新博客，今天打算总结一下关于UI布局及屏幕适配的一些实战技巧，尤其使用纯代码，会对提升效率及代码易于维护等方面有明显帮助，这里提到的没有使用任何Xib， 如果不是在外包公司，也推荐大家多使用甚至完全使用纯代码布局UI，优缺点下面会说明，本文布局使用masonry。货不太干，只是工作中的一点点小技巧与基础知识，大家可以来分享更多的技巧。

下篇地址：http://www.jianshu.com/p/0c1d76e7ea1a

提纲：
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类就不传了。。。

再提一下另外一个规范， “名字不要随便起，弄个坑爹名字，自己隔天都不知道啥意思，是跟公司结了仇了还是怕泄露天机”

不算特别不规范的命名

为什么说这些命名不是特别不规范， 因为这里面虽然有些vBack啦, lbl啦， tbl啦， 不是那么容易理解， 但是好歹是lbl，都用lbl了，不过为啥非得把Label放前面，官方命名的时候比如btn.titleLabel，Label也是放在后面的啊， 也没缩写成什么lbl，我们就简简单单的叫nickNameLabel不行吗。。。

说到命名就再多说一点， 如果一个复杂View内部布局的时候需要分割成几部分，在能想出名字的情况下最好不要按位置命名，比如topView，midView之类，明天产品说把位置调一下，最下面的部分比较重要提到最上面，这怎么办， 尽量想一想这部分大概负责什么，要表达个什么意思

3. UI工厂类 与 代码块

UI工厂类： 其实代码很简单，就是把对Label, Button等控件的属性赋值封装一下， 做到一行代码就能创建一个VIew， 如下图， 虽然这一句代码有点长， 但是习惯之后写个View是真心快

UI工厂类.h

UI工厂类.m

代码块： 代码块就是下图的东西， 应该没人不知道，不会添加隔壁百度

代码块

这个东西不光是UI布局用， 很多位置都比较方便， 我常用的有这样几个

懒加载

masonry定义过的一部分

masonry填空模式

尤其是纯代码masonry布局， 这样的代码块会让你布局的速度直逼甚至超越拖线， 只需要打出make就会出现已经定义好的各种约束， 比如要布局高度， 打出makeh， 回车， 就直接进入填空模式，tab切换填空即可

4. 懒加载， View使用strong还是weak

为什么要用懒加载， 有一种说法是用到的时候在创建，节省内存开销，这种说法固然没问题，但是对于大部分UI来说，基本迟早都会被创建。
所以，主要优点不在这里，本着<自己的事情自己做， 尽量不要影响他人>的做人原则，代码也该这样写，你既然是个View，那你就把自己解决好再来见我， 我要用你的时候只需要self.testView就可以了，下面两张图对比一下就会看到区别了，第二张为刚到公司时上一任的大作，这里选取了一种比较看的清的贴出来

弱引用懒加载 masonry布局

上图注意：masonry的block没有进行copy，即当前对象没有引用这个block，是局部的引用，不会形成循环引用的，可以不用weakSelf

混乱的还好的示例

对比一下即可看出来， 由于上图使用中的控件均使用懒加载， 所以布局方法里连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;

注意weakView为nil，strongView还存在

强指针View置空

下面图解一下， 为什么不置空， strongView就不被释放

强弱指针View实际区别

总结起来的话， 其实如果理解到位，使用强弱都没有问题，但是一般来说，由于弱引用会被及时的释放掉，所以需求允许的话，一般建议使用弱引用，那什么情况不能使用弱引用呢，这个要看具体需求，举个例子，如果一个View，需要从父View移除掉，但是之后还有可能加回来，还要保持移除之前的样子，这种情况强引用会更适合。

---

收集了一些意见：

1. 懒加载不一定一定要， 这是完全没问题的，有人习惯把创建View，属性赋值，添加到父视图的代码写在一起，认为这样便于管理，顺着看更清晰，没问题。
2. 如果View层次复杂，用懒加载弱引用View的时候注意层级关系，如果理解不到位，容易产生问题，因为addSubView写在懒加载里，极易造成层次不清晰，这时就要个人理解，用自己认为最适合的方法了。
3. 我为什么喜欢将UI写成懒加载？aView就是aView，bLabel就是bLabel，每个控件做好自己事情，给自己颜色字号都弄好了，等我要用你的时候，比如要往父视图添加了，拿来直接加就好，所以在添加View这个方法里都是添加，无关代码没有，要修改aView背景色，去找aView（aView的懒加载里面改）啊

文／CoderLXWang（简书作者）
原文链接：http://www.jianshu.com/p/bb021d4acc35
著作权归作者所有，转载请联系作者获得授权，并标注“简书作者”。

 

 

上篇发出之后收集了一些反馈， 总结起来以下几点：

1. 没有demo，代码没有全部粘上来。
   我认为这篇的内容不需要，不能我写个弱引用的懒加载怎么写，还一定要把声明weak属性的代码放上来吧。
2. 关于xib/strotyboard和纯代码
   我是两种用过，实际工作中也基本都达到了熟练的程度，现在使用纯代码也不是公司要求，自己觉得更好，其他的就不说了，这就相当于两条路都行的通，任意一条走成老司机了另一条也没问题，但是新人工作中最好纯代码为主。
3. 关于懒加载是否一定要
   理解到位想怎么搞怎么搞，萝卜青菜各有所爱。

---

提纲：上篇说到第4条
1. 关于xib/storyboard 与 纯代码的对比  
2. 一条规范（又提了一点关于命名的）
3. UI工厂类 与 代码块 4. 懒加载， View使用strong还是weak 5. 复杂界面要会分区，要会障眼法 6. masonry均布View，及其布局时约束依赖关系 7. 关于屏幕适配的一点技巧 8. 循环引用（上篇文章有人对循环引用不理解，虽然是基础，有人不理解还是说一下吧）

5. 复杂界面要会分区，要会用障眼法

分区：什么叫分区，其实就是封装，干啥其实都是一样，UI网络逻辑思路有相同的地方，就包括收拾东西，为啥很多人喜欢把各种东西用各种盒子装起来，假设现在要写一个aView，上面是这样的

一个View上的元素

这个要怎么写， 直接挨个创建直接往aView上加吗， 这以后维护起来改点东西相信你死的心都会有的，一般这种元素有点多的都要适当的分一下区

分区后

这样分区后，如图所示，写UI的时候就先依次单独解决好上中下三部分，然后需要做的就是对上中下三部分的整体进行布局，这一级布局的时候就完全可以忽略他们内部的东西是什么样的，全部完成整体微调，该调里面就里面， 该调整体就整体

障眼法： 所谓障眼法就是投机取巧，当然可以有各种各样的方法，把一些复杂功能简化，不管用了什么方法，最终看起来像是实现了就可以。
下面举个例子， 这个例子是项目中的一个界面， 我简化了一下抽出来， 这是一个消费记录的界面， 有个tableview，每个cell如下所示，可以展开收起

展开状态

收起状态

看到这样一个界面，首先不要考虑如何展开收起，就看一下展开的要怎么写，（演示Demo中的UI因为没有使用网络数据，也为了演示方便，做了简化，实际账单消费下面还有一部分如何消费，可获得什么等等的区域），参照上一条，这种一个View里元素较多的时候可以先分区如下：

按功能或者位置分区如图

先假设展开状态已经写好了，下面要考虑如何收起，观察UI发现收起状态的信息是展开状态中的主要信息， 如图元素其实表达的是同样信息

Paste_Image.png

那么难道要打破布局，将这几个view找到重新布局，其他的隐藏掉吗？那再点击回到展开状态怎么办，在重新布局？想想就麻烦

所以，这时再搞一个summaryView，负责收起的信息展示，这个View内部的时间桌号等控件，跟展开状态的时间桌号虽然长的一样，但是实际是两个不同的UI对象。

summaryView

所以完成之后，这个View里会有如下几大块

• summaryView (收起的View)
• expendBgView(展开时的整体View)
  • topView (这样命名不好)
  • midView

如此布局，在点击了View要展开/收起的时候，只需要转换summaryView和expendBgView的隐藏状态，改变一下最外层View的底部约束即可

demo地址：https://github.com/CoderLXWang/LayoutViewDemo

6. masonry均布View，及其布局时约束依赖关系

均布View： 等间距布局 - 从0开始说一下masonry的使用

约束依赖关系：这个标题其实比较宽泛，也说不好，如何写约束本身就是比较灵活的，每个人的写法可能都不一样，下面举两个例子大概说一下，
示例1：

示例1

这个很简单， 左右间距都是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.最小高度为图片高度，文字高度超度图片，就以文字高度为准

 

 

 

直接上代码，只为说明约束，不要找别的毛病，具体自己看吧，这里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)

举个例子

5s效果

不做比例的适配，在6p上如图

6p效果

其实也没啥问题，看起来也没有很不协调的地方，但是注意看一下券左右两条竖直虚线，会发现大屏上左面券命和右面打印的宽度会比较小，中间区域显得过大，应该稍微匀一点给左右两边，两边看起来会不那么挤，同时右侧点击范围也会相应放大，做法就是将左右约束的值*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); }];

乘上比例之后，效果如图

*KRATE后的6P效果

为什么会有这种问题产生， 其实也是由于个人的布局习惯引起的，在布局这个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)

拿一个界面举个例子，如图

5s效果

这里左右看起来窄窄的间距用的都是6dp，6dp如果直接*KRATE基本没用，乘完也就加一个dp，效果基本就是如下，屏幕很大，间距很小气，也许你会说小屏上也小气，设计说了，你不懂，正好

6P效果

如果将各处左右间距设置为

make.left.equalTo(ws.view).offset(6*KKRATE(1.8)); make.right.equalTo(ws.view).offset(-6*KKRATE(1.8));

效果如下

*KKRATE后6P效果

明显大气了许多。。。

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，看起来貌似循环成一个圈了，这就是循环引用吗？貌似怪怪的，因为少了一个引用

简单的循环引用？

实际上少了一个引用关系，没有考虑retainVC是那里来的，retainVC被创建之后加载nav导航栈里是被navController强引用的，这是我们就可以按ARC的原则分析了，就是看线，找实线，这里我们关心的是控制器会不会被正常释放，那我们就看控制器有几根实线，这时就会发现有两根，pop出去的时候，上面的那条nav的线断了，但是还有一条View的线，所以控制器就不会被释放

实际循环引用图示1

示例2：代理为什么用weak声明
如图就是代理为什么用弱引用，如果用强引用就变成示例1的情况了

代理用弱引用原因

示例3：一般使用block为什么注意循环引用，使用weakSelf
先说为什么block一定要用copy，既然会循环引用，那么就像代理一样，使用弱引用的指针不行吗？
详细看这篇文章吧 Block为什么使用copy修饰，
更详细可以看这篇谈Objective-C block的实现
总结起来就是为了使其存放在堆中，如果不copy一下，block是存放在栈中的，出了创建它的作用域，就可能被释放掉，但是用了copy，对这个block就是强引用，所以需要注意循环引用，使用weakSelf。
那什么是weakSelf，block默认对内部引用的外部变量是强引用，所以如果直接使用了self，则相当于block有一条实线（强指针）指向self，则self又有两条实线了

block为什么需要weakSelf

示例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及屏幕适配的一些技巧（上）

文／CoderLXWang（简书作者）
原文链接：http://www.jianshu.com/p/0c1d76e7ea1a
著作权归作者所有，转载请联系作者获得授权，并标注“简书作者”。