DTSendSignalFlag的替代方案可以识别仪器中的关键事件？ [英] Alternative to DTSendSignalFlag to identify key events in Instruments?

问题描述

曾经有一个很好的工具， DTSendSignalFlag ，是 DTPerformanceSession 框架的一部分，您可以通过它编程将标志插入仪器（请参阅

在这张快照中，我分析了7个下载操作（橙色）和7个解析操作（绿色），分别限制为两个。当他们完成后，我发布了一个完成的路标（红色针脚）。但是这个演示应用程序的细节并不重要，而只是说明了如何在乐器的兴趣点中呈现单个路标和开始/结束路标。

主要问题是我现在在代码中的事件和我在仪器中看到的事件之间有明确的对应关系。我可以控制 - 点击路标范围列表中的条目，并告诉乐器设置时间过滤器，如果我愿意，这样当我回到我的其他乐器（分配或时间）时探查器或其他），检查范围被过滤到我的应用程序中的相关兴趣点。

---

注意，以上是斯威夫特。在Objective-C中， kdebug_signpost API类似，但您必须包括：

  #import< sys / kdebug_signpost.h> 
  

显然，如何定义代码的枚举也会发生变化。

注意，这个 kdebug_signpost API是在iOS 10 / macOS 10.12中引入的。标题告诉我们早期的OS版本可以使用 syscall ：

在以前的版本中操作系统，应用程序可以使用：

 系统调用（SYS_kdebug_trace，APPSDBG_CODE（DBG_MACH_CHUD，<您的事件代码>）| DBG_FUNC_< ; type>，arg1，arg2，arg3，arg4）; 
  

记录仪器将显示的事件。 syscall（2）现已弃用，此界面取代了上述调用。

注意：如果您发现自己必须在早期操作系统版本上使用 syscall ，则必须导入< sys / kdebug.h> ：

  #import< sys / kdebug.h> 
  

此外，我无法找到 SYS_kdebug_trace的声明在任何标题中，但偶然发现在线参考说这个值是 180 ，我凭经验证实：

  #ifndef SYS_kdebug_trace 
 #define SYS_kdebug_trace 180 
 #endif 
  

There used to be a nice tool, DTSendSignalFlag, part of the DTPerformanceSession framework, by which you could programmatically insert flags into Instruments (see Xcode Instruments trace comparison). This feature stopped working in iOS 7.

Has anyone succeeded in getting DTSendSignalFlag to work in iOS 7? Signal flags are (were?) a useful way to programmatically post flags in Instruments via code (really helpful when diagnosing complicated apps in Instruments), but I'm not seeing my programmatically created flags in Instruments when I run on the iOS 7 simulator (but it works when I have Xcode 5 build for the iOS 6 simulator).

解决方案

Rather than using flags, we can now use programmatically inserted signposts which are captured in Instrument's "Points of Interest". In iOS 10 and macOS 10.12, we can use kdebug_signpost. This is illustrated in WWDC 2016 video System Trace in Depth.

For those processes that take a discrete amount of time, we can use kdebug_signpost_start and kdebug_signpost_end. For example:

kdebug_signpost_start(SignPostCode.download.rawValue, UInt(index), 0, 0, SignPostColor.orange.rawValue)
// perform download
kdebug_signpost_end(SignPostCode.download.rawValue, UInt(index), 0, 0, SignPostColor.orange.rawValue)

To mark a single moment in time, we can just use kdebug_signpost:

kdebug_signpost(SignPostCode.done.rawValue, 0, 0, 0, UInt(SignPostColor.red.rawValue))

The first parameter is just some unique numeric code that corresponds to a "signpost code name" that we'll use in Instruments. You can use whatever values you want (between 0 and 16383), but I use something that designates the type of task:

enum SignPostCode: UInt32 {   // some custom constants that I'll reference in Instruments
    case download = 0
    case parse = 1
    case done = 2
}

The rest of the parameters can be whatever UInt values you want, but in my example, I'll use the second parameter as a unique identifier to match up repeated start and end calls and I'll use the last parameter to color code my regions in Instruments:

enum SignPostColor: UInt {    // standard color scheme for signposts in Instruments
    case blue = 0
    case green = 1
    case purple = 2
    case orange = 3
    case red = 4
}

Having done this, you can then profile the app in Instruments, click on the "+" button in the right side of the Instruments toolbar, and add "Points of Interest". By configuring the "Signpost Code Names" to match the numeric values I passed as the first parameter to my signposts, Instruments will actually translate those codes for me. Once I profile the app and I now have my points of interest clearly highlighted for me:

In this snapshot, I profiled seven download operations (in orange) and seven parse operations (in green), constrained to two at a time, respectively. And when they were done, I posted a single "done" signpost (pin red). But the details of this demo app are not critical, but rather this just illustrates how single signposts and start/end signposts are rendered in Instruments' "Points of Interest".

The main issue is that I now have clear correspondence between events in my code and what I see in Instruments. And I can control-click on an entry in the list of signpost ranges and tell Instruments to "Set time filter", if I want, so that when I go back to my other instruments (allocations or time profiler or whatever), the inspection range is filtered down to the relevant points of interest in my app.

---

Note, the above is Swift. In Objective-C, the kdebug_signpost API is similar, but you have to include:

#import <sys/kdebug_signpost.h>

Obviously, how you define your enumerations for your codes will change, too.

Note, this kdebug_signpost API was introduced in iOS 10/macOS 10.12. The headers tell us that earlier OS versions could use syscall:

In previous versions of the operating system, applications could use:

syscall(SYS_kdebug_trace, APPSDBG_CODE(DBG_MACH_CHUD, <your event code>) | DBG_FUNC_<type>, arg1, arg2, arg3, arg4);

to record events that would be displayed by Instruments. syscall(2) is now deprecated and this interface replaces the above call.

Note: If you find yourself having to use syscall on an earlier OS version, you'll have to import <sys/kdebug.h>:

#import <sys/kdebug.h>

Also, I wasn't able to find a declaration of SYS_kdebug_trace in any of the headers, but stumbled across a reference online that said that this value is 180, which I empirically verified:

#ifndef SYS_kdebug_trace
#define SYS_kdebug_trace 180
#endif

这篇关于DTSendSignalFlag的替代方案可以识别仪器中的关键事件？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！