[轉]iOS8 自動調整UITableView和UICollectionView佈局

轉自:http://www.cocoachina.com/industry/20140825/9450.html

(via: 玉令天下的Blog)

 

本文講述了UITableView、UICollectionView實現 self-sizing cell 佈局的知識，以及如何用 InvalidationContext 優化 UICollectionView 佈局的更新。

 

背景

iOS 愈來愈人性化了，用戶能夠在設置-通用-輔助功能中動態調整字體大小了。你會發現全部 iOS 自帶的APP的字體大小都變了，惋惜咱們開發的第三方APP依然是之前的字體。在 iOS 7 以後咱們能夠用 UIFont 的preferredFontForTextStyle: 類方法來指定一個樣式，並讓字體大小符合用戶設定的字體大小。目前可供選擇的有六種樣式：

UIFontTextStyleHeadline
UIFontTextStyleBody
UIFontTextStyleSubheadline
UIFontTextStyleFootnote
UIFontTextStyleCaption1
UIFontTextStyleCaption2

iOS會根據樣式的用途來合理調整字體。

 

問題來了，諸如字體大小這種「動態類型」，咱們須要對其進行動態的UI調整，不然老是以爲咱們的界面怪怪的：

咱們想要讓Cell 的高度隨着字體大小而做出調整：

總之，還會有其餘動態因素致使咱們須要修改佈局。

 

解決方案

UITableView

有三種策略能夠調節Cell（或者是Header和Footer）的高度：

 

a.調節Height屬性

b.經過委託方法tableView: heightForRowAtIndexPath:

c.Cell的「自排列」（self-sizing）

 

前兩種策略都是咱們所熟悉的，後面將介紹第三種策略。UITableViewCell 和 UICollectionViewCell 都支持 self-sizing。

 

在 iOS 7 中，UITableViewDelegate新增了三個方法來知足用戶設定Cell、Header和Footer預計高度的方法：

- tableView:estimatedHeightForRowAtIndexPath:
- tableView:estimatedHeightForHeaderInSection:
- tableView:estimatedHeightForFooterInSection:

固然對應這三個方法 UITableView 也 estimatedRowHeight、estimatedSectionHeaderHeight 和 estimatedSectionFooterHeight 三個屬性，侷限性在於只能統必定義全部行和節的高度。

 

以 Cell 爲例，iOS 會根據給出的預計高度來建立一個Cell，但等到真正要顯示它的時候，iOS 8會在 self-sizing 計算得出新的 Size 並調整 table 的 contentSize 後，將 Cell 繪製顯示出來。關鍵在於如何得出 Cell 新的 Size，iOS提供了兩種方法：

 

自動佈局

這個兩年前推出的神器雖然在一開始表現不佳，但隨着 Xcode 的愈來愈給力，在iOS7中自動佈局儼然成了默認勾選的選項，經過設定一系列約束來使得咱們的UI可以適應各類尺寸的屏幕。若是你有使用約束的經驗，想必已經有了解決思路：向 Cell 的 contentView 添加約束。iOS 會先調用 UIView 的 systemLayoutSizeFittingSize: 方法來根據約束計算新的Size，若是你沒實現約束，systemLayoutSizeFittingSize: 會接着調用sizeThatFits:方法。

 

人工代碼

咱們能夠重寫sizeThatFits:方法來本身定義新的Size，這樣咱們就沒必要學習約束相關的知識了。

 

下面我給出了一個用 Swift 語言寫的 Demo-HardChoice ，使用自動佈局來調整UITableViewCell的高度。我經過實現一個UITableViewCell的子類DynamicCell來實現自動佈局，你能夠再GitHub上下載源碼：

import UIKit

class DynamicCell: UITableViewCell {

    required init(coder: NSCoder) {
        super.init(coder: coder)
        if textLabel != nil {
            textLabel.font = UIFont.preferredFontForTextStyle(UIFontTextStyleHeadline)
            textLabel.numberOfLines = 0
        }
        if detailTextLabel != nil {
            detailTextLabel.font = UIFont.preferredFontForTextStyle(UIFontTextStyleBody)
            detailTextLabel.numberOfLines = 0
        }
    }

    override func constraints() -> [AnyObject] {
        var constraints = [AnyObject]()
        if textLabel != nil {
            constraints.extend(constraintsForView(textLabel))
        }
        if detailTextLabel != nil {
            constraints.extend(constraintsForView(detailTextLabel))
        }
        constraints.append(NSLayoutConstraint(item: contentView, attribute: NSLayoutAttribute.Height, relatedBy: NSLayoutRelation.GreaterThanOrEqual, toItem: contentView, attribute: NSLayoutAttribute.Height, multiplier: 0, constant: 44))
        contentView.addConstraints(constraints)
        return constraints
    }

    func constraintsForView(view:UIView) -> [AnyObject]{
        var constraints = [NSLayoutConstraint]()
        constraints.append(NSLayoutConstraint(item: view, attribute: NSLayoutAttribute.FirstBaseline, relatedBy: NSLayoutRelation.Equal, toItem: contentView, attribute: NSLayoutAttribute.Top, multiplier: 1.8, constant: 30.0))
        constraints.append(NSLayoutConstraint(item: contentView, attribute: NSLayoutAttribute.Bottom, relatedBy: NSLayoutRelation.GreaterThanOrEqual, toItem: view, attribute: NSLayoutAttribute.Baseline, multiplier: 1.3, constant: 8))
        return constraints
    }

}

上面的代碼須要注意的是，Objective-C中的類在Swift中均可以被當作AnyObject，這在類型兼容問題上很管用。

 

別忘了在相應的 UITableViewController 中的 viewDidLoad 方法中加上：

self.tableView.estimatedRowHeight = 44

自適應效果以下：

UICollectionView

UITableView 和 UICollectionView 都是 data-source 和 delegate 驅動的。UICollectionView 在此之上進行了進一步抽象。它將其子視圖的位置，大小和外觀的控制權委託給一個單獨的佈局對象。經過提供一個自定義佈局對象，你幾乎能夠實現任何你能想象到的佈局。佈局繼承自 UICollectionViewLayout 抽象基類。iOS 6 中以 UICollectionViewFlowLayout 類的形式提出了一個具體的佈局實現。在 UICollectionViewFlowLayout 中，self-sizing 一樣適用：

採用self-sizing後：

UICollectionView 實現 self-sizing 不只能夠經過在 Cell 的 contentView 上加約束和重寫 sizeThatFits: 方法，也能在 Cell 層面（之前都是在 contentSize 上進行 self-sizing）上作文章：重寫 UICollectionReusableView 的preferredLayoutAttributesFittingAttributes: 方法來在 self-sizing 計算出 Size 以後再修改，這樣就達到了對Cell佈局屬性（UICollectionViewLayoutAttributes）的全面控制。

 

PS：preferredLayoutAttributesFittingAttributes: 方法默認調整Size屬性來適應 self-sizing Cell，因此重寫的時候須要先調用父類方法，再在返回的 UICollectionViewLayoutAttributes 對象上作你想要作的修改。

 

由此咱們從最經典的 UICollectionViewLayout 強制計算屬性（還記得 UICollectionViewLayoutAttributes 的一系列工廠方法麼？）到使用 self-sizing 來根據咱們需求調整屬性中的Size，再到重寫UICollectionReusableView（UICollectionViewCell也是繼承於它）的 preferredLayoutAttributesFittingAttributes: 方法來從Cell層面對全部屬性進行修改：

下面來講說如何在 UICollectionViewFlowLayout 實現 self-sizing：

首先，UICollectionViewFlowLayout 增長了estimatedItemSize 屬性，這與 UITableView 中的 」estimated...Height「 很像（注意我用省略號囊括那三種屬性），但畢竟 UICollectionView 中的 Item 都須要約束 Height 和 Width的，因此它是個 CGSIze，除了這點它與 UITableView 中的」estimated...Height「用法沒區別。

其...沒有其次，在 UICollectionView 中實現 self-sizing，只需給 estimatedItemSize 屬性賦值（不能是 CGSizeZero ），一行代碼足矣。

 

InvalidationContext

假如設備屏幕旋轉，或者須要展現一些其妙的效果（好比 CoverFlow ），咱們須要將當前的佈局失效，並從新計算佈局。固然每次計算都有必定的開銷，因此咱們應該謹慎的僅在咱們須要的時候調用 invalidateLayout 方法來讓佈局失效。

 

在 iOS 6 時代，有的人會「聰明地」這樣作：

- (BOOL)shouldInvalidateLayoutForBoundsChange:(CGRect)newBounds
{
    CGRect oldBounds = self.collectionView.bounds;
    if (CGRectGetWidth(newBounds) != CGRectGetWidth(oldBounds)) {
        return YES;
    }
        return NO;
}

而 iOS 7 新加入的 UICollectionViewLayoutInvalidationContext 類聲明瞭在佈局失效時佈局的哪些部分須要被更新。當數據源變動時，invalidateEverything 和 invalidateDataSourceCounts 這兩個只讀 Bool 屬性標記了UICollectionView 數據源「所有過時失效」和「Section和Item數量失效」，UICollectionView會將它們自動設定並提供給你。

 

你能夠調用invalidateLayoutWithContext:方法並傳入一個UICollectionViewLayoutInvalidationContext對象，這能優化佈局的更新效率。

 

當你自定義一個 UICollectionViewLayout 子類時，你能夠調用 invalidationContextClass 方法來返回一個你定義的 UICollectionViewLayoutInvalidationContext 的子類，這樣你的 Layout 子類在失效時會使用你自定義的InvalidationContext 子類來優化更新佈局。

 

你還能夠重寫 invalidationContextForBoundsChange: 方法，在實現自定義 Layout 時經過重寫這個方法返回一個 InvalidationContext 對象。

 

綜上所述都是 iOS 7 中新加入的內容，而且還能夠應用在 UICollectionViewFlowLayout 中。在 iOS 8 中，UICollectionViewLayoutInvalidationContext 也被用在self-sizing cell上。

 

iOS8 中 UICollectionViewLayoutInvalidationContext 新加入了三個方法使得咱們能夠更加細緻精密地使某一行某一節Item（Cell）、Supplementary View 或 Decoration View 失效：

invalidateItemsAtIndexPaths:
invalidateSupplementaryElementsOfKind:atIndexPaths:
invalidateDecorationElementsOfKind:atIndexPaths:

對應着添加了三個只讀數組屬性來標記上面那三種組件：

invalidatedItemIndexPaths
invalidatedSupplementaryIndexPaths
invalidatedDecorationIndexPaths

iOS自帶的照片應用會將每一節照片的信息（時間、地點）停留顯示在最頂部，實現這種將 Header 粘在頂端的功能其實就是將那個 Index 的 Supplementary View 失效，就這麼簡單。

 

UICollectionViewLayoutInvalidationContext 新加入的 contentOffsetAdjustment 和 contentSizeAdjustment 屬性可讓咱們更新 CollectionView 的 content 的位移和尺寸。

 

此外 UICollectionViewLayout 還加入了一對兒方法來幫助咱們使用self-sizing：

shouldInvalidateLayoutForPreferredLayoutAttributes:withOriginalAttributes:
invalidationContextForPreferredLayoutAttributes:withOriginalAttributes:

當一個self-sizing Cell發生屬性發生變化時，第一個方法會被調用，它詢問是否應該更新佈局（即原佈局失效），默認爲NO；而第二個方法更細化的指明瞭哪些屬性應該更新，須要調用父類的方法得到一個InvalidationContext 對象，而後對其作一些你想要的修改，最後返回。

 

試想，若是在你自定義的佈局中，一個Cell的Size由於某種緣由發生了變化（好比因爲字體大小變化），其餘的Cell會因爲 self-sizing 而位置發生變化，你須要實現上面兩個方法來讓指定的Cell更新佈局中的部分屬性；別忘了整個 CollectionView 的 contentSize 和 contentOffset 所以也會發生變化，你須要給 contentOffsetAdjustment 和 contentSizeAdjustment 屬性賦值。