The phenomenon of

The solution

UIView *viewTemp = [[UIView alloc] initWithFrame:CGRectMake(0, 0, ScreenWidth, heightUse)];
[viewTemp addSubview:self.viewHeader];
[self.viewHeader mas_makeConstraints:^(MASConstraintMaker *make) {
    make.edges.equalTo(viewTemp).priority(900);
}];

self.tableView.tableHeaderView = viewTemp;
Copy the code

Problem analysis

self.viewHeader.frame = CGRectMake(0, 0, ScreenWidth, heightUse);
self.tableView.tableHeaderView = self.viewHeader;
Copy the code

The self. The tableView. TableHeaderView size at the beginning of 0. Then set the self. The tableView. TableHeaderView = self. ViewHeader; Cause the runLoop within a cycle of self, tableView. TableHeaderView size to change. Change from 0 to the size of self.viewheader.

Because of the self. The tableView. TableHeaderView = self. ViewHeader; So the self. The tableView. TableHeaderView dimensional change is reflected in the self. ViewHeader size changes. The size of self.viewHeader changes from 0 to a set size.

In the self.viewheader change, we start with size 0. There may be a conflict in our layout. In fact, we rarely, if ever, think about the layout of the bottom view being 0, we think it’s never going to be 0, it’s all in our control, but the head layout of the tableView is so dimensioned that we start with the outermost view being 0. Cause a constrained conflict, where the console prints an alert, and maybe a lot of warnings. Each warning has a similar problem, xxxview.width == 0.

==”<NSLayoutConstraint:0x600001ac0140 xxxView:0x7ff534cca8a0.width == 0>”==

This warning also reflects constraint conflicts caused by a parent view width of 0. When the view expands, our constraints are no longer in conflict, and runLoop updates the UI without any problems, so the interface behaves normally again. But there was a constraint conflict, and the console sent a warning message.

And here we actually know why. The outermost view size of our custom view becomes 0, so our view has a constraint conflict. The console prints a constraint warning. And then when we expand our view size everything works fine again, and there’s nothing wrong with the UI.

prove

Solution analysis

The first approach: use priorities

As you can see, our solution is to create a new viewTemp and add our self.viewheader to the viewTemp. Constraint is being performed and the priority is set to 900.

At this point, we start with self.viewheader size 0, and our custom view size tries to shrink to 0. However, constraint conflicts were found and no further reduction was carried out due to low priority. When self.viewHeader is expanded, our custom view tries to expand, and it expands without problem.

The second option is to apply the constraint in the next loop of the runLoop

Testing this method can also solve the problem. The dimensions of viweTemp are expanded from 0 during the first runLoop. This has nothing to do with self.viewheader.

The constraint is completed two cycles below runLoop. At this point, the superview has already changed its layout, and the view is fully expanded, so self.viewheader is not affected.

Recommendation: The first method

The second method is to update the UI twice, and if you miscalculate, you might see an incorrect UI the first time. So this method is not recommended.

conclusion

When we meet with the console print = = “< NSLayoutConstraint: 0 x600001ac0140 xxxView: 0 x7ff534cca8a0. Width = = 0 >” = =. At this point, the UI is intact.

At this time we want to check whether use the tableView. TableHeaderView, if it is, then this modified to give it a try.