孕孕的三个问题之——为什么使用 Auto Layout 之后手动修改 frame 无效

2015-11-12   /   阅读数:607   /   分类: Auto Layout Club

刚开始使用 Auto Layout 的时候,我应该都经历过神奇的“bug”:手动设置 frame 值不管用,通过修改 frame 进行的动画出现了“反向运动”的奇特效果,而且动画时间也大幅缩短,非常奇怪。

这涉及到了 Auto Layout 本身的特性,我们先来看一段苹果的文档:https://developer.apple.com/library/prerelease/ios/documentation/UserExperience/Conceptual/AutolayoutPG/index.html

External Changes(外部变化)

下面是一些会引发 Auto Layout 重新排布的常见外部变化情况:

  • OS X 上用户改变了窗口大小
  • 使用或者退出 iPad 上的 Split View
  • iOS 设备屏幕方向旋转
  • iOS 上全局置于屏幕顶部的“电话中”及“录音中”提示条
  • 我们想要支持不同的 size classes
  • 我们想要支持不同的屏幕尺寸

Internal Changes(内部变化)

下面是一些会引发 Auto Layout 重新排布的常见内部变化情况:

  • 内容发生了变化
  • 支持国际化的 APP 在语言改变时
  • iOS 中的 Dynamic Type(例如用户自定义文字大小)

从上面的文档中,我们应该可以初窥端倪了:

  • Auto Layout 在得到当前屏幕尺寸后开始工作
  • Auto Layout 在内容发生变化需要更新布局时会重新排布界面
  • Auto Layout 是一种完全不同于之前使用代码计算 frame 的全新界面组织方式

Auto Layout 是一种新的界面组织引擎,其界面组织逻辑不遵循之前手动构建 UI 组件、手动设定尺寸和位置的基本逻辑。实际上有过实际的使用经验你就会发现,Auto Layout 具有跟传统代码组织 UI 布局完全不一样的行为方式:

  • 容器驱动:先显示界面,拿到屏幕尺寸,再重新排布 UI
  • 内容驱动:修改内容,会触发 UI 的重新排布和重绘
  • 底层一致:依然遵循基础的 iOS UI 渲染原则和流程
  • 对于第三点打一个比方可能更容易理解:Auto Layout 更像是 HTTP 层的透明代理,而手写代码依然工作在 IP 层;Auto Layout 更加方便使用,但是跟手写代码比起来更上层、更慢、约束更多。

回到我们标题中提出的问题:为什么使用 Auto Layout 之后手动修改 frame 无效?经过我们上面的分析可以发现,手动修改 frame 工作在更底层,不可能无效。

其实是有效的,但是这个“效”并不是我们想要的“效”而已。如果你在使用了 Auto Layout 的界面上像通过修改 frame 来做动画,你就会发现神奇的事情:你定义了 500 ms,一个按钮从下往上动 100px,实际上你会看到一个神奇的快速动画:很短时间内(估计为几毫秒到十几毫秒),这个按钮从上往下移动了 100px,这是为什么呢?因为在使用了 Auto Layout 的页面中,代码修改 frame 会在一瞬间完成,不会再像之前那样按照既定的 500ms 做完动画;而就在 frame 被瞬间修改之后,Auto Layout 的布局引擎侦测到了~~在途的聚变打击~~内容发生了变化,启动了重绘机制,UI 会重新排布为之前约束规定的样子,而由于 Auto Layout 布局系统的“低性能”,我们就看到了奇怪的“快速反向动画”。

那么 Auto Layout 系统下的动画如何做呢?其实非常简单,把之前修改 frame 的代码变为修改约束值即可,详情可以查看我的 Keynote:https://github.com/johnlui/AutoLayout

要是你说:我就是傲娇,我就想用修改 frame 的方式修改被 Auto Layout 约束的元素,怎么办?这里有一个高票的解决方案,我想你可以试试:Can I use setFrame and autolayout on the same view?

WRITTEN BY

avatar

发表评论:

© 2011-2017 岁寒  |  Powered by Emlog