4

我正在使用 Xcode 4.6.1，并且我有一个 iOS 6.1 应用程序。

它有一个表格视图，可以向下钻取到另一个表格视图。第二个表格视图使用自定义单元格来显示其数据。然而，第二个表格视图有一个问题：它的内容大小通常是错误的（特别是高度，要么太高要么太短）。这要么导致底部有额外的空间，要么没有足够的空间滚动到底部。

下图显示了我制作的一个测试应用程序的四个屏幕截图，它重现了该问题。我将介绍导致我的问题的步骤。

我的测试应用程序中的四张图片

  1. 应用程序加载，并显示第一个表。它有三行向下钻取到第二个表。

  2. 我选择第一行，即“列表：0 到 10”。导航控制器将第二个表格推到屏幕上。它有 11 行，并且（正确地）具有 11 行的内容大小。

  3. 然后我返回并选择了下一行，即“列表：A 到 P”。第二个表格再次出现在屏幕上，现在它有 16 行。但是，它只有 11 行的内容大小。其他 5 行仍在下方，但内容大小不断反弹到第 11 行。

  4. 然后我返回并选择了最后一行，即“List: a to f”。第二个表格再次出现在屏幕上，它有 6 行。但是，它仍然具有 11 行的内容大小。表格视图底部空间太大，底部显示 5 个单元格，其中没有任何内容。

这里的模式是内容大小保持在最初加载时的大小。因此，我选择的第一行将具有正确的内容大小，但所有其他行现在都将保持该大小，无论它们有多少行。这也意味着如果我首先选择了“列表：a 到 f”，它有 6 行，那么所有其他的都会有 6 行的内容大小，因为它保持在我选择的第一行的内容大小.

在我的代码中，我自己从不更改内容大小；这一切都是自动发生的。为了弄清楚表格视图何时以及为何改变其内容大小，我在第二个表格的“contentSize”属性上设置了一个观察者。在我这样做之后，我意识到内容大小并没有保持不变，但是当我选择一行时它实际上被更改了两次：首先是正确的大小（重新加载表格视图时），然后恢复到旧尺寸（当表格视图出现时）。

所以我试图弄清楚为什么它被恢复到旧的大小。为了查看幕后发生的事情，我让它在每次观察到内容大小发生变化时打印出堆栈跟踪。

在下面，您可以看到前面引导您完成的步骤的控制台日志。但是，为了节省空间并使其更具可读性，我将长堆栈跟踪替换为“（堆栈跟踪类型 A）”之类的消息。稍后我将向您展示它们的详细信息，但现在我只是将它们称为堆栈跟踪类型 A、B 或 C。

first table: selected row 0 (List: 0 to 10)
second table: viewDidLoad
OBSERVED CHANGE: contentSize.height = 484 (row count = 11)
(Stack Trace Type A)
OBSERVED CHANGE: contentSize.height = 484 (row count = 11)
(Stack Trace Type B)
second table: viewWillAppear
OBSERVED CHANGE: contentSize.height = 484 (row count = 11)
(Stack Trace Type C)
second table: viewDidAppear
*going back to first table*
second table: viewWillDisappear
second table: viewDidDisappear

first table: selected row 1 (List: A to P)
OBSERVED CHANGE: contentSize.height = 704 (row count = 16)
(Stack Trace Type A)
second table: viewWillAppear
OBSERVED CHANGE: contentSize.height = 484 (row count = 16)
(Stack Trace Type C)
second table: viewDidAppear
*going back to first table*
second table: viewWillDisappear
second table: viewDidDisappear

first table: selected row 2 (List: a to f)
OBSERVED CHANGE: contentSize.height = 264 (row count = 6)
(Stack Trace Type A)
second table: viewWillAppear
OBSERVED CHANGE: contentSize.height = 484 (row count = 6)
(Stack Trace Type C)
second table: viewDidAppear
*going back to first table*
second table: viewWillDisappear
second table: viewDidDisappear

如您所见，它将内容大小恢复为旧大小。在这种情况下，这将是 484，这足以显示 11 个高度为 44 的单元格。如果一切正常，则观察到的与Stack Trace Type C相结合的变化将不会发生。所以换句话说，C 型是导致问题的原因。

现在我将向您展示堆栈跟踪的实际外观。请注意，前两个（A 和 B）与问题无关。我展示它们只是为了让您可以将它们与 C 型进行比较/对比，C 型似乎是导致问题的原因。

（堆栈跟踪类型 A） 当表格视图因重新加载而更改其内容大小时，堆栈跟踪看起来像这样。

(
    0   CustomTableCellTest   0x00002fe0 -[MasterViewController observeValueForKeyPath:ofObject:change:context:] + 320
    1   Foundation            0x00b0d417 NSKeyValueNotifyObserver + 357
    2   Foundation            0x00b26b24 NSKeyValueDidChange + 456
    3   Foundation            0x00adbd60 -[NSObject(NSKeyValueObserverNotification) didChangeValueForKey:] + 131
    4   Foundation            0x00b48b80 _NSSetSizeValueAndNotify + 185
    5   UIKit                 0x000b57ef -[UITableView(_UITableViewPrivate) _updateContentSize] + 782
    6   UIKit                 0x000c3974 -[UITableView noteNumberOfRowsChanged] + 154
    7   UIKit                 0x000c32dc -[UITableView reloadData] + 769
    8   CustomTableCellTest   0x00004d97 -[MetaMasterViewController tableView:didSelectRowAtIndexPath:] + 567
    9   UIKit                 0x000c7285 -[UITableView _selectRowAtIndexPath:animated:scrollPosition:notifyDelegate:] + 1194
    10  UIKit                 0x000c74ed -[UITableView _userSelectRowAtPendingSelectionIndexPath:] + 201
    11  Foundation            0x00ad15b3 __NSFireDelayedPerform + 380
    12  CoreFoundation        0x01c55376 __CFRUNLOOP_IS_CALLING_OUT_TO_A_TIMER_CALLBACK_FUNCTION__ + 22
    13  CoreFoundation        0x01c54e06 __CFRunLoopDoTimer + 534
    14  CoreFoundation        0x01c3ca82 __CFRunLoopRun + 1810
    15  CoreFoundation        0x01c3bf44 CFRunLoopRunSpecific + 276
    16  CoreFoundation        0x01c3be1b CFRunLoopRunInMode + 123
    17  GraphicsServices      0x01bf07e3 GSEventRunModal + 88
    18  GraphicsServices      0x01bf0668 GSEventRun + 104
    19  UIKit                 0x00017ffc UIApplicationMain + 1211
    20  CustomTableCellTest   0x000021ed main + 141
    21  CustomTableCellTest   0x00002115 start + 53
)

（堆栈跟踪类型 B） 这仅在表视图第一次出现时发生，因此只发生一次。我相信它发生在表格最初加载其视图时。

(
    0   CustomTableCellTest   0x00002fe0 -[MasterViewController observeValueForKeyPath:ofObject:change:context:] + 320
    1   Foundation            0x00b0d417 NSKeyValueNotifyObserver + 357
    2   Foundation            0x00b26b24 NSKeyValueDidChange + 456
    3   Foundation            0x00adbd60 -[NSObject(NSKeyValueObserverNotification) didChangeValueForKey:] + 131
    4   Foundation            0x00b48b80 _NSSetSizeValueAndNotify + 185
    5   UIKit                 0x000b57ef -[UITableView(_UITableViewPrivate) _updateContentSize] + 782
    6   UIKit                 0x000cbc8e -[UITableView _rectChangedWithNewSize:oldSize:] + 261
    7   UIKit                 0x000cc231 -[UITableView setFrame:] + 279
    8   UIKit                 0x000f5014 +[UIViewControllerWrapperView wrapperViewForView:frame:] + 448
    9   UIKit                 0x00110e18 -[UINavigationController _startTransition:fromViewController:toViewController:] + 239
    10  UIKit                 0x0011189b -[UINavigationController _startDeferredTransitionIfNeeded:] + 386
    11  UIKit                 0x00111e93 -[UINavigationController pushViewController:transition:forceImmediate:] + 1030
    12  UIKit                 0x00111a88 -[UINavigationController pushViewController:animated:] + 62
    13  CustomTableCellTest   0x00004e21 -[MetaMasterViewController tableView:didSelectRowAtIndexPath:] + 705
    14  UIKit                 0x000c7285 -[UITableView _selectRowAtIndexPath:animated:scrollPosition:notifyDelegate:] + 1194
    15  UIKit                 0x000c74ed -[UITableView _userSelectRowAtPendingSelectionIndexPath:] + 201
    16  Foundation            0x00ad15b3 __NSFireDelayedPerform + 380
    17  CoreFoundation        0x01c55376 __CFRUNLOOP_IS_CALLING_OUT_TO_A_TIMER_CALLBACK_FUNCTION__ + 22
    18  CoreFoundation        0x01c54e06 __CFRunLoopDoTimer + 534
    19  CoreFoundation        0x01c3ca82 __CFRunLoopRun + 1810
    20  CoreFoundation        0x01c3bf44 CFRunLoopRunSpecific + 276
    21  CoreFoundation        0x01c3be1b CFRunLoopRunInMode + 123
    22  GraphicsServices      0x01bf07e3 GSEventRunModal + 88
    23  GraphicsServices      0x01bf0668 GSEventRun + 104
    24  UIKit                 0x00017ffc UIApplicationMain + 1211
    25  CustomTableCellTest   0x000021ed main + 141
    26  CustomTableCellTest   0x00002115 start + 53
)

因此，当事情正常工作时，类型 A 和 B 都会发生。但是，当事情不能正常工作时，我也会得到下一个堆栈跟踪。

（堆栈跟踪类型 C） 这是在内容大小恢复到旧大小时发生的堆栈跟踪。

(
    0   CustomTableCellTest   0x00003080 -[MasterViewController observeValueForKeyPath:ofObject:change:context:] + 320
    1   Foundation            0x00b0d417 NSKeyValueNotifyObserver + 357
    2   Foundation            0x00b26b24 NSKeyValueDidChange + 456
    3   Foundation            0x00adbd60 -[NSObject(NSKeyValueObserverNotification) didChangeValueForKey:] + 131
    4   Foundation            0x00b48b80 _NSSetSizeValueAndNotify + 185
    5   UIKit                 0x0007c213 -[UIScrollView _resizeWithOldSuperviewSize:] + 161
    6   UIKit                 0x0005cf2a -[UIView(Geometry) resizeWithOldSuperviewSize:] + 72
    7   UIKit                 0x0005bb28 __46-[UIView(Geometry) resizeSubviewsWithOldSize:]_block_invoke_0 + 80
    8   CoreFoundation        0x01cb85a7 __NSArrayChunkIterate + 359
    9   CoreFoundation        0x01c9003f __NSArrayEnumerate + 1023
    10  CoreFoundation        0x01c8fa16 -[NSArray enumerateObjectsWithOptions:usingBlock:] + 102
    11  UIKit                 0x0005babf -[UIView(Geometry) resizeSubviewsWithOldSize:] + 149
    12  UIKit                 0x00557dcc -[UIView(AdditionalLayoutSupport) _is_layout] + 143
    13  UIKit                 0x000607ae -[UIView(Hierarchy) layoutSubviews] + 80
    14  UIKit                 0x000682dd -[UIView(CALayerDelegate) layoutSublayersOfLayer:] + 279
    15  libobjc.A.dylib       0x010e76b0 -[NSObject performSelector:withObject:] + 70
    16  QuartzCore            0x02292fc0 -[CALayer layoutSublayers] + 240
    17  QuartzCore            0x0228733c _ZN2CA5Layer16layout_if_neededEPNS_11TransactionE + 468
    18  QuartzCore            0x02287150 _ZN2CA5Layer28layout_and_display_if_neededEPNS_11TransactionE + 26
    19  QuartzCore            0x022050bc _ZN2CA7Context18commit_transactionEPNS_11TransactionE + 324
    20  QuartzCore            0x02206227 _ZN2CA11Transaction6commitEv + 395
    21  QuartzCore            0x022068e2 _ZN2CA11Transaction17observer_callbackEP19__CFRunLoopObservermPv + 96
    22  CoreFoundation        0x01c5eafe __CFRUNLOOP_IS_CALLING_OUT_TO_AN_OBSERVER_CALLBACK_FUNCTION__ + 30
    23  CoreFoundation        0x01c5ea3d __CFRunLoopDoObservers + 381
    24  CoreFoundation        0x01c3c7c2 __CFRunLoopRun + 1106
    25  CoreFoundation        0x01c3bf44 CFRunLoopRunSpecific + 276
    26  CoreFoundation        0x01c3be1b CFRunLoopRunInMode + 123
    27  GraphicsServices      0x01bf07e3 GSEventRunModal + 88
    28  GraphicsServices      0x01bf0668 GSEventRun + 104
    29  UIKit                 0x00017ffc UIApplicationMain + 1211
    30  CustomTableCellTest   0x000021ed main + 141
    31  CustomTableCellTest   0x00002115 start + 53
)

正如你所看到的，发生了一些 QuartzCore 的东西，这些东西在 Type A 或 B 中是不存在的。此外，在 Type C 的几行中，实际上在幕后调用了带有“OldSize”字样的方法。名字。因此，显然它确实将其恢复为“旧尺寸”。但是，我仍然不明白为什么首先要调用这些 QuartzCore 和“OldSize”方法。

我尝试查找“resizeSubviewsWithOldSize”，但我能找到的唯一文档是NSView（适用于 OS X 应用程序，而不是使用 UIView 的 iOS 应用程序）。文档中的这个描述并没有真正帮助我理解为什么在这种情况下调用它。

但是，即使我不知道为什么要调用它，但我对何时调用它有一个很好的了解。通过更多的测试，我意识到它会在表格视图出现时恢复到旧的内容大小，有时当它消失时。

例如，当我让一个模态视图覆盖屏幕然后消失时，内容大小实际上改变了 3 次。日志消息看起来像这样。

*Modal view entering*
second table: viewWillDisappear
OBSERVED CHANGE: contentSize.height = 484 (row count = 11)
(Stack Trace Type C)
second table: viewDidDisappear

*Modal view exiting*
second table: viewWillAppear
OBSERVED CHANGE: contentSize.height = 484 (row count = 11)
(Stack Trace Type C)
second table: viewDidAppear
OBSERVED CHANGE: contentSize.height = 484 (row count = 11)
(Stack Trace Type C)

因此，更改与重新加载的表视图无关：它与它的出现和消失有关。我猜视图每次出现时都会尝试布局其子视图，因此我的自定义单元格的布局方式似乎存在问题。

最初我认为问题在于我的自定义单元格的设置方式：在我的代码中或在 xib 中。这是因为当我不使用自定义单元格时问题消失了。但是有一次我在自定义单元格xib中关闭了自动布局，问题也消失了。所以显然这个问题与自动布局有关。

为了方便调试，我在xib中设置单元格的方式很简单：单元格上唯一的东西就是一个灰色背景色的UILabel。所有的自动布局约束都是 Interface Builder 的默认约束。您可以在下面看到我的自定义单元格 xib 的样子。

MasterCell xib

我还尝试删除 UILabel 以便单元格上没有任何内容，然后我打开了自动布局。当我这样做时，问题也消失了。所以我猜想在单元格上设置 UILabel 的方式有问题。这很奇怪，因为它是由 Interface Builder 设置的那些我无法删除的“紫色”默认约束。

在四处寻找有关表格视图单元格中自动布局的信息后，我遇到了这个问题。显然，Interface Builder 没有正确地将其约束设置为单元格的内容视图。我不确定这是否与我的问题有关，但我还是尝试了。我使用了 Adrian 发布的解决方案，看起来像这样。

//  MasterCell.m
//  My custom UITableViewCell subclass

- (void)awakeFromNib {
    [super awakeFromNib];

    for (NSLayoutConstraint *cellConstraint in self.constraints) {

        [self removeConstraint:cellConstraint];

        id firstItem = cellConstraint.firstItem == self ? self.contentView : cellConstraint.firstItem;
        id seccondItem = cellConstraint.secondItem == self ? self.contentView : cellConstraint.secondItem;

        NSLayoutConstraint *contentViewConstraint =
        [NSLayoutConstraint constraintWithItem:firstItem
                                     attribute:cellConstraint.firstAttribute
                                     relatedBy:cellConstraint.relation
                                        toItem:seccondItem
                                     attribute:cellConstraint.secondAttribute
                                    multiplier:cellConstraint.multiplier
                                      constant:cellConstraint.constant];

        [self.contentView addConstraint:contentViewConstraint];
    }
}

然而，虽然它似乎做了它打算做的事情（即更改与内容视图相关的约束而不是单元格本身），但这仍然没有解决我的问题：内容大小仍然恢复到旧尺寸。

总而言之，为了澄清这个相当长的问题，这基本上就是我要问的。

为什么当我在自定义表格单元格 xib 中启用自动布局时，当表格出现在屏幕上时，表格视图的内容大小会错误地重新调整回“旧大小”？

4

1 回答 1

1

您正在为“主”表重新使用相同的表视图控制器实例，但您正在以错误的顺序向它发送消息。

你像这样推动控制器：

if (!self.masterViewController) {
    self.masterViewController = [[MasterViewController alloc] init];
}

self.masterViewController.objects = self.masterObjects[indexPath.row];

[self.masterViewController.tableView reloadData];
[self.navigationController pushViewController:self.masterViewController animated:YES];

如果您只是交换 reloadData 和 push 行，那么您的问题就会消失。

我不完全确定这里发生了什么，但我认为问题在于，一旦弹出主控制器，它就没有任何参考框架（双关语！）在重新加载它时计算适当的内容大小，所以它可能没有缓存这个新高度的内容大小。

然后，当视图被推送时，滚动视图突然又有了一个上下文，它知道它已经重新计算了，所以使用缓存的内容大小。无论如何，这就是我从堆栈跟踪中得到的印象（正如你所做的那样）。您选择的第一张桌子总是很好，因为没有旧尺寸可用。如果你用故事板做这个，你每次都会实例化一个新的主控制器，你永远不会注意到问题。

至于为什么自动布局有什么不同，好吧，我只是在这里猜测和挥手，但是在自动布局下，一切都发生在视图控制器生命周期的后期，而不是在显式布局下。如果您一直有自动布局，那么在没有超级视图（因此对其大小没有限制）的视图中，自动布局无法计算出应该是什么大小。这可能是一个错误，但解决方法很简单，正如我所说，通常在将新视图控制器推送到导航堆栈时，你会初始化新的，当它们被弹出时它们会消失，所以你永远不会看到这。

于 2013-03-24T13:04:22.693 回答