从iOS7开始，在我的UITableView顶部有额外的空间它有一个UITableViewStyleGrouped样式。
这里有一个例子:
tableview从第一个箭头开始，有35个像素的无法解释的填充，然后绿色的头是一个由viewForHeaderInSection返回的UIView(其中section为0)。
有人能解释一下这个35像素的数量是从哪里来的吗?我如何才能在不切换到UITableViewStylePlain的情况下摆脱它?
更新(回答):
在iOS 11及更高版本中:
tableView.contentInsetAdjustmentBehavior = .never
当前回答
我认为制作UIEdgeInsets -35 0 0 0是乏味的。在我的例子中，我实现了tableView: hightforheaderinsection:方法，它有可能返回0。
当我把0改成0.1f时，问题就消失了。
其他回答
我假设这只是新UITableViewStyleGrouped样式的一部分。它存在于所有分组表视图中，似乎没有任何直接的方法来控制该空间。
如果这个空间是由一个UIView表示的，那么可以搜索UITableView的所有子视图来找到那个特定的视图并直接编辑它。然而，也有可能该空间只是标题和单元格开始之前的硬编码偏移量，没有任何方法来编辑它。
要搜索所有子视图(我将在表没有单元格时运行这段代码，以使它更容易阅读输出):
- (void)listSubviewsOfView:(UIView *)view {
// Get the subviews of the view
NSArray *subviews = [view subviews];
// Return if there are no subviews
if ([subviews count] == 0) return;
for (UIView *subview in subviews) {
NSLog(@"%@", subview);
// List the subviews of subview
[self listSubviewsOfView:subview];
}
}
在我的例子中，在Storyboard的原型可视化中有一个不需要的名为HeaderView的单元格，当我删除它时，一切都很好。
在ios7中，你的视图开始于屏幕的上方，而不是导航栏的下方。它非常简单的设置到底部的导航栏。检查这个答案的解决方案，这不是同一个问题，但非常相关的你。
我已经找到了我最初的bug的原因，并创建了一个示例项目来展示它。我相信有一个iOS7漏洞。
在iOS7中，如果你用分组样式创建一个UITableView，但是在第一个布局上没有设置一个委托，然后你设置了一个委托并调用reloadData，在顶部会有一个35px的空间，永远不会消失。
看这个项目我做的展示bug: https://github.com/esilverberg/TableViewDelayedDelegateBug
特别是这个文件:https://github.com/esilverberg/TableViewDelayedDelegateBug/blob/master/TableViewDelayedDelegateBug/ViewController.m
如果第24行是活动的，
[self performSelector:@selector(updateDelegate) withObject:nil afterDelay:0.0];
在顶部会有一个额外的35px空间。如果第27行是活动的，第24行被注释掉，
self.tableView.delegate = self;
顶部没有空间。这就像tableView在某处缓存结果而不是在委托设置和reloadData调用后重新绘制自己。
我也一直在想这个问题。我很确定这是iOS7的漏洞。 最终帮助我的，是xib中的观点顺序。在一个视图中，表视图被正确显示，在另一个视图中，表视图有额外的35px空间。两者之间唯一的区别(UITableView)是，在显示不好的视图中，UITableView是第一个子，而在显示正常的视图中，它是第二个。
这对我来说很有用，只是改变了视图的顺序。我真的不喜欢为了解决问题而添加额外的代码。
