使用electricbubble/gidevice调用coreprofilesessiontap无法获取正确结果？

云上老周

2026-8-9

问题描述

使用electricbubble/gidevice调用com.apple.instruments.server.services.coreprofilesessiontap接口时，启动后返回异常结果（异常截图：异常结果1、异常结果2），但使用Python的py-ios-device却能获取到正确数据（正常结果截图：正常数据截图）。

相关Go语言调用代码如下：

option := map[string]interface{}{
    "rp": 10,
    "tc": []map[string]interface{}{
        {
            "kdf2": []int64{630784000, 833617920, 830472456},
            "tk":   3,
            "uuid": strings.ToUpper(uuid.New().String()),
        }},
    "ur": 1000,
}
if _, err := c.i.call(instrumentsServiceCoreprofilesessiontap, "setConfig:", option); err != nil {
    fmt.Printf("err: %v\n", err)
    return nil, err
}
if _, err := c.i.call(instrumentsServiceCoreprofilesessiontap, "start"); err != nil {
    fmt.Printf("err: %v\n", err)
}

请问是否有人遇到过类似问题？如何才能获取正确的数据？

可能的解决方案

结合electricbubble/gidevice的keyedarchiver.go实现与py-ios-device的差异，问题大概率出在数据序列化/反序列化的格式不匹配，以下是具体排查和修复方向：

核对NSKeyedArchiver的类型映射：
iOS接口对NSKeyedArchiver序列化的数据类型有严格要求，比如kdf2中的数值，Go的int64是否对应OC的NSNumber类型？对比py-ios-device的实现，看它如何处理整数（是否用特定包装类），可以尝试将int64替换为float64，或者使用gidevice提供的OC类型常量包装数值。
验证setConfig:参数结构细节：
检查tc数组内的uuid格式是否完全符合接口要求，部分iOS接口对UUID的大小写、连字符位置有严格限制，即便你用了strings.ToUpper，也可以对比py-ios-device生成的UUID格式是否一致。另外确认rp、ur的数值类型是否与接口预期匹配（比如是否需要是NSNumber而非Go原生类型）。
获取接口返回的详细错误信息：
不要仅打印err，尝试解析call方法返回的第一个值，iOS端可能返回了具体的错误描述，这能直接定位是参数错误还是序列化问题。
对比py-ios-device的参数序列化逻辑：
查看py-ios-device调用该接口时的参数序列化代码，看它如何将Python字典转换为NSKeyedArchiver数据，再对应调整gidevice的参数构造方式。比如嵌套数组、字典结构在Python中的处理方式，是否需要在Go中使用特定的切片或映射类型，或是添加额外元数据。
检查gidevice的call方法实现：
确认gidevice的call方法是否正确处理了复杂嵌套结构的参数，比如tc是数组嵌套字典的结构，序列化时是否正确转换为OC的NSArray和NSDictionary。

内容的提问来源于stack exchange，提问作者haizhohuang