隨着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
