iOS Auto Layout的实现原理及性能。

1、什么是Auto Layout?

Auto Layout是苹果在2012年发布iPhone 5之后,为了开发者更方便的适配不同尺寸的屏幕应运而生的一个框架,但是这个框架的语法相当之蹩脚、冗长,并且大部分iOS程序猿还是习惯手撸代码,xib和storyboard用的相对较少,所以并没有收到开发者的好评,直到Masonry的出现,才使得其获得了大规模的使用。

2、Auto Layout的实现原理。

在介绍Auto Layout原理之前,我们先简单了解下Cassowary,Cassowary是上世纪90年代诞生的一种用于解决用户界面布局问题的算法,它通过将布局问题抽象成线性等式或不等式约束来进行求解,而我们要了解的Auto Layout就是对Cassowary算法的一种实现。由于才疏学浅,没有对Cassowary进行深入研究,所以在此就不作具体讨论了,有兴趣的可以研究研究,还望可以指点一二。

下面我们看下Auto Layout的原理,我们知道view的frame属性是CGRect类型,只包含origin(x,y)和size(width,height),万变不离其宗,Auto Layout的线性表达式,最终也是求解出这四个值,然后布局视图的,我们看个简单的例子来增强理解:

图1
图2

如图1所示,将ViewA和ViewB添加到父视图中,并增加了简单的constraints(约束条件),而在图二中,我们可以看到已经转换为线性等式:

A.top = Safe Area.top + 65;

A.leading = Safe Area.leading + 76;

A.height = 79;

A.width = 76;

B.top = A.top;

B.leading = A.trailing + 71;

B.height = 79;

B.width = 76;

通过Auto Layout来布局的过程就是将上述等式转换为frame的过程,这时我们可以注意到,如果求解ViewA的frame需要解4元1次方程组,而求解ViewB的frame需要解6元1次方程组,这还是在width和height都是直接设置的原因,如果这两个约束也依赖ViewA的话,就要求解8元1次方程组了,所以就引出了我们接下来要讨论的一个话题(iOS12对这部分有所优化,我们后边再讲)。

3、Auto Layout的性能如何?

接下来我会从两方面来介绍(iOS12之前、iOS12之后)。

iOS12之前

我通过采集三种方式多次布局不同数量的视图的时间(使用设备为iPhone 6s,iOS11.0系统),做出了下图,x轴代表视图的数量,y轴代表消耗时间(单位ms),Auto Layout只是最简单的用法(直接设置左、上、宽、高),Nested是嵌套使用Auto Layout,Frame是直接布局不使用Auto Layout。

图3

我们可以看到直接使用Frame消耗的时间是最少的,直接使用Auto Layout看着也没有啥大问题,而嵌套使用Auto Layout消耗时间就呈指数增长了,在我们的工作中,如果使用Auto Layout多多少少都会涉及到嵌套,如果页面很复杂,那就会造成性能问题。PS:当然上述的数据的采集受到一些其他因素影响,可能会导致数据不是很准确,但是整体的趋势是没问题的。

我们知道iOS系统的正常FPS(屏幕刷新率)为60Hz(60次每秒),也就是说每次刷新的时间最多为1000ms/60=16.67ms,当一次是运行时间超过16.67ms时,就会出现掉帧的现象,从而引发卡顿,我们以16.67ms反推,三种不同的布局手段的承受能力是多少呢,看下图

图4

我们可以看出,在布局方面,frame还是有明显优势的,以上为iOS12之前的数据,WWDC18上苹果讲到优化了Auto Layout性能,将其指数关系优化到了线性关系,我们来探其一二。

iOS12之后

我们用相同的测试代码在另一台测试机(iPhone 6s,iOS12.1.2)上结果如下:

图5
图6

由以上两图可以看出,在相同的硬件条件下,iOS12系统上性能确实比之前要好很多,不仅表现在Auto Layout上,直接通过frame布局也有所提升,不过提升最明显的还是嵌套类型的Auto Layout,在100个视图以内,几乎有普通的Auto Layout并驾齐驱,同样的16.67ms一次循环的情况下,能布局的数量都提升很多,这也确实配得上WWDC18上苹果公司提到的性能提升的说法。

苹果的一些建议

1、不要写重复的约束和无用的约束;

2、一个视图中不要搞两套约束;

3、不要频繁的移除和添加约束,在需要的地方更新;

4、intrinsicContentsize(内置宽高),比如UILabel、UIImageView、UIButton,这几种控件可以不设置宽高,由系统计算,但是会比较影响性能;

5、systemLayoutSizeFittingSize,布局引擎获取size,每次调用都会创建和销毁一个布局引擎,比较消耗性能,尽量少用。

参考文献:

从 Auto Layout 的布局算法谈性能

WWDC 2018:高性能 Auto Layout

WWDC视频:WWDC 2018: High Performance Auto Layout

最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 202,529评论 5 475
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 85,015评论 2 379
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 149,409评论 0 335
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 54,385评论 1 273
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 63,387评论 5 364
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 48,466评论 1 281
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 37,880评论 3 395
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 36,528评论 0 256
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 40,727评论 1 295
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 35,528评论 2 319
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 37,602评论 1 329
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 33,302评论 4 318
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 38,873评论 3 306
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 29,890评论 0 19
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 31,132评论 1 259
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 42,777评论 2 349
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 42,310评论 2 342

推荐阅读更多精彩内容