ios - 由于自动布局和大量 subview ，关闭 VC 非常慢

Question

我有一个加载了很多 subview 的 ScrollView ，出于我不会深入探讨的原因，我选择反对 cell 重用和 UITableView。它运行良好，除了在填充 View 时有一点初始主线程滞后。但是，每次 VC "on top" 被关闭时(例如在呈现模态 overtop 之后)，都会有明显的延迟(2-3 秒)。我通过分析器运行它，堆栈跟踪非常深入地研究了 IOS/Autolayout，如附图所示。

代码似乎进入 NSLayoutConstraint("+0x06 calll "-[NSLayoutConstraint _addToEngine:]+0x0b")​​。

我能做些什么来绕过这种明显的约束重新应用吗？

Answer 1

为什么你的 ScrollView 的性能很差

从您的轨迹来看，您的问题的根源从转换回来开始:您将 80% 以上的时间花在 -[UITransitionView transition:fromView:toView:removeFromView:] 上。此方法立即将您转换到的 View 添加回 View 层次结构(-addSubview: 调用如下)，这需要完整的自动布局传递。

我不知道有什么方法可以强制普通的 iOS View Controller 转换系统将您的旧 View 保留在后台，可以这么说，以避免这种自动布局传递。 (如果多个 View 堆积在屏幕外并开始导致内存压力，这种方法实际上可能会遇到自己的一系列问题。)

在现有结构中加速自动布局

尽管如此，您还是可以尝试通过多种方式优化您的自动布局过程。首先，修改 ScrollView 以减少 subview 。 Apple 的开发人员技术支持有时也建议扁平化 View 层次结构；使自动布局减少递归有时会有所帮助。 (例如，参见 Florian Kugler 和 Martin Pilkington 执行的性能测试。)

您还应该始终确保将约束安装在层次结构中可能最深的 View 上，同时仍然位于它相关的两个 View 的共同祖先上。例如，如果 View A 有 subview B 和 C，您可能希望在 View C 上安装一个仅引用 View C 的约束，而不是 View A；但是，A 上需要存在与 B 和 C 相关的约束。这对于所有 Auto Layout 工作来说是一个很好的指南，而不仅仅是在这种特殊情况下；层次结构中安装的约束越深，底层求解器在任何特定级别的工作速度就越快。

改变你的方法

UITableView 能够通过在自动布局系统中提供一种中断来避免这个问题:表格 View 可以使用约束正确定位，然后使用它自己的委托(delegate)方法(例如 -tableView:heightForRowAtIndexPath:) 和一些内部布局魔术来为每个单元格单独运行自动布局，而不需要一次布置整个 View 。常规的 UIScrollViews 没有这种优化的奢侈。

我知道您说过您有理由不在此处采用 UITableView，但您可能会考虑重新审视这些原因。从切换到 UITableView 和实现委托(delegate)方法 -tableView:estimatedHeightForRowAtIndexPath:，您可以看到一些非常显着的速度改进，这让您可以在 View 加载时短路大量自动布局计算并将它们推迟到您即将在屏幕上滚动新单元格的位置。在这个方向上已经进行了一些相当重要的实验，既here on StackOverflow以及社区中的其他人。 (快速搜索“UITableView Auto Layout height”会出现几十个结果。)

祝你好运!