全屏返回手势

自 iOS7 之后，Apple 增加了屏幕边缘右划返回交互的支持，再配合上 UINavigationController 的交互式动画，pop 到上一级页面的操作变的非常顺畅和丝滑，从此，我很少再使用点击左上角导航栏上的返回按钮的方式返回了，因为这对单手操作十分不友好；如果一个 App 居然胆敢不支持滑动返回，那离被卸载就不远了。

说到全屏返回手势，首先我感觉这件事本身可能就有问题，毕竟有点反苹果官方的交互，让用户从任意的地方都能够滑动返回这个交互在国内的 App 中非常普遍，比如我手机中的手Q、微博、网易新闻、大众点评等，当然还有百度知道- -。这里得对微信的产品经理们得点个赞，从整个 App 来看，不论是交互还是 UI 结构和样式都非常的 iOS，没有什么特别奇葩的页面和交互，以至于使用 UIKit 原生的框架可以非常简单的搭建起来，这也符合我个人对 App 的一个愿景：一个优秀的 App 不论从用户角度看还是从代码角度看都应该是简单且优雅的，呼吁各家产品经理可以多借鉴下像微信这样很本色的 App 设计。（以后可以分享下如何使用 Storyboard 在一小时内快速搭建起微信 UI）

FDFullscreenPopGesture

工作毕竟是工作，于是乎所以就被迫实现了套 pan 手势处理加截图和视差，虽然在运动曲线上、bar 截图处理上下了不少功夫，但距离系统的丝滑效果还是差距挺远。随时间推移，终于能够最低支持 iOS7 后，我们把这个问题再次拿出来讨论和研究，直到在微博上看到了 J_雨同学的这篇文章 后才找到了这个迄今为止最简单的解决方案。于是乎在他的授权下，我们在 forkingdog 上把这个返回手势开源，github地址，并果断应用到了百度知道 App 内，这是 Demo 效果：

利用了系统自己的边缘返回手势处理函数后，一切动画和曲线都和原生效果一毛一样了。
于是乎发布了 FDFullscreenPopGesture 1.0 版本，而且提供了一个 AOP 形式的 API，把它添加到工程里面，什么代码都不用写，所有 UINavigationController 就自带这个全屏返回效果了。

丝滑的处理导航栏的显示和隐藏

接下来我们发现利用系统的 UINavigationBar 时，返回手势中若碰到前一个页面有 bar，后一个页面没 bar，或者反过来时，动画就非常难看，举两个反例：

手Q iOS：

它的个人中心页面上面的 bar 是隐藏状态，然后做了个和其他页面很像的假 bar，但返回手势一开始就露馅了，为了弥补，还做了下后面真 bar 的 alpha 值动画，两个返回按钮还是重叠在了一起。

新浪微博 iOS：

和手Q一样的实现方式，只不过没做 alpha 动画，所以就非常明显了。

为啥会这样呢？这可能就是 UINavigationController 在导航栏控制 API 上设计的缺陷了。 一个 UINavigationController 管理了串行的 N 个 UIViewController 栈式的 push 和 pop，而 UINavigationBar 由 UINavigationController 管理，这就导致了 UIViewController 无法控制自己上面的 bar 单独的隐藏或显示。 这非常像 UIApplication 全局的 status bar，牵一发还得动全身，不过 Apple 在 iOS7 之后为 vc 控制自己的 status bar 提供了下面几个方法：

1
2
3

- (UIStatusBarStyle)preferredStatusBarStyle NS_AVAILABLE_IOS(7_0);
- (BOOL)prefersStatusBarHidden NS_AVAILABLE_IOS(7_0);
- (UIStatusBarAnimation)preferredStatusBarUpdateAnimation NS_AVAILABLE_IOS(7_0);

终于让这个全局变量变成了局部变量，虽然写起来费劲了些。
但是对 UINavigationBar 的控制，依然是全局的，可能 Apple 觉得 App 不应该有这种奇怪的页面结构？

解决这个问题的方法也不难，在滑动返回的后要出现的那个 view controller 中写下面的代码：

1
2
3
4

- (void)viewWillAppear:(BOOL)animated {
    [super viewWillAppear:animated];
    [self.navigationController setNavigationBarHidden:YES animated:animated];
}

系统就会把有 bar 和 无 bar 的 transition 动画衔接起来。但是如上面所说，这是个全局变量，还得在所有由这个没有 bar 的特殊页面能 push 和 pop 的页面都进行反向的处理，代码非常的乱乎。于是乎，我们试着解决了这个问题，先看效果：

我特意挑了个从真 bar 到假 bar，再从假 bar 到 真 bar 的页面，还算蛮丝滑的，transition 动画全是系统自己搞定的。
就事把 FDFullscreenPopGesture 更新到了 1.1 版本，贯彻我们一向的精简 API，你只需要在 bar 要隐藏的 view controller 中写一句话：

1
2
3
4

- (void)viewDidLoad
    [super viewDidLoad];
    self.navigationController.fd_prefersNavigationBarHidden = YES;
}

或者喜欢重载的写法也行：

1
2
3

- (BOOL)fd_prefersNavigationBarHidden {
    return YES;
}

刻意的模仿了下系统的命名风格，就这一句话，剩下的就都不用操心了。

关于私有API

大家会质疑说，这用到了 UIKit 的私有属性和私有 API，要是系统升级变了咋办？要是审核被拒了咋办？
首先，iOS 系统的 SDK 为了向下兼容，一般只会增加方法或者修改方法实现，不太可能直接删除一个共有方法，而私有方法的行为确实可能有变化，但系统 release 频率毕竟很低，每当新版本发布时 check 下原来的功能是否能 work 就好了，大可不必担心这么远，SDK 是死的人是活的。
另一个就是审核问题，FDFullscreenPopGesture 的实现中有主要有两处触碰到了私有 API：

1
2
3
4

// 1. 私有变量标志transition动画是否正在进行
[self.navigationController valueForKey:@"_isTransitioning"];
// 2. 一个内部的selector
NSSelectorFromString(@"handleNavigationTransition:");

不论是 kvc 还是 selector 反射，都是利用 objc runtime 完成的，而到了这一层，真的就没啥公有私有可言了。设想你就是开发 Apple 私有 API 检查工具的工程师，给你一个 ipa 的包，你会如何检查出其中有没有私有 API 呢？

首先，这个检查一定是个静态检查吧，不可能是运行时检查，因为代码逻辑那么复杂，把程序跑起来看所有 objc_msgSend 中包不包括私有调用这件事太不现实了。
对 ipa 文件做静态检查的话肯定是去分析 Mach-O 可执行文件，因为这时很多源代码级别的信息已经丢失，经分析可以采取下面几种手段：

• 是否 link 了私有 framework 或者公开 framework 中的私有符号，这可以防止开发者把私有 header 都 dump 出来供程序直接调用。
• 同上，使用@selector(_private_sel)加上-performSelector:的方式直接调用私有 API。
• 扫描所有符号，查看是否有继承自私有类，重载私有方法，方法名是否有重合。
• 扫描所有string，看字符串常量段是否出现和私有 API 对应的。

我觉得前三条被 catch 住的可能性最高，也最容易被检查出来。再来看我们用到用字符串的方法 kvc 和 反射 selector，应该属于最后一条，这时候就很难抉择了，拿 handleNavigationTransition: 来说，看上去人畜无害啊，我自己类里面的方法也完全可能命名出这个来，所以单单凭借字符串命中私有 API 判定，苹果很容易误伤一大票开发者。
综上，我觉得使用字符串的方式使用私有 API 是相对安全的，我们的 App 马上要提交审核，如果过了几天你还能读到这段文字，说明我的猜想是木有错的，大家可以放心使用。

0 代码的 Demo

还有一个有意思的事，我们在 github 上的 demo工程 木有写一行代码，就实现了下面的效果：

工程长这个样子，view controller 类也没写，为了体现 FDFullscreenPopGesture 的 AOP 性质：

页面由 Storyboard 构建：

而控制页面隐藏 bar 的属性也能用 Runtime Attributes 模拟调用：

这样就完成了一个非常干净的 Demo

加入到你的工程中

首先要求最低支持 iOS7，我想在 WWDC 2015 结束，iOS9 发布后，主流的 App 就都会 iOS7 起跳了。
依然是熟悉的 cocoapods 安装：

1

pod 'FDFullscreenPopGesture', '~> 1.1'

要是没有搜到就 pod setup 下。

广告时间

我这边正在招聘 iOS，坐标北京，希望找到一个代码规范的、爱用 IB 的、懒得写重复代码、不爱加班的同学，相信这里有很大空间供你学习和提升，还可以参与到 forkingdog 开源小组中做点屌屌的东西，欢迎私聊或把简历丢到 sunyuan01@baidu.com

我是前言

这篇文章是我和我们团队最近对 UITableViewCell 利用 AutoLayout 自动高度计算和 UITableView 滑动优化的一个总结。
我们也在维护一个开源的扩展，UITableView+FDTemplateLayoutCell，让高度计算这个事情变的前所未有的简单，也受到了很多星星的支持，github链接请戳我

这篇总结你可以读到：

• UITableView高度计算和估算的机制
• 不同iOS系统在高度计算上的差异
• iOS8 self-sizing cell
• UITableView+FDTemplateLayoutCell如何用一句话解决高度问题
• UITableView+FDTemplateLayoutCell中对RunLoop的使用技巧

UITableViewCell高度计算

rowHeight

UITableView是我们再熟悉不过的视图了，它的 delegate 和 data source 回调不知写了多少次，也不免遇到 UITableViewCell 高度计算的事。UITableView 询问 cell 高度有两种方式。
一种是针对所有 Cell 具有固定高度的情况，通过：

1

self.tableView.rowHeight = 88;

上面的代码指定了一个所有 cell 都是 88 高度的 UITableView，对于定高需求的表格，强烈建议使用这种（而非下面的）方式保证不必要的高度计算和调用。rowHeight属性的默认值是 44，所以一个空的 UITableView 显示成那个样子。

另一种方式就是实现 UITableViewDelegate 中的：

1
2
3

- (CGFloat)tableView:(UITableView *)tableView heightForRowAtIndexPath:(NSIndexPath *)indexPath {
    // return xxx
}

需要注意的是，实现了这个方法后，rowHeight 的设置将无效。所以，这个方法适用于具有多种 cell 高度的 UITableView。

estimatedRowHeight

这个属性 iOS7 就出现了， 文档是这么描述它的作用的：

If the table contains variable height rows, it might be expensive to calculate all their heights when the table loads. Using estimation allows you to defer some of the cost of geometry calculation from load time to scrolling time.

恩，听上去蛮靠谱的。我们知道，UITableView 是个 UIScrollView，就像平时使用 UIScrollView 一样，加载时指定 contentSize 后它才能根据自己的 bounds、contentInset、contentOffset 等属性共同决定是否可以滑动以及滚动条的长度。而 UITableView 在一开始并不知道自己会被填充多少内容，于是询问 data source 个数和创建 cell，同时询问 delegate 这些 cell 应该显示的高度，这就造成它在加载的时候浪费了多余的计算在屏幕外边的 cell 上。和上面的 rowHeight 很类似，设置这个估算高度有两种方法：

1
2
3
4
5

self.tableView.estimatedRowHeight = 88;
// or
- (CGFloat)tableView:(UITableView *)tableView estimatedHeightForRowAtIndexPath:(NSIndexPath *)indexPath {
    // return xxx
}

有所不同的是，即使面对种类不同的 cell，我们依然可以使用简单的 estimatedRowHeight 属性赋值，只要整体估算值接近就可以，比如大概有一半 cell 高度是 44， 一半 cell 高度是 88， 那就可以估算一个 66，基本符合预期。

说完了估算高度的基本使用，可以开始吐槽了：

1. 设置估算高度后，contentSize.height 根据“cell估算值 x cell个数”计算，这就导致滚动条的大小处于不稳定的状态，contentSize 会随着滚动从估算高度慢慢替换成真实高度，肉眼可见滚动条突然变化甚至“跳跃”。
2. 若是有设计不好的下拉刷新或上拉加载控件，或是 KVO 了 contentSize 或 contentOffset 属性，有可能使表格滑动时跳动。
3. 估算高度设计初衷是好的，让加载速度更快，那凭啥要去侵害滑动的流畅性呢，用户可能对进入页面时多零点几秒加载时间感觉不大，但是滑动时实时计算高度带来的卡顿是明显能体验到的，个人觉得还不如一开始都算好了呢（iOS8更过分，即使都算好了也会边划边计算）

iOS8 self-sizing cell

具有动态高度内容的 cell 一直是个头疼的问题，比如聊天气泡的 cell， frame 布局时代通常是用数据内容反算高度：

1

CGFloat height = textHeightWithFont() + imageHeight + topMargin + bottomMargin + ...;

供 UITableViewDelegate 调用时很可能是个 cell 的类方法：

1
2
3

@interface BubbleCell : UITableViewCell
+ (CGFloat)heightWithEntity:(id)entity;
@end

各种魔法 margin 加上耦合了屏幕宽度。

AutoLayout 时代好了不少，提供了-systemLayoutSizeFittingSize:的 API，在 contentView 中设置约束后，就能计算出准确的值；缺点是计算速度肯定没有手算快，而且这是个实例方法，需要维护专门为计算高度而生的 template layout cell，它还要求使用者对约束设置的比较熟练，要保证 contentView 内部上下左右所有方向都有约束支撑，设置不合理的话计算的高度就成了0。

这里还不得不提到一个 UILabel 的蛋疼问题，当 UILabel 行数大于0时，需要指定 preferredMaxLayoutWidth 后它才知道自己什么时候该折行。这是个“鸡生蛋蛋生鸡”的问题，因为 UILabel 需要知道 superview 的宽度才能折行，而 superview 的宽度还依仗着子 view 宽度的累加才能确定。这个问题好像到 iOS8 才能够自动解决（不过我们找到了解决方案）

回到正题，iOS8 WWDC 中推出了 self-sizing cell 的概念，旨在让 cell 自己负责自己的高度计算，使用 frame layout 和 auto layout 都可以享受到：

这个特性首先要求是 iOS8，要是最低支持的系统版本小于8的话，还得针对老版本单写套老式的算高（囧），不过用的 API 到不是新面孔：

1
2

self.tableView.estimatedRowHeight = 213;
self.tableView.rowHeight = UITableViewAutomaticDimension;

这里又不得不吐槽了，自动计算 rowHeight 跟 estimatedRowHeight 到底是有什么仇，如果不加上估算高度的设置，自动算高就失效了- -
PS：iOS8 系统中 rowHeight 的默认值已经设置成了 UITableViewAutomaticDimension，所以第二行代码可以省略。

问题：

1. 这个自动算高在 push 到下一个页面或者转屏时会出现高度特别诡异的情况，不过现在的版本修复了。
2. 求一个能让最低支持 iOS8 的公司- -

iOS8抽风的算高机制

相同的代码在 iOS7 和 iOS8 上滑动顺畅程度完全不同，iOS8 莫名奇妙的卡。很大一部分原因是 iOS8 上的算高机制大不相同，这是我做的小测试：

研究后发现这么多次额外计算有下面的原因：

1. 不开启高度估算时，UITableView 上来就要对所有 cell 调用算高来确定 contentSize
2. dequeueReusableCellWithIdentifier:forIndexPath: 相比不带 “forIndexPath” 的版本会多调用一次高度计算
3. iOS7 计算高度后有”缓存“机制，不会重复计算；而 iOS8 不论何时都会重新计算 cell 高度

iOS8 把高度计算搞成这个样子，从 WWDC 也倒是能找到点解释，cell 被认为随时都可能改变高度（如从设置中调整动态字体大小），所以每次滑动出来后都要重新计算高度。

说了这么多，究竟有没有既能省去算高烦恼，又能保证顺畅的滑动，还能支持 iOS6+ 的一站式解决方案呢？

UITableView+FDTemplateLayoutCell

使用 UITableView+FDTemplateLayoutCell 无疑是解决算高问题的最佳实践之一，既有 iOS8 self-sizing 功能简单的 API，又可以达到 iOS7 流畅的滑动效果，还保持了最低支持 iOS6。
使用起来大概是这样：

1
2
3
4
5
6
7

#import <UITableView+FDTemplateLayoutCell.h>
- (CGFloat)tableView:(UITableView *)tableView heightForRowAtIndexPath:(NSIndexPath *)indexPath {
    return [tableView fd_heightForCellWithIdentifier:@"identifer" cacheByIndexPath:indexPath configuration:^(id cell) {
        // 配置 cell 的数据源，和 "cellForRow" 干的事一致，比如：
        cell.entity = self.feedEntities[indexPath.row];
    }];
}

写完上面的代码后，你就已经使用到了：

• 和每个 UITableViewCell ReuseID 一一对应的 template layout cell
  这个 cell 只为了参加高度计算，不会真的显示到屏幕上；它通过 UITableView 的 -dequeueCellForReuseIdentifier: 方法 lazy 创建并保存，所以要求这个 ReuseID 必须已经被注册到了 UITableView 中，也就是说，要么是 Storyboard 中的原型 cell，要么就是使用了 UITableView 的 -registerClass:forCellReuseIdentifier: 或 -registerNib:forCellReuseIdentifier:其中之一的注册方法。
• 根据 autolayout 约束自动计算高度
  使用了系统在 iOS6 就提供的 API：-systemLayoutSizeFittingSize:
• 根据 index path 的一套高度缓存机制
  计算出的高度会自动进行缓存，所以滑动时每个 cell 真正的高度计算只会发生一次，后面的高度询问都会命中缓存，减少了非常可观的多余计算。
• 自动的缓存失效机制
  无须担心你数据源的变化引起的缓存失效，当调用如-reloadData，-deleteRowsAtIndexPaths:withRowAnimation:等任何一个触发 UITableView 刷新机制的方法时，已有的高度缓存将以最小的代价执行失效。如删除一个 indexPath 为 [0:5] 的 cell 时，[0:0] ~ [0:4] 的高度缓存不受影响，而 [0:5] 后面所有的缓存值都向前移动一个位置。自动缓存失效机制对 UITableView 的 9 个公有 API 都进行了分别的处理，以保证没有一次多余的高度计算。
• 预缓存机制
  预缓存机制将在 UITableView 没有滑动的空闲时刻执行，计算和缓存那些还没有显示到屏幕中的 cell，整个缓存过程完全没有感知，这使得完整列表的高度计算既没有发生在加载时，又没有发生在滑动时，同时保证了加载速度和滑动流畅性，下文会着重讲下这块的实现原理。

我们在设计这个工具的 API 时斟酌了非常长的时间，既要保证功能的强大，也要保证接口的精简，一行调用背后隐藏着很多功能。

这一套缓存机制能对滑动起多大影响呢？除了肉眼能明显的感知到外，我还做了个小测试：
一个有 54 个内容和高度不同 cell 的 table view，从头滑动到尾，再从尾滑动到头，iOS8 系统下，iPhone6，使用 Time Profiler 监测算高函数所花费的时间：

未使用缓存API、未使用估算，共花费 877 ms：

使用缓存API、开启估算，共花费 77 ms：

测试数据的精度先不管，从量级上就差了一个数量级，说实话自己也没想到差距有这么大- -

同时，工具也顺手解决了-preferredMaxLayoutWidth的问题，在计算高度前向 contentView 加了一条和 table view 宽度相同的宽度约束，强行让 contentView 内部的控件知道了自己父 view 的宽度，再反算自己被外界约束的宽度，破除“鸡生蛋蛋生鸡”的问题，这里比较 tricky，就不展开说了。下面说说利用 RunLoop 预缓存的实现。

利用RunLoop空闲时间执行预缓存任务

FDTemplateLayoutCell 的高度预缓存是一个优化功能，它要求页面处于空闲状态时才执行计算，当用户正在滑动列表时显然不应该执行计算任务影响滑动体验。
一般来说，这个功能要耦合 UITableView 的滑动状态才行，但这种实现十分不优雅且可能破坏外部的 delegate 结构，但好在我们还有RunLoop这个工具，了解它的运行机制后，可以用很简单的代码实现上面的功能。

空闲RunLoopMode

在曾经的 RunLoop 线下分享会（视频可戳）中介绍了 RunLoopMode 的概念。
当用户正在滑动 UIScrollView 时，RunLoop 将切换到 UITrackingRunLoopMode 接受滑动手势和处理滑动事件（包括减速和弹簧效果），此时，其他 Mode （除 NSRunLoopCommonModes 这个组合 Mode）下的事件将全部暂停执行，来保证滑动事件的优先处理，这也是 iOS 滑动顺畅的重要原因。
当 UI 没在滑动时，默认的 Mode 是 NSDefaultRunLoopMode（同 CF 中的 kCFRunLoopDefaultMode），同时也是 CF 中定义的 “空闲状态 Mode”。当用户啥也不点，此时也没有什么网络 IO 时，就是在这个 Mode 下。

用RunLoopObserver找准时机

注册 RunLoopObserver 可以观测当前 RunLoop 的运行状态，并在状态机切换时收到通知：

1. RunLoop开始
2. RunLoop即将处理Timer
3. RunLoop即将处理Source
4. RunLoop即将进入休眠状态
5. RunLoop即将从休眠状态被事件唤醒
6. RunLoop退出

因为“预缓存高度”的任务需要在最无感知的时刻进行，所以应该同时满足：

1. RunLoop 处于“空闲”状态 Mode
2. 当这一次 RunLoop 迭代处理完成了所有事件，马上要休眠时

使用 CF 的带 block 版本的注册函数可以让代码更简洁：

1
2
3
4
5
6
7

CFRunLoopRef runLoop = CFRunLoopGetCurrent();
CFStringRef runLoopMode = kCFRunLoopDefaultMode;
CFRunLoopObserverRef observer = CFRunLoopObserverCreateWithHandler
(kCFAllocatorDefault, kCFRunLoopBeforeWaiting, true, 0, ^(CFRunLoopObserverRef observer, CFRunLoopActivity _) {
    // TODO here
});
CFRunLoopAddObserver(runLoop, observer, runLoopMode);

在其中的 TODO 位置，就可以开始任务的收集和分发了，当然，不能忘记适时的移除这个 observer

分解成多个RunLoop Source任务

假设列表有 20 个 cell，加载后展示了前 5 个，那么开启估算后 table view 只计算了这 5 个的高度，此时剩下 15 个就是“预缓存”的任务，而我们并不希望这 15 个计算任务在同一个 RunLoop 迭代中同步执行，这样会卡顿 UI，所以应该把它们分别分解到 15 个 RunLoop 迭代中执行，这时就需要手动向 RunLoop 中添加 Source 任务（由应用发起和处理的是 Source 0 任务）
Foundation 层没对 RunLoopSource 提供直接构建的 API，但是提供了一个间接的、既熟悉又陌生的 API：

1
2
3
4
5

- (void)performSelector:(SEL)aSelector
               onThread:(NSThread *)thr
             withObject:(id)arg
          waitUntilDone:(BOOL)wait
                  modes:(NSArray *)array;

这个方法将创建一个 Source 0 任务，分发到指定线程的 RunLoop 中，在给定的 Mode 下执行，若指定的 RunLoop 处于休眠状态，则唤醒它处理事件，简单来说就是“睡你xx，起来嗨！”
于是，我们用一个可变数组装载当前所有需要“预缓存”的 index path，每个 RunLoopObserver 回调时都把第一个任务拿出来分发:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

NSMutableArray *mutableIndexPathsToBePrecached = self.fd_allIndexPathsToBePrecached.mutableCopy;
CFRunLoopObserverRef observer = CFRunLoopObserverCreateWithHandler(kCFAllocatorDefault, kCFRunLoopBeforeWaiting, true, 0, ^(CFRunLoopObserverRef observer, CFRunLoopActivity _) {
    if (mutableIndexPathsToBePrecached.count == 0) {
        CFRunLoopRemoveObserver(runLoop, observer, runLoopMode);
        CFRelease(observer); // 注意释放，否则会造成内存泄露
        return;
    }
    NSIndexPath *indexPath = mutableIndexPathsToBePrecached.firstObject;
    [mutableIndexPathsToBePrecached removeObject:indexPath];
    [self performSelector:@selector(fd_precacheIndexPathIfNeeded:)
                 onThread:[NSThread mainThread]
               withObject:indexPath
            waitUntilDone:NO
                    modes:@[NSDefaultRunLoopMode]];
});

这样，每个任务都被分配到下个“空闲” RunLoop 迭代中执行，其间但凡有滑动事件开始，Mode 切换成 UITrackingRunLoopMode，所有的“预缓存”任务的分发和执行都会自动暂定，最大程度保证滑动流畅。

PS: 预缓存功能因为下拉刷新的冲突和不明显的收益已经废弃

开始使用UITableView+FDTemplateLayoutCell

如果你觉得这个工具能帮得到你，整合到工程也十分简单。
使用 cocoapods：

1

pod search UITableView+FDTemplateLayoutCell

写这篇文章时的最新版本为 1.2，去除了前一个版本的黑魔法，增加了预缓存功能。
欢迎使用和支持这个工具，有 bug 请随时反馈哦~
再复习下 github 地址： https://github.com/forkingdog/UITableView-FDTemplateLayoutCell

前段时间整理项目中的AppDelegate，发现很多写在- application:didFinishLaunchingWithOptions:中的代码都只是为了在程序启动时获得一次调用机会，多为某些模块的初始化工作，如：

1
2
3
4
5
6
7
8

- (BOOL)application:(UIApplication *)application
didFinishLaunchingWithOptions:(NSDictionary *)launchOptions {
    // ...
    [FooModule setup];
    [[BarModule sharedInstance] setup];
    // ...
    return YES;
}

其实这些代码完全可以利用Notification的方式在自己的模块内部搞定，分享一个巧妙的方法：

1
2
3
4
5
6
7
8
9
10
11
12
13

/// FooModule.m
+ (void)load
{
    __block id observer =
    [[NSNotificationCenter defaultCenter]
     addObserverForName:UIApplicationDidFinishLaunchingNotification
     object:nil
     queue:nil
     usingBlock:^(NSNotification *note) {
         [self setup]; // Do whatever you want
         [[NSNotificationCenter defaultCenter] removeObserver:observer];
     }];
}

解释：

• + load方法在足够早的时间点被调用
• block 版本的通知注册会产生一个__NSObserver *对象用来给外部 remove 观察者
• block 对 observer 对象的捕获早于函数的返回，所以若不加__block，会捕获到 nil
• 在 block 执行结束时移除 observer，无需其他清理工作
• 这样，在模块内部就完成了在程序启动点代码的挂载

值得注意的是，通知是在- application:didFinishLaunchingWithOptions:调用完成后才发送的。
顺便提下给 AppDelegate 瘦身的建议：AppDelegate 作为程序级状态变化的 delegate，应该只做路由和分发的作用，具体逻辑实现代码还是应该在分别的模块中，这个文件应该保持整洁，除了<UIApplicationDelegate>的方法外不应该出现其他方法。

终究还是来了。Apple下发了支持64位的最后通牒：

As we announced in October, beginning February 1, 2015 new iOS apps submitted to the App Store must include 64-bit support and be built with the iOS 8 SDK. Beginning June 1, 2015 app updates will also need to follow the same requirements.

早应该做的适配终于要开始动工了，苦了64位的CPU运行了这么久32位的程序。前段时间公司项目完成了64-bit包的适配，本没那么复杂的事被无数不标准的老代码搅和的不轻，总结几个Tip共勉。

Tips

拒绝基本数据类型和隐式转换

首当其冲的就是基本类型，比如下面4个类型在32-bit和64-bit下分别是多长呢？

1
2
3
4

size_t s1 = sizeof(int);
size_t s2 = sizeof(long);
size_t s3 = sizeof(float);
size_t s4 = sizeof(double);

32-bit下：4, 4, 4, 8；64-bit下：4, 8, 4, 8
（PS： 这个结果随编译器，换其他平台可不一定）
它们的长度变化可能并非我们对64-bit长度加倍的预期，所以说，程序中出现sizeof的代码多看两眼。而且，除非你明确知道自己在做什么，应该使用下面的类型代替基本类型：

• int -> NSInteger
• unsigned -> NSUInteger
• float -> CGFloat
• 动画时间 -> NSTimeInterval
• …

这些都是SDK中定义的类型，而我们大部分时间都在跟SDK的API们打交道，使用它们能将类型转换的影响降低很多。

再比如说下面的代码：

1
2
3
4

NSArray *items = @[@1, @2, @3];
for (int i = -1; i < items.count; i++) {
    NSLog(@"%d", i);
}

结果是，for循环一次都没有进。
数组的count是NSUInteger类型的，-1与其比较时隐式转换成NSUInteger，变成了一个很大的数字：

1
2
3
4

(lldb) p i
(int) $0 = -1
(lldb) p (NSUInteger)i
(NSUInteger) $1 = 18446744073709551615

这和64-bit到没啥关系，想要说明的是，这种隐式转换也需要小心，一定要注意和这个变量相关的所有操作（赋值、比较、转换）
老式for循环可以考虑写成：

1

for (NSUInteger index = 0; index < items.count; index++) {}

当然，数组遍历还是更推荐用for-in或block版本的，它们之间的比较可以回顾下这篇文章。

使用新版枚举

和上面的原因差不多，枚举应该使用新版的写法：

1
2
3
4
5
6

typedef NS_ENUM(NSInteger, UIViewAnimationCurve) {
    UIViewAnimationCurveEaseInOut,
    UIViewAnimationCurveEaseIn,
    UIViewAnimationCurveEaseOut,
    UIViewAnimationCurveLinear
};

不仅能为枚举值指定类型，而且当赋值赋错类型时，编译器还会给出警告，没理由不用这种写法。

替代Format字符串

适配64-bit时，你是否遇到了下面的恶心写法：

1
2

NSArray *items = @[@1, @2, @3];
NSLog(@"数组元素个数：%lu", (unsigned long)items.count);

一般情况下，利用NSNumber的@语法糖就可以解决：

1
2

NSArray *items = @[@1, @2, @3];
NSLog(@"数组元素个数：%@", @(items.count));

同理，int转string也可以：

1
2

NSInteger i = 10086;
NSString *string = @(i).stringValue;

当然，如需要%.2f这种Format就不适用了。

64-bit下的BOOL

32-bit下，BOOL被定义为signed char，@encode(BOOL)的结果是'c'
64-bit下，BOOL被定义为bool，@encode(BOOL)结果是'B'
更直观的解释是：

1
2
3
4

(lldb) p/t (signed char)7
(BOOL) $0 = 0b00000111 (YES)
(lldb) p/t (bool)7
(bool) $1 = 0b00000001 (YES)

32-bit版本的BOOL包括了256个值的可能性，还会引起一些坑，像这篇文章所说的。而64-bit下只有0（NO），1（YES）两种可能，终于给BOOL正了名。

不直接取isa指针

编译器已经默认禁用了这种使用，isa指针在32位下是Class的地址，但在64位下利用bits mask才能取出来真正的地址，若真需要，使用runtime的object_getClass 和object_setClass方法。关于64位下isa的讲解可以看这篇文章

解决第三方lib依赖和lipo命令

以源码形式出现在工程中的第三方lib，只要把target加上arm64编译就好了。
恶心的就是直接拖进工程的那些静态库(.a)或者framework，就需要重新找支持64-bit的包了。这时候就能看出哪些是已无人维护的lib了，是时候找个替代品了（比如我全网找不到工程中用到的一个音频库的64位包，终于在一个哥们的github上找到，哭着给了个star- -）

打印Mach-O文件支持的架构

如何看一个可执行文件是不是支持64-bit呢？

使用lipo -info命令，比如看看UIKit支持的架构：

1
2
3

// 当前在Xcode Frameworks目录
sunnyxx$ lipo -info UIKit.framework/UIKit
Architectures in the fat file: UIKit.framework/UIKit are: arm64 armv7s

想看的更详细的信息可以使用lipo -detailed_info：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

sunnyxx$ lipo -detailed_info UIKit.framework/UIKit
Fat header in: UIKit.framework/UIKit
fat_magic 0xcafebabe
nfat_arch 2
architecture arm64
    cputype CPU_TYPE_ARM64
    cpusubtype CPU_SUBTYPE_ARM64_ALL
    offset 4096
    size 16822272
    align 2^12 (4096)
architecture armv7s
    cputype CPU_TYPE_ARM
    cpusubtype CPU_SUBTYPE_ARM_V7S
    offset 16826368
    size 14499840
    align 2^12 (4096)

当然，还可以使用file命令：

1
2
3
4

sunnyxx$ file UIKit.framework/UIKit
UIKit.framework/UIKit: Mach-O universal binary with 2 architectures
UIKit.framework/UIKit (for architecture arm64):Mach-O 64-bit dynamically linked shared library
UIKit.framework/UIKit (for architecture armv7s):Mach-O dynamically linked shared library arm

上述命令对Mach-O文件适用，静态库.a文件，framework中的.a文件，自己app的可执行文件都可以打印下看看。

合并多个架构的包

如果，我们有MyLib-32.a和MyLib-64.a，可以使用lipo -create命令合并：

1

sunnyxx$ lipo -create MyLib-32.a MyLib-64.a -output MyLib.a

支持64-bit后程序包会变大么？

会，支持64-bit后，多了一个arm64架构，理论上每个架构一套指令，但相比原来会大多少还不好说，我们这里增加了大概50%，还有听说会增加一倍的。

一个lib包含了很多的架构，会打到最后的包里么？

不会，如果lib中有armv7, armv7s, arm64, i386架构，而target architecture选择了armv7s, arm64，那么只会从lib中link指定的这两个架构的二进制代码，其他架构下的代码不会link到最终可执行文件中；反过来，一个lib需要在模拟器环境中正常link，也得包含i386架构的指令。

Checklist

最后列一下官方文档中的注意点：

• 不要将指针强转成整数
• 程序各处使用统一的数据类型
• 对不同类型的整数做运算时一定要注意
• 需要定长变量时，使用如int32_t, int64_t这种定长类型
• 使用malloc时，不要写死size
• 使用能同时适配两个架构的格式化字符串
• 注意函数和函数指针（类型转换和可变参数）
• 不要直接访问Objective-C的指针（isa）
• 使用内建的同步原语（Primitives）
• 不要硬编码虚存页大小
• Go Position Independent

References

https://developer.apple.com/library/prerelease/ios/documentation/General/Conceptual/CocoaTouch64BitGuide/Introduction/Introduction.html#//apple_ref/doc/uid/TP40013501-CH1-SW1
http://www.sealiesoftware.com/blog/archive/2013/09/24/objc_explain_Non-pointer_isa.html
http://www.bignerdranch.com/blog/64-bit-smorgasbord/
http://www.bignerdranch.com/blog/bools-sharp-corners/