【问题标题】:How to determine what's running on main thread + slowing down UI?如何确定主线程上正在运行什么+减慢 UI?
【发布时间】:2016-08-09 20:59:02
【问题描述】:

我在我的应用程序中添加了一个新的数据加载功能。它旨在将大型数据库的内容从移动设备传输和处理到后端。在我在这个管道中运行的任何函数中,函数的全部内容都在一个

dispatch_async

这将分派到非主线程。我还通过日志验证了这些是否有效。管道中的每个函数都脱离了主线程。然而,我正在经历 UI 冻结。

问题:

  1. 找出主线程上的内容以及它正在做什么/等待什么的最佳方法是什么?
  2. 是否有可能让非主线程做这么多实际上影响主线程的事情?

【问题讨论】:

  • 仅供参考 - dispatch_async 不保证后台队列。它使用你传入的任何队列。使用一些相关代码更新您的问题。
  • @rmaddy - 你是对的,当然。我们需要更多的继续。但在他的辩护中,他确实说他正在分派到一个“非主线程”[原文如此]。
  • @Rob OP 并没有说“他”正在分派到“非主线程”。 OP 声明 dispatch_async 调度到“非主线程”。因此,我原来的评论。
  • @rmaddy - 没关系。但是,如果他将一些缓慢而耗时的东西发送到主队列并想知道为什么应用程序没有响应,我会感到惊讶。但你的观点被采纳了。
  • 底线是检查你是否不小心在主线程中调度了一些繁重的处理器密集型操作。

标签: ios objective-c


【解决方案1】:

您应该使用 Instruments 来分析您的应用。 Time Profiler(确保使用“记录等待线程”选项)可能很有用,系统跟踪也是如此。对于这两者,您可能希望使用“线程策略”视图,专注于主线程。有一堆 WWDC 视频描述了各种方法,包括过时但仍然相关的 2012 年视频 Building Concurrent User Interfaces on iOS。还要寻找引用“分析”和“仪器”的更新的 WWDC 视频。

关于对性能产生不利影响的非主线程,它通常可以忽略不计,您可能还有其他事情发生。只有当您使用不支持多线程的非常旧的设备时才会出现严重问题。

顺便问一下,你 100% 确定主线程真的没有响应吗?还是您可能只是没有看到及时反映 UI 更新?这可能是由于意外地从后台线程执行 UI 更新,而不是将它们分派回主队列。

如果您需要更具体的建议,我们需要一个关于性能问题的reproducible example。但抽象地说,

  • 确保您在主队列上没有任何耗时的操作;
  • 确保将所有 UI 更新分派回主队列...这包括任何可能触发 UIKit 控件更新的
  • 确保您的代码不会“等待”来自主线程的任何内容(例如等待信号量、等待操作队列上的操作、等待调度组等);和
  • 请记住,并非所有异步 API 都会在后台队列中调用其完成处理程序(事实上,为了便于使用,许多将其分派回主队列),所以如果您在完成中做任何耗时的事情处理程序,确认它实际上是否在后台线程上运行。

【讨论】:

    【解决方案2】:

    我会为此使用 Instruments,您可以使用很多工具,例如 Time Profiler、Allocations、System Usage 等。要打开这些工具,请在 xcode 或 Xcode>Open Developer Tools>Instruments 中使用 command+i在 xcode 菜单中。

    【讨论】:

    • 您能否分享一下您如何分析此 UI 操作以及后台线程上正在更新的任何项目。
    • 您能否为“this” UI 操作提供更多上下文?
    猜你喜欢
    • 2015-02-22
    • 2020-06-02
    • 1970-01-01
    • 2020-10-18
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多