随着iPhone和iPad水平方向上多任务处理需求的强烈，iOS应用程序设计与开发人员在构建他们的应用程序时可能会面临新的挑战。而AutoLayout的引入使得许多人开始将其视为解决上述问题的头号帮手。这篇文章将为你揭开它的神秘面纱，或者更确切地说，让你了解到AutoLayout解决问题的局限性。
多种布局
为了弄清楚这篇文章的目的，我们假设你是一位iOS app开发者，你正在规划一款类似Unread应用的结构。我们必须让可滚动table view数量达到2,0000行。基于以下几个因素，每行都有一个动态高度：
1.标题的长度，博客名称和文章摘要；
2.图像缩略图的存在与否；（是否存在一个图像缩略图）
3.用户选择的字体大小。
那么，如果给定一个容器宽度w,我们该如何布局元素?
作为一名开发者，我们已经设计了一些原型，我们将用这些原型来编写计算所有元素大小和位置所需的代码。如果一个容器的宽度固定为w，那么我们的布局可能会是这样的：
计算所有这些界面元素的位置所需的数学和逻辑可能会变得非常复杂，而AutoLayout正是为了解决这个问题。在限制了给定容器的大小这一前提下， AutoLayout使得编写和调试用来计算一组界面元素布局的代码变得非常简单。
需要指出的是，你不能假定容器的宽度恒定为W1，因为应用程序可能需要处理至少两种可能性的容器宽度:竖直和水平。那么对于宽度w2，我们的布局看起来怎么样呢？
这个布局显然和第一个大不相同，AutoLayout使得计算所有元素的位置变得更加简单。但是作为一名app开发者，你面临的问题远比根据给定容器宽度计算布局要复杂的多。你也不得不综合考虑计算成千上万的模型对象和可能的容器来做推断。这个问题已经超出AutoLayout能够解决的范围，更加难以应付。
单元格的高度及性能
注意,上述第二布局和第一布局相比，形成了不同的总高度。既然你的应用程序有两个不同高度的布局，那么会有什么样的影响呢？
当加载table view时，它需要知道它将显示多少行，每行多高。对于产生动态行高度(如上设计)的设计来说,这些指标计算起来将会非常耗时间。但你却又不想让你的应用程序在计算这些高度时暂停几秒钟。此时，你该怎么办呢？
使用新的估算行高的API。乍一看这似乎是最好的选择，问题是estimatedHeightForRowAtIndexPath存在bug，我曾经在另一篇博文中进行了详述，大概结论是任何需要精确度的app功能（比如点击状态栏滚动到列表顶部）根本不会与使用该方法的table view发生作用，所以这不是一个很好的解决方案。
预估并缓存所有行高。使用iOS在后台执行工作的能力，你的应用可以提前计算出每个table view行的高度。然后你的table view将会加载“immediately”，无需暂停主要队列。
如果你能够正确运用的话，预先估算会是一个更好的解决方案。当然，想要正确地运用它是非常困难的，有很多因素需要被考虑进来，例如：
l 你需要预先估算多少布局呢？除了竖直和水平方向上，还有其它吗？每一个新布局都会增加必须执行的预估算总量。
l 当后台队列正处理一长串预估算时，如果此时用户改变主题或者字体会怎样呢？
l 如果你在缓存后台计算的结果,哪些事件会让缓存无效呢？日期的更改，还是内容的变化？
l 如果table view在单个列表中有20000个项目会怎么样呢？有可能在类似iPad 2的老设备上执行所有的任务吗，甚至是background queue？在老设备上它可能要花费15-30秒钟来做完所有的工作。然后你要重写模型集合以支持在新内容中分写吗？
iPad多任务和性能
在上面的示例中,仅使用两个静态宽度的布局，你的应用程序就很好地完成了任务。如果iOS 8允许iPad应用程序运用动态宽度加入一个分屏多任务处理模式,这将成倍增加出色发挥table view性能的困难。预先估算这一方法将无法应用于具体实践当中。
假设预估行高API和预估算都无法使用，那开发者唯一可选的是从一开始就不允许元素同时具备动态高度和动态宽度。这将能使其优异性能得以发挥，不过这样将难以实现灵活的应用程序容器。
鉴于这个原因，我认为，如果苹果为iPad应用程序添加分屏多任务功能,那只有缩放应用程序容器，而不改变底层逻辑宽度（768 points for portrait，1024 points for landscape）。
要点
要点就是要明确知道：AutoLayout 能够简化单一容器中的单一布局计算，无法有效地计算多个可能容器的大量布局。
原文：AutoLayout Myths, Table View Performance, and Side-by-Side iPad App Multi-tasking
1176
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
