前言：本来我昨天遇到一个需要动态调整 UICollectionViewCell 尺寸和布局的需求，自己手动实现了，想起来去年 iOS 8 中的 Self-sizing cells，于是过来学习一下。发现这个新特性与我的需求不怎么搭配，但是这是个很有意思并且很实用的新特性。
首先来看看应用场景：
下面两种布局要怎么实现？要按以往的方法，前者需要在 delegate 中的– tableView:heightForRowAtIndexPath:根据 UILabel 的内容来计算每个 cell 的高度（此话有点不对，因为这个方法实在那个 cellForXXX 的方法前调用的，不知道具体内容是没法计算的，解决方案可以参考这篇博客），后者需要自定义布局来计算每个 cell 的大小，两者都比较麻烦，而且很容易造成性能低下，特别是后者。但是利用新特性，在设定了相应的约束的前提下，仅仅需要几行代码就可以搞定，准确来说，前者三行代码，后者仅需一行代码，还避免老方法的性能缺陷，酷到没朋友。另外，上面的 tableview 中的字体是动态变化的，只要用户在设置中更改字体大小，这里也会做出相应的调整，是不是很方便。这也是 iOS 8 中的新特性。
笔记内容
- 动态类型适应（动态字体, TableView 以及 CollectionView 都适用）
- Self-sizing cells（两者都适用）
- CollectionView 智能布局更新
1. 动态类型适应（Dynamic Type adoption）
在 iOS 8 中允许应用使用动态字体，在通用-辅助功能-更大字体的设置中，可以为支持动态字体的应用设置字体大小了。而在支持动态字体的应用中，TableView 中使用了动态字体的地方将会根据字体的大小来自动调整大小和布局，真是很方便，主讲工程师也推荐大家使用动态字体。工程师并未提及 CollectionView 支持 Dynamic Type adoption，根据我的试验，CollectionView 也是支持的，但是没有 TableView 中那么完美，不像后者在在设置中调整好后再次进入应用即可调整，前者需要杀掉应用再次进入应用才会调整大小，严格来说不是 Dynamic Type adoption。
支持 Dynamic Type adoption 的前提是使用预定义的字体样式，也就是说你使用了其他的字体是不支持动态适应的。有两者方法可以设置：
1.在代码中通过 [UIFont preferredFontForTextStyle:] 来设定；
2.在 IB 中选择预定义字体样式。
预定义的字体支持六种样式：
NSString *const UIFontTextStyleHeadline;
NSString *const UIFontTextStyleSubheadline;
NSString *const UIFontTextStyleBody;
NSString *const UIFontTextStyleFootnote;
NSString *const UIFontTextStyleCaption1;
NSString *const UIFontTextStyleCaption2;
2. Self-sizing Cells
1) TableView
在 TableView 中有两种手法来调整每一行的高度：
1.property：rowHeight;
2.delegate: - (CGFloat)tableView:(UITableView *)tableView heightForRowAtIndexPath:(NSIndexPath *)indexPath
第一个方法只能将所有行设置为同一高度；第二个方法有很大的性能缺陷，因为 TableView 每次生成 cell 的时候都要向 delegate 询问这个方法。
新特性 Self-sizing Cells 的实现代码拥有良好的性能，且仅需几行代码：
self.tableView.estimatedRowHeight = 44.0f;
self.tableView.rowHeight = UITableViewAutomaticDimension;
而要实现开头图中的布局，还需要对 UILabel 进行设置：
label.numberOfLines = 0//使UILabel 的高度根据其内容来变化`
estimatedRowHeight 是 iOS 7 中新增的属性，顾名思义，预计高度；同时需要将 rowHeight 属性设置为 UITableViewAutomaticDimension，意思是告诉 TableView 没有 rowHeight，请根据其他信息来判断每一行的高度。另外，TableView 还有 HeaderView 和 FooterView，也有类似的属性来达到同样的效果。
实现 Self-sizing Cells 的关键属性：estimatedRowHeight。当滚动 TableView 使得 cell 即将显示在屏幕上的时候，生成一个 cell，cell 的高度根据 estimatedRowHeight 或者 delegate 的-tableView: heightForRowAtIndexPath: 返回的高度来决定。使用 Self-sizing Cells 时，则是根据 estimatedRowHeight 来决定（此时在 delegate 中不要实现对应的方法），当生成了 cell 后，向 cell 询问它到底应该有多高（在下面讲解实现机制），如果结果和 estimatedRowHeight 不一样，则调整 TableView 的 contentSize，最后将 cell 显示在屏幕上。
怎么知道 cell 到底应该有多高呢？有两种方法可以知道，而这也是实现 Self-sizing Cells 的前提条件：
根据 contentView 中的约束，TableView 向 cell 发送 -systemLayoutSizeFittingSize: 消息来得到它应该具备的高度；如果你没有添加约束，还有一个机会来知道这个高度，systemLayoutSizeFittingSize: 会调用 - (CGSize)sizeThatFits:(CGSize)size，这时候就需要覆写该方法来手工计算了。
2) CollectionView
从这个部分开始是另外一个工程师讲的，应该是一位印度工程师，那口音，以后我搞英文演讲也不是梦了。
TableView 中 cell 的宽度是相对而言是个固定值，高度是可变的，而 CollectionView 则需要两个方向的尺寸才能工作。在 CollectionView 中，所有 cells 和 supplementary view 以及 decoration view 的尺寸、位置以及其他布局属性都是由 CollectionView 的 layout 对象决定。默认情况下，CollectionView 采用FlowLayout 布局，与 TableView 的 estimatedRowHeight 属性对应的是 UICollectionViewFlowLayout 中新的 estimatedItemSize 属性。
1）FlowLayout
在 CollectionView 中使用 Self-sizing Cells 的前提条件同 TableView 类似，对 cell 的 contentView 添加约束条件或是重写 - (CGSize)sizeThatFits:(CGSize)size，如果采用后者，则还会遇到 rotation 的问题，比较麻烦，推荐使用约束。注意，如果约束条件并不是非常严格，动态尺寸布局就不会那么完整，比如，在开头的布局中，只对宽度进行约束的话，那么在高度方面就不会进行动态适应了。
在 CollectionView 中使用 Self-sizing Cells，只需要将 FlowLayout 的 estimatedItemSize 指定为非零尺寸即可。一行代码搞定，在- viewDidLoad：中：
UICollectionViewFlowLayout *selfFlowLayout = (UICollectionViewFlowLayout *)self.collectionViewLayout;
selfFlowLayout.estimatedItemSize = CGSizeMake(50, 50);
好吧，两行。具体的 cell 的尺寸则会根据约束条件以及 estimatedItemSize 综合来考虑。
- 自定义 layout
如果不使用 FlowLayout 或者其子类而自定义其他布局的话，也可以使用 Self-sizing cells，需要重写以下方法，这些是 iOS8 新增的方法:- shouldInvalidateLayoutForPreferredLayoutAttributes:withOriginalAttributes:
- invalidationContextForPreferredLayoutAttributes:withOriginalAttributes:
其中的 PreferredLayoutAttributes 其实是指 UICollectionReusableView 中的新增方法: - preferredLayoutAttributesFittingAttributes:
该方法使得 cell 有机会在应用 layout 返回的布局前做出最后一次修改。
实际上 CollectionView 的 Self-sizing Cells 与UICollectionViewLayoutInvalidationContext类有较大关系，这就引出下面了的内容。
CollectionView 的智能布局更新
iOS 8 为 CollectionView 提供了更细节化而且更全面的布局控制，对于提升自定义布局的性能很有帮助。
1）布局策略
上面的图本来是视频中工程师讲述 CollectionView 中 Self-sizing Cells 的截图，放在这里是想说明 cell 的布局是如何驱动的。图中第一种方法就是在 iOS 6 中随着 UICollectionView 一起推出的 UICollectionViewLayout 类，它决定了 cell 以及 SupplementaryView 的位置、大小、alpha以及其他布局信息，是以往实现自定义布局的唯一选择；Self-sizing Cells 就是今天讲到的新特性，利用约束条件或是重写 - sizeThatFits: 结合新增的 estimatedItemSize 属性实现动态布局；第三种则是利用了 cell 的父类 UICollectionReusableView 的新增方法
- preferredLayoutAttributesFittingAttributes: 在应用 Self-sizing Cells 的布局信息前最后一次修改布局信息。后面两种都是 iOS 8 中的新特性：
FlowLayout 中的 estimatedItemSize 在 Self-sizing Cells 中起到了什么作用呢？与 TableView 中的 estimatedRowHeight 类似，只是由于UICollectionView 多了布局对象以及 cell 多出了一个维度的尺寸变化，estimatedItemSize 参与的布局过程比 estimatedRowHeight 在 TableView 中更加复杂了。首先由 CollectionView 的 FlowLayout 对象根据 estimatedItemSize 以及其他信息计算出 cell 的布局信息，CollectionView 根据数据源重用或生成 cell，Self-sizing Cells 机制在这里发挥作用，实现手法和前面提到的一样：利用 AutoLayout 或是 -sizeThatFits:；或者由 - preferredLayoutAttributesFittingAttributes: 做出最终修改，CollectionView 将更新的布局信息反馈给 FlowLayout 对象，后者响应更新的布局信息，最后向 CollectionView 提供最终的布局信息将 cell 显示在屏幕上。
2）布局更新(Layout Invalidation)
I) 传统的布局更新
UICollectionViewLayout 使用-invalidateLayout来更新布局，布局对象会依次调用以下方法：
- prepareLayout
- collectionViewContentSize
- layoutAttributesForElementsInRect:
再次更新布局时，上面的方法再循环一次。在 iOS 8 之前，更新布局只能对 CollectionView 上的所有 elements 进行布局更新。显然，这里面有很多本不需要进行计算的，也是性能隐患；从 iOS 8 开始可以针对局部的布局进行更新了，不需要重新计算所有 elements 的布局信息，这对性能的提升有很大的帮助，主讲工程师称之为「Smart Invalidation」。
II) 新的布局系统
实现智能布局更新的关键在于 UICollectionViewLayoutInvalidationContext 类，这并不是 iOS 8 才推出的，而是在 iOS 7 中出现的。InvalidationContext 类用来提供布局更新的信息，但在 iOS 7 中只是用来重构原来的布局系统，并没有提供新的特性。
在 iOS 7 中 InvalidationContext 类仅有两个公开接口, 而且调用者无法设置；在添加或是删除 items 时，由 CollectionView 来自动设置：
//指示是否有增减 element
@property (nonatomic, readonly) BOOL invalidateDataSourceCounts;
//指示是否需要更新全部的布局信息
@property (nonatomic, readonly) BOOL invalidateEverything;
为了搭建新的布局系统，在 iOS 7 中 UICollectionViewLayout 类新增了三个方法，用来配合 InvalidationContext 类使用：
+ invalidationContextClass //指定布局环境
- invalidateLayoutWithContext://根据提供的布局环境来更新布局`
对 bounds 变化时的支持:
- invalidationContextForBoundsChange://返回一个包含了所需信息的InvalidationContext对象
FlowLayout 在处理 rotation 时使用了 InvalidationContext 来更新布局，流程如下：
//首先询问是否需要更新布局
- (BOOL)shouldInvalidateLayoutForBoundsChange:(CGRect)newBounds
//如果需要更新布局，接下来调用下面的方法获取InvalidationContext对象，如果重写下面的方法，需要调用父类的实现
- (UICollectionViewLayoutInvalidationContext *)invalidationContextForBoundsChange:(CGRect)newBounds
//最后利用上面获取的InvalidationContext 来更新布局
- (void)invalidateLayoutWithContext:(UICollectionViewLayoutInvalidationContext *)context
Note: 在 FlowLayout 中使用 Self-sizing Cells 来实现文章开头的布局的时候，其处理 rotation 的性能相当的差。在我的 iPad mini 上，要经过3秒左右才能响应屏幕的旋转。说好的提升性能呢，不知道是哪里出了问题，不然也不至于把这个特性放出来。在不使用 Self-sizing 的时候，稍好一点，不知道是不是字符串的处理有性能缺陷。也有可能我的机器太老了。
III) 智能布局更新
有了 iOS 7 中打下的基础，iOS 8 在 InvalidationContext 类中增加了新的 API，可以对针对局部的布局更新了：
- invalidateItemsAtIndexPaths:
- invalidateSupplementaryElementsOfKind:atIndexPaths:
- invalidateDecorationElementsOfKind:atIndexPaths:
新的 API 和 CollectionView 更新 cell 内容的 API 类似，只是控制的尺度更细微，能够具体到单个的 element 的布局，在以往更新布局只能对整体进行操作。利用新的 API，实现 Photos 应用中时间线里面的浮动 Header 就相当简单了，调用 - invalidateSupplementaryElementsOfKind:atIndexPaths: 使得对应位置的 HeaderView 布局失效即可。
Note：说得好听，但目前为止我还没有利用这个特性成功地实现这个浮动 Header，一般称之为 sticky header。目前我用 google 搜出来的答案基本抄的这个答案下的代码。而这个尝试利用 InvalidContext 的帖子，特别是那个meelawsh的回答，经试验完全是鬼扯好吧。可是我对这个帖子没有任何权限，既不能赞同反对，甚至不能评论！！！而且那个家伙甚至连个邮箱都没有留下！
5/12 更新：被这个东西折腾了几天，发现用这个来提升性能比写一个浮动 header 布局麻烦多了。需要考虑屏幕上的 HeaderView 是否超出了屏幕从而单独更新这个 HeaderView 的布局，以及下方的 HeaderView 上升到当前悬浮的 HeaderView 的位置时。
IV) 对 Self-sizing Cells 的支持
上面的章节里提到在自定义 layout 中使用 Self-sizing Cells，需要重写以下两个方法：
- shouldInvalidateLayoutForPreferredLayoutAttributes:withOriginalAttributes:
- invalidationContextForPreferredLayoutAttributes:withOriginalAttributes:
在第二个方法中，返回一个 InvalidationContext 对象。在 iOS 8 中 InvalidationContext 类新增了两个属性：
@property(nonatomic) CGPoint contentOffsetAdjustment;
@property(nonatomic) CGPoint contentSizeAdjustment
顾名思义，cell 的尺寸发生变化，那么在 UICollectionView 的 contentOffset 和 contentSize 都要发生变化。后者很好理解，cell 变大变小，需要用来展示内容的面积也回发生变化，前者呢，可以看看这篇文章：理解 ScrollView。在第二个方法返回的 InvalidationContext 对象需要提供这两个信息。
