Halfrost's Field | 冰霜之地

一缕殇流化隐半边冰霜

嗨,我是冰霜 (@halfrost),一名来自中国的 iOS 开发者,已退役 acmer 。现居上海。吾笃信:德不孤,必有志,技不疏,必有朋。


WWDC2016 Session笔记 - Xcode 8 Auto Layout新特性

目录

  • 1.Incrementally Adopting Auto Layout
  • 2.Design and Runtime Constraints
  • 3.NSGridView
  • 4.Layout Feedback Loop Debugging

一.Incrementally Adopting Auto Layout

Incrementally Adopting Auto Layout是什么意思呢?在我们IB里面布局我们的View的时候,我们并不需要一次性就添加好所有的constraints。我们可以一步步的增加constraints,简化我们的步骤,而且能让我们的设置起来更加灵活。

再谈新特性之前,先介绍一下这个特性对应的背景来源。

有这样一种场景,试想,我们把一个view放在父view上,这个时候并没有设置constraints,当我们运行完程序,就会出现下图的样子。

看上去一切都还正常。但是一旦当我们把设备旋转90°以后,就会出现下图的样子。

这个时候可以发现,这个View的长,宽,以及top和left的边距都没有发生变化。这时我们并没有设置constraints,这是怎么做到的呢?

在程序的编译期,Auto Layout的引擎会自动隐式的给View加上一些constraints约束,以保证View的大小不会发生变化。这个例子中,View被加上了top,left,width,height这4个约束。

如果我们需要更加动态的resize的行为,就需要我们在IB里面自定义约束了。现在问题就来了,有没有更好的方式来做这件事情?最好是能有一种不用约束的方法,也能达到简单的resize的效果。

现在这个问题有了解决办法。在Xcode8中,我们可以给View指定autoresizing masks,而不用去设置constraints。这就意味着我们可以不用约束,我们也能做到简单的resize的效果。

在Autolayout时代之前,可能会有人认出这种UI方式。这是一种Springs & Struts的UI。我们可以设定边缘约束(注:这里的约束并不是指的是Autolayout里面的constraints,是autoresizing masks里面的规则),无论View的长宽如何变化,这些View都会跟随着设置了约束的view一起变化。

上述的例子中,Xcode 8 中在没有加如何constraint就可以做到旋转屏幕之后,View的边距并没有发生变化。这是怎么做到的呢?事实上,Xcode 8的做法是先取出autoresizing masks,然后把它转换成对应的constraints,这个转换的时机发生在Runtime期间。生成对应的constraints是发生在运行时,而不是编译时的原因是可以给我们开发者更加便利的方式为View添加更加细致的约束。

在View上,我们可以设置translatesAutoresizingMaskIntoConstraints属性。

translatesAutoresizingMaskIntoConstraints == true  

假设如果View已经在Interface Builder里面加过constraints,“Show the Size inspector”面板依旧会和以前一样。点击View,查看给它加的所有的constraints,这个时候Autoresizing masks就被忽略了,而且translatesAutoresizingMask的属性也会变成false。如下图,我们这个时候在“Show the Size inspector”面板上面就已经看不到AutoresizingMask的设置面板了。

上图就是在Autolayout时代之前,我们一直使用的是autoresizing masks,但是Autolayout时代来临之后,一旦勾选上了这个Autolayout,之前的AutoresizingMask也就失效了。

回到我们最原始的问题上来,Xcode 8 现在针对View可以支持增量的适用Autolayout。这就意味着我们可以从AutoresizingMask开始,先做简单的resize的工作,然后如果有更加复杂的需求,我们再加上适当的约束constraints来进行适配。简而概之,Xcode 8 Autolayout ≈ AutoresizingMask + Autolayout 。

接下来用一个demo的例子来说明一下Xcode 8 Autolayout新特性。
在说例子之前我们先来说一下Xcode 8在storyboard上新增了哪些功能。如下图,我们可以看到,在最下方新增加了一栏,可以切换不同的屏幕大小,可以看出,iPhone现在已经分化成6种屏幕大小需要我们适配了,从大到小,依次是:iPad pro 12.9, iPad 9.7 , iPhone 6s Plus/iPhone 6 Plus , iPhone 6s/iPhone 6, iPhone SE/iPhone5s/iPhone5, iPhone4s/iPhone4。下面还可以选择横竖屏,和不用屏幕百分比的适应性。

回到例子,我们现在对页面上这些view来做简单的AutoresizingMask。右边的那个预览界面是可以看到我们加上这些Mask之后的效果。

先是粉色的父View,我们给它加上如下的AutoresizingMask。

给”雨天”的imageView加上如下AutoresizingMask

给”阴天”的imageView加上如下的AutoresizingMask

最后给我们的中间的Label加上AutoresizingMask

这个时候我们旋转一下屏幕,一切正常,View的排版都如我们所愿。

这个时候我们再选择一下,3:2分屏,这个时候就出现了不对的情况了。Label的Width被挤压了。

原因是因为Autoresizing masks并不会向Autolayout一样,会考虑View的content,所以这里被挤压了。

想fix这个Label,我们可以很容易的添加一个constraints来修复。不过这里我们来谈谈另外一种做法。

进入到Attributes Inspector面板,找到Autoshrink属性,把“fixed font size”切换成“minimum font size”

这个时候就fix上述的问题了。

此时就算是回到landscape,分屏的情况下,已经可以显示正常。

接着我们再来处理一下中间的温度的Label。这个时候我们有比较复杂的需求。这个时候我们就需要用到constraint了。

这个时候我们按时control键,然后拖到父View上,释放,会弹出菜单。我们再按住shift,这样我们可以一次性选择多个constraints。

我们一次性选择“Center Horizontally in Container” 和 “Center Vertically in Container”。注意这个时候右边还是AutoresizingMask的面板,因为这个时候Label还没有任何的constraint。当我们点击“Add Constraints”的时候,就给Label加上了约束,右边的面板也变成了constraints面板了。

我们再给这个Label继续加2个constraints。“Horizontal Spacing”和“Baseline”。

同样的,从Label拖拽到“太阳”的那个imageView上,再添加“Horizontal Spacing”和“Baseline”约束。

这个时候我们更新一下frame。如下图所示,选择“Update Frames”,这个时候所有的frame就都完成了。

这个时候我们更新一下中间温度的Label的字体大小,这时候计算变大,由于我们的constraints都是正确的,两边的View也会随着Label字体变大而变大。

Xocde 8在这个时候就变得更加智能了,会立即自动更新frame。

我们在继续给晴天的上海加上一个背景图。添加一个imageView,然后大小铺满整个父View,把mode 选择成“Aspect Fill”

接下面一般的做法就是在这个imageView上面添加constraints,来使这个View和父View大小一样。但是这种简单的resize的行为在Xocde 8里面就不需要再添加Constraint了,这里我们改用Autoresizing masks来实现。给imageView添加一下这些mask。

我们把imageView放到背景去。这时,我们所有的界面就布局完成了。

测试一下横屏的效果

甚至分屏的一样可以完成任务!

Demo的Github地址,这个demo没啥难的,就是看看效果。

这就是Xcode 8 的Incrementally Adopting Auto Layout,Autoresizing masks + Auto Layout Constraint 一起协同工作!

二.Design and Runtime Constraints

在我们开发过程中有这样一种情况,View的constraints会依据你所加载的数据来添加的。所以在app运行之前,我们是无法知道所有的constraints的。

这里有3种方法可以对应以上的情况。

1.Placeholder Constraints

假设现在我们需要把一张图片放在View的垂直和水平的中间,并且距离左边的边缘有一个leading margin。并且还需要保持其长宽的比例。而这种图片的最终样子,我们并不知道。只有到运行时,我们才能知道这样图片的样子。

为了能在Interface Builder看到我们的图片,我们要先预估一下图片的长宽比例。假设我们估计为4:3。这时候就给图片加上constraints,并且勾上“place order constraint”,这个约束会在build time的时候被移除。

当我们在运行时拿到图片之后,这个是时候我们再给它加上适当的约束和长宽比例即可。

2.Intrinsic Content Size

还是类似上面那种场景,我们有时候会自定义一些UIView或者NSView,这些View里面的content是动态的。Interface Builder并不会运行我们的代码,所以不到app运行的时候我们并不知道里面的大小。我们可以给它设置一个内在的content的大小。

Setting a design time intrinsic content size only affects a view while editing in Interface Builder.The view will not have this intrinsic content size at runtime.

注意一下上面的说明intrinsic content size仅仅相当于是在布局的时候一个placeholder,在运行时这个size就没有了。所以如果开发过程中真的需要用到这个内在的content的大小,那么我们需要overriding的content size

override var intrinsicContentSize: CGSize  
3.Turn Off Ambiguity Per View

这个是Xcode 8的一个新特性。当上述2种方法都无法解决我们的需求的时候。这个时候就需要用到这种方法了。Xcode 8给了我们可以在constraints产生歧义的时候,可以动态调整警告级别的能力。

在这个场景中,我们仅仅只知道我们需要把这个imageView放在水平位置的中央,但是imageView的大小和它的水平位置我们并不知道。如果我们仅仅只加上了这一个约束的话,Interface Builder就会报红,因为IB这时候根据我们给的constraints,并不能唯一确定当前的view的位置。

如果我们在之后的运行时,拿到图片的完整信息之后,我们自己知道该如何去加constraints,我们知道该如何去排版保证imageView能唯一确定位置的时候,这时我们可以关掉IB的红色警告。找到“Ambiguous”,这里是警告的级别,我们这里选择“Never Verify”,这时就没有红色的警告和错误提醒了。但是选择这一项的前提是,我们能保证之后运行时我们可以加上足够的constraints保证view的位置信息完整。

以上3种方法就是我们在运行时给view增加constraints的解决办法。

三.NSGridView

这是macOS给我们带来的一个新的layout容器。

有时候我们为了维护constraints的正确性是件比较麻烦的事情,比如即使我们就是一组简单的checkboxes,维护constraints也不容易。这个时候我们会选择用stack view来让我们开发更容易一些。

下图是macOS的app常见到的一组checkboxes。

这时候我们选用NS/UIStackView来实现,因为它有以下的优点,它可以排列一组items,重要的是它可以处理好content size并且可以控制好每个item之间的spacing。

但是stack view依旧有一些场景无法很顺手的处理。例如下图的场景。

这时依旧可以用stack view来实现,但是它不能帮我们根据content完成行和列的对齐。

这就是为什么要引入新的NSGridView的原因。

使用NSGridView,我们可以很容易的做到content在X轴和Y轴上的对齐。仅仅只需要我们把content放进预先定义好的网格中即可,NSGridView会帮我们管理好接下来对齐的一切事情。

我们来看看下面的例子。

NSGridView有2个子类,NSGridRow 和 NSGridColumn,它们俩会自动的管理好content的大小。当然我们可以在需要的时候指定size的大小,padding和spacing的大小。我们也可以动态的隐藏一些rows行和colunms列。

NSGridCell的工作就是管理每个cell里面content view的layout。如果某个cell的内容超出cell的边界,cell会合并起来,就像普通的电子表格app的做法一样。

我们来构建一个简单的界面。设计图如下:

我们并不需要去关心网格的sizing,我们只用关心每一行每一列究竟有多少个content需要被显示出来。

let empty = NSGridCell.emptyContentView  
let gridView = NSGridView(views: [
 [brailleTranslationLabel, brailleTranslationPopup], 
 [empty, showContractedCheckbox], 
 [empty, showEightDotCheckbox], 
 [statusCellsLabel, showGeneralDisplayCB],
 [empty, textStyleCB], 
 [showAlertCB] 
])

用上述代码运行出来的界面是这样的:

虽然我们调用构造函数没错,但是出来的界面和设计的明显有一些差距。最明显的问题就是UI被拉开了,有很多空白的地方。

产生问题的原因就在于,网格被约束到了window的边缘。我们的意图应该是window来匹配我们的网格大小,但是现在出现的问题变成了,网格被拉伸了,去匹配window的大小了。

我们解决这个问题的办法就是去改变 grid view内容的hugging的优先级。尽管页面上的constraints已经具有了高优先级,但是我们现在仍可以继续提高优先级,来让constraints推动content,使其远离window的边缘。我们提高一些优先级:

gridView.setContentHuggingPriority(600, for: .horizontal)
gridView.setContentHuggingPriority(600, for: .vertical)

我们会发现,window里面的content更加聚合了,中间的大段空白消失了。

我们再来解决一下window中间的空白,左边的label和右边的content距离太远。根据设计,我们应该让label居右排列。这件事很容易,只要我们调整一下cell的位置信息即可完成。排列的位置信息会影响到cell,行,列,网格视图。

如果没有指定cell的placement这个属性值,那么行列就会根据gridview的placement属性值来确定。这个规则可以使我们在一处设定好placement,瞬间可以改变大量的cell的布局。

//first column needs to be right-justified:
gridView.column(at: 0).xPlacement = .trailing

我们找到gridView的第一列,改变它的xPlacement属性值,这样一列的cell都会变成居右排列。

居右之后,我们又会出现新的问题,baseline不对齐了。

行的对齐和列的对齐原理一样的,同理,我们只需要设置一处,将会影响整个网格视图。

// all cells use firstBaseline alignment
gridView.rowAlignment = .firstBaseline

设置完成之后,整个网格视图就对齐了。

接下来我们再来改变一下pop-up button的边距。

let row = gridView.cell(for: brailleTranslationPopup)!.row!
row.topPadding = 5
row.bottomPadding = 5

这里取第一行的做法也可以和之前取第一列的做法一样,直接取下标0的row即可。这里换一种更好的做法来做。在gridView里面找到包含pop-up button的cell,根据cell找到对应的row行。这种方式比直接去下标index的好处在于,日后如果有人在index 0的位置又增加了一行,那么代码就出错了,而我们这里的代码一直都不会出错,因为保证是取出了包含pop-up button的cell。所以代码里面尽量不要写死固定的index,这样以后维护起来比较困难。

同理,我们也给“status cells”也一起加上Padding

ridView.cell(for:statusCellsLabel)!.row!.topPadding = 6

这里需要对比一下padding 和 spacing的区别。

padding是针对每个行或者每个列之间的间距,我们可以增加padding来改变两两之间的间距。 spacing是针对整个gridview来说的,改变了它,将会影响整个网格视图的布局。

再来看看我们的设计图:

如果没有padding那么就是下图的样子:

如果没有spacing那么就会出现下图的样子:

如果spacing和padding都没有的话,那就都挤在一起了:

最后我们来处理一下最下面那一行包含checkbox的cell

这里就需要用到之前提到了,合并2个cell了。

// Special treatment for centered checkbox:
let cell = gridView.cell(for: showAlertCB)!
cell.row!.topPadding = 4
cell.row!.mergeCells(in: NSMakeRange(0, 2))

这里我们直接指出了,合并前2个cell。

执行完代码之后,就会是这个样子。

最后一行的cell就会横跨2个cell的位置。虽然占了2个cell的位置,但是它依旧还继承着第一列的居右的排列规则。

现在我们的需求是既不希望它居右,也不希望它居左。 checkbox其实是支持排列在2个列之间的,但是由于这相邻的2个列的宽度并不相等,所以gridview不知道该怎么排列了。这时就需要我们手动来改变布局了。

这里可能有人会想,直接把

cell.xPlacement = .none

把cell的xPlacement直接变成none,这样做会一下子打乱整个gridview的constraints布局,我们不能这样做。我们需要再继续给cell加上额外的constraints来维护整个gridview的constraints的平衡。

cell.xPlacement = .none
let centering = showAlertCB.centerXAnchor.constraint(equalTo: textStyleCB.leadingAnchor)
cell.customPlacementConstraints = [centering]

我们只需要在给出checkbox在x轴方面的锚点即可。这时候checkbox就会排列成我们想要的样子了。

至此,我们就完成了需求。总结一下,NSGridView是一个新的控件,能很好的帮助我们进行网格似布局。它能很快很方便的把我们需要展示的content排列整齐。之后我们仅仅只需要调整一下padding和spacing这些信息即可。

四.Layout Feedback Loop Debugging

有时候我们设置好了constraint之后,没有报任何错误,但是有些情况当我们运行起来的时候就有一堆constraint冲突在debug窗口里面,严重的还会使app直接崩溃。崩溃的情况就是遇到了layout feedback loop。

遇到这种情况,往往是发生在“过渡期”,开始或者结束的时候。如果说你点击了一个button,button相应了你的点击,但是之后button不弹起,一直保持着被按下的状态。

然后会观察到CPU使用率爆表,内存倍增,然后app就崩溃了,与此同时返回了一大堆的layout的栈回溯信息。

发生这个情况的原因是某个view的layout被一直执行,一直执行,陷入了死循环中。Runloop就不会停下,CPU的使用率会一直处于峰值。所有的消息都会被收集到自动释放的对象中去,消息一直发送,就会一直收集。所以内存也会倍增。

导致这个原因之一,是setNeedsLayout这个方法。

当其中一个view调用完setNeedsLayout之后,会传递到父视图继续调用setNeedsLayout,父视图的setNeedsLayout可能又会调用到其他视图的layout信息。如果我们能在这相互之后调用找到调用者,也就是那个view调用了这个方法,那我们就可以分析清楚这些setNeedsLayout从哪里来,到哪里去,就能找到死循环的地方了。

这些信息确实很难收集,这也是为何苹果要为我们专门开发这样一个工具,方便我们来调试,查找问题的原因。

开启这个工具的开关在“Arguments”选项里面。如下图。

-UIViewLayoutFeedbackLoopDebuggingThreshold 100 // 50...1000
-NSViewLayoutFeedbackLoopDebuggingThreshold 100 // 50...1000
// Logs to com.apple.UIKit:LayoutLoop or com.apple.AppKit:LayoutLoop

UIView是在iOS里面使用的,NSView是在macOS里面使用的。一旦我们开启了这个开关,那么layout feedback loop debugger就会开始记录每一个调用了setNeedsLayout的信息。

这里我给它设置了阀值是100。

如果发现在一个Runloop中,layout在一个view上面调用的次数超过了阀值,这里设置的是100,也就是说次数超过100,这个死循环还会在跑一小段,因为这个时候要给debugger一个记录信息的时间。当记录完成之后,就会立即抛出异常。并且信息会显示在logs中。log会被记录在com.apple.UIKit:LayoutLoop(iOS)/com.apple.AppKit:LayoutLoop(macOS)中

我们也可以打全局的异常断点exception break point。 在调试窗口也可以用LLDB命令po出一些调试信息。

接下来看2个实用的例子。

1.Upstream Geometry Change

这里有这么多个view,层级如上图。

现在右子串上面10个子view在一次的层级变化中,被移除了。

那么最上层圈起来的3个view都会被影响。于是这3个view的bounds就发生了变化。于是就会隐式的调用setNeedsLayout,来获取新的bounds的信息。(这里经过@kuailejim @冬瓜争做全栈瓜 和大神们实验,setNeedsLayout是需要我们开发者手动调用的,系统并不会在bounds改变的时候隐式调用setNeedsLayout方法)。当前view的bounds改变,但是如果父view没有layout完成,那么父view也会继续收到setNeedsLayout消息。这个消息就会一直被往上传递,直到传到最顶层的view,顶层的view layout完成之后,将会重置下面关联的view的bounds,调用layoutSubview()方法。这时候,死循环就产生了。

这3个view就是上面3个view,下面的view需要setNeedsLayout,需要获取最新的bounds信息,中间蓝色的view也同样需要setNeedsLayout,于是又会让上层的view调用setNeedsLayout()方法,这个时候死循环就产生了。上下各有2个环,共同的view就是中间蓝色的view。环内的view都在相互的请求setNeedsLayout(),并且在自己layout完成以后又会去重置关联的view的bounds。这就形成了triggers layout。

大家对这里产生2个环产生了极大的好奇,热烈讨论这里会产生环的情况。目前可以想到会产生环的场景是这样子的:在上面的3颗子树,当某种场景下,突然删掉了右边的子树,假设用户的屏幕现在是全屏,由于一下子突然删掉了一堆view,那么原来那里就会变成空白,这个时候开发者想要把其他的view平铺到屏幕上。这个时候就需要改变上面父view的bounds,最下面的view会代码里面手动调用上面蓝色的view,setNeedsLayout()方法,并且把蓝色view的bounds设置成全屏,由于蓝色view的bounds改变,这个时候开发者代码里面又手动调用了蓝色view的父view,去执行setNeedsLayout()方法。top view代码里面又写了bounds = origRect,这时候就触发了蓝色view的layout,更新bounds。这样就产生了循环。同理下面也会形成循环。这样就产生了2个死循环了。这些总结需要感谢@kuailejim @冬瓜争做全栈瓜 给出的指点。

这里是我们用工具收集到的log,第一行就是top-level view,接下来的就是递归的过程。往下看,我们会看见一些数字,这些数字就是view接到layout的次数,并且这些数字是有序的。一次死循环中这些数字就是循环时候的顺序。当然一个循环中,每个view可以是起点也可以是终点。这里我们默认把top view设置成起点。这样就可以向我们展示出死循环中一共牵扯进来了多少个view。

从log上看,上面有3个view,下面有10个view,加起来也不等于23,这是为什么呢?我们继续往下看log,来看看“Views receiving layout in order”这里面记录了些什么吧。

这里我们可以很明显的看到,view接收到layout的顺序,一共正好23个。也可以看出,在一起循环中,一个view接收到layout的次数不止一次。

如上图所标示的,有2段在循环,有10个view接收到layout之后,再是2个view,紧接着又是10个view,再是1个view。

回到最初我们使用这个工具的用途上来,最初我们使用这个工具是用来查看 top-level view 接收到setNeedsLayout消息到底从哪里来。继续往下查找,找到调用的栈信息那里。

从上往下看,前几行肯定都是UIViewLayoutFeedbackLoopDebugging的信息。往下看,看到第6行,可以看到DropShadowView接受到了信息,准备setBounds。回看之前的层级信息,我们会发现DropShadowView是TransitionView的子view。

引起DropShadowView触发setBounds的唯一途径是,它的父view,TransitionView触发了setNeedsLayout()方法。因为这个时候TransitionView还没有layout。

回到“geometry change records”,这个时候我们可以看到选中的这3行信息在一遍遍的循环。看第2行和第3行,我们可以看到是来自于TransitionView的layout。这时是合理的。再看第一行,会发现这个时候有一个TransitionView的子view调用了viewLayoutSubviews。

这个时候我们就定位到了bug的根源了,只要想方设法在layout的时候,不要改变superview的bounds即可以去掉这个死循环。

2.Ambiguous Layout From Constraints

在我们设置constraints约束的时候,常常会产生一些歧义的constraints。歧义的constraints通常不可怕,我们只需要稍稍做些调整,然后update all frame即可。

但是有如下的场景会导出形成环:

当你的view在旋转之后,constraints也随之变化,然后有些view在旋转之后的constraint就会相互冲突。因次有些constraint就形成了环。

这个问题在没有这个debugger工具的时候,思考起来很烧脑,没有任何头绪,这也是为什么log把top-level view放在第一行的原因,给我们暗示,从这里开始找bug的原因。

在log,我们会看到好多的“Ambiguous Layout”。注意:tAMIC是Translates Auto Resizing Mask into Constraints的缩写。

我们来看看详细的log。看log之前,我们应该知道,constraint虽然冲突很多,但是可能引起冲突的constraint只有一个,也就是说当我们更正了其中一个constraint,很可能所有的冲突都解决了。 如上图log所示,在minX这里我们设置了2个带有冲突性的constraint,一个是-60,一个是-120。我们可以一个个的检查约束,但是这个列表很长,检查起来也比较麻烦。

那我们画图来分析一下这个问题。

如图,label有leading和trailing padding,label是container的子view,container是action的子父,action是representation的子view。container和action view之间有一个居中的centering constraint。action view在representation view上有一个autoresizing mask constraints。

然后每个representation view之间是alignment对齐的。自此看来,这些view并没有足够的constraints能让这些view都能确定位置信息。比如在X轴上,这一串view是可以存在在任何的位置,所以产生了歧义的constraint。

解决上面的歧义的

-UIViewLayoutFeedbackLoopDebuggingThreshold 100 // 50...1000
-NSViewLayoutFeedbackLoopDebuggingThreshold 100 // 50...1000
 //Logs to com.apple.UIKit:LayoutLoop or com.apple.AppKit:LayoutLoop

用debugger就可以解决上述的问题。

总结

这个Xcode 8 给我们的Autolayout融合了之前Autoresizing masks的用法,使两个合并在一起使用,这样不同场景我们可以有更多的选择,可以更加灵活的处理布局的问题。还允许我们能手动调节constraints警告优先级别。

针对macOS的布局问题,又给我们带来了新的控件NSGridView

最后给我们带来的新的调试Layout Feedback Loop Debugging的工具,能让我们平时调试起来比较头疼的问题,有了工具可以有据可循,迅速定位问题,查找问题。

最后,请大家多多指教。

最近的文章

关于IB_DESIGNABLE / IBInspectable的那些需要注意的事

前言IB_DESIGNABLE / IBInspectable 这两个关键字是在WWDC 2014年”What’s New in Interface Builder”这个Session里面,用Swift讲过一个例子。也是随着Xcode 6 新加入的关键字。这两个关键字是用在我们自定义View上的,目前暂时只能用在UIView的子类中所以系统自带的原生的那些控件使用这个关键字都没有效果。 Live RenderingYou can use two different attributes—...…

iOS继续阅读
更早的文章

WWDC2016 Session笔记 - iOS 10 UICollectionView新特性

前言关于 iOS 10 UICollectionView的新特性,主要还是体现在如下3个方面 顺滑的滑动体验现在基本上人人都离不开手机,手机的app也每天都有人在用。一个app的好坏由它的用户体验决定。在可以滑动的视图里面,必须要更加丝滑柔顺才能获得用户的青睐。这些UICollectionView的新特性可以让你们的app比原来更加顺滑,而且这些特性只需要你加入少量的代码即可达到目的。 针对self-sizing的改进self-sizing的API在iOS8的时候被引进,iOS10中...…

iOS继续阅读