UITableViewAlertForLayoutOutsideViewHierarchy错误:仅警告一次(iOS 13 GM) [英] UITableViewAlertForLayoutOutsideViewHierarchy error: Warning once only (iOS 13 GM)

查看:900
本文介绍了UITableViewAlertForLayoutOutsideViewHierarchy错误:仅警告一次(iOS 13 GM)的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

在执行Segue时,iOS13出现了一个奇怪的错误,我无法弄清这是什么意思,也找不到针对此错误的任何文档.问题在于,这似乎会导致很多延迟(几秒钟),直到执行segue为止.

I am getting a strange error with iOS13 when performing a Segue and I can't figure out what it means, nor can I find any documentation for this error. The problem is that this seems to cause a lot of lag (a few seconds) until the segue is performed.

2019-09-11 22:45:38.861982 + 0100 Thrive [2324:414597] [TableView]仅警告一次:通知UITableView布局其可见单元格 和其他内容,而不必处于视图层次结构中(表视图 或尚未将其超级视图之一添加到窗口中).这可能 通过强制表视图内的视图加载和执行而导致错误 没有准确信息的布局(例如表格视图范围,特征 收集,布局边距,安全区域插图等),并且还将 由于额外的布局传递而导致不必要的性能开销. 在以下位置建立象征性的断点 UITableViewAlertForLayoutOutsideViewHierarchy可以在 调试器,看看是什么原因导致这种情况的发生,因此您可以避免这种情况 如果可能的话,请完全采取行动,或将其推迟到表格视图中 已添加到窗口.表格视图:层=; contentOffset:{0,0}; contentSize:{315,118}; AdjustedContentInset:{0,0,0,0}; dataSource:>

2019-09-11 22:45:38.861982+0100 Thrive[2324:414597] [TableView] Warning once only: UITableView was told to layout its visible cells and other contents without being in the view hierarchy (the table view or one of its superviews has not been added to a window). This may cause bugs by forcing views inside the table view to load and perform layout without accurate information (e.g. table view bounds, trait collection, layout margins, safe area insets, etc), and will also cause unnecessary performance overhead due to extra layout passes. Make a symbolic breakpoint at UITableViewAlertForLayoutOutsideViewHierarchy to catch this in the debugger and see what caused this to occur, so you can avoid this action altogether if possible, or defer it until the table view has been added to a window. Table view: ; layer = ; contentOffset: {0, 0}; contentSize: {315, 118}; adjustedContentInset: {0, 0, 0, 0}; dataSource: >

我正在使用Hero,但是我尝试禁用它并使用常规的Segue,但这并没有阻止这种滞后.

I am using Hero but I tried disabling it and using a regular Segue and this hasn't stopped the lag.

启动segue的代码是didSelectRowAt

The code to initiate the segue is didSelectRowAt

func tableView(_ tableView: UITableView, didSelectRowAt indexPath: IndexPath) {
        if indexPath.section == 0 {
            selectedCell = realIndexFor(activeGoalAt: indexPath)
            performSegue(withIdentifier: "toGoalDetails", sender: nil)
        } else if indexPath.section == 1 {
            selectedCell = indexPath.row
            performSegue(withIdentifier: "toIdeaDetails", sender: nil)
        } else {
            selectedDecision = indexPath.row
            hero(destination: "DecisionDetails", type: .zoom)
        }
    }

然后来自目标VC的viewDidLoad或viewWillAppear中的任何代码都不会以任何方式影响这一点(我尝试将它们全部注释掉,没有任何区别.

And then none of the code in viewDidLoad or viewWillAppear from the destination VC affects this in any way (I tried commenting it all out with no difference.

知道这是什么原因吗?我可以分享任何其他需要的细节.

Any idea what's causing this? I can share whatever other details are needed.

谢谢.

推荐答案

发生在我身上是因为我在viewWillAppear( :)方法中注册了用于更改方向通知的设备. 我将注册移到了viewDidAppear( :)中,并且Xcode不再在断点处停止.

It happened to me because I registered the device for change orientation notification in the viewWillAppear(:) method. I moved the registration in the viewDidAppear(:) and Xcode it's not stopping at the breakpoint anymore.

我可以说的是,当视图已经可见时,布局更改可能会运行...

What I can say is that layout changes might be run when the view is already visible...

这篇关于UITableViewAlertForLayoutOutsideViewHierarchy错误:仅警告一次(iOS 13 GM)的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆