文档反馈官招募中，报名立赚积分兑换代金券！> HOT
文档中心>腾讯云可观测平台>终端性能监控 Pro>接入指南>iOS SDK 接入指引>数据上报验证

数据上报验证

最近更新时间：2025-09-02 11:50:02

我的收藏

本页目录：

前提条件

崩溃是100%上报，不支持采样。除崩溃外，其他监控能力都支持采样，默认是全部关闭。
需要在 终端性能监控 Pro > 应用配置 > SDK 配置 页面创建配置任务。有关配置功能的详细说明请参见 SDK 配置 。
在接入期间，建议参考 SDK 配置 设置测试号码白名单，即将所有采样率调整为1.0，方便验证数据上报。接入完成后，再根据需要调整采样率。或者创建多个配置任务，根据版本类型（对应初始化的 BuglyConfig 中的 buildConfig），配置开发任务、灰度任务、以及正式任务。开发任务打开所有的监控项，灰度阶段按需采样，正式发布根据需要降低采样。
检查待接入的产品是否已经 购买并绑定 生效中的资源包。如果产品没有绑定生效中的资源包，该产品将无法上报数据。

崩溃监控

说明：
由于崩溃捕获依赖系统的 signal 监听接口，若 App 中有接入其他类似能力的 SDK 或有相关逻辑存在监听 signal 的逻辑，可能会影响 SDK 对崩溃的捕获成功率。这种情况下，可确保 SDK 初始化在其他监听逻辑注册之后，可减少对 Crash 捕获的影响。

模拟异常

初始化完成后，可以模拟 OC 异常、C++异常、信号异常来验证 SDK 的上报情况，详细可以参考 Demo。
崩溃发生后，部分异常问题需要在第二次启动才能完成上报。上报可能存在延时，测试时建议触发异常后，重新启动 App，再刷新展示界面。
// 模拟 OC 异常
id data = [NSArray arrayWithObject:@"Hello World"];
[(NSDictionary *)data objectForKey:@""];

// 模拟信号异常
abort();

// 模拟 C++异常
throw "Something went wrong";

检查数据上报

崩溃上报后，在 崩溃 > 问题列表 中可以看到上报的问题，点击进入问题详情，即可查看上报详情。

ANR 监控

跟崩溃类似，可以通过如下的测试接口来模拟 ANR，也可以自行在 UI 线程执行异常耗时任务。
// 模拟ANR
while(YES)
{
    ;
}
ANR 上报后，在 ANR > 问题列表 可以看到上报的问题，点击进入问题详情，即可查看上报详情。

FOOM 监控

FOOM 率：FOOM（Foreground Out Of Memory）一般指 App 因为内存使用过高，被系统意外杀死的情况。由于 FOOM 判断原理的原因，因此也会包含其他原因导致的 App 被系统意外杀死的情况。可以通过如下的测试接口来模拟 FOOM：
- (void)foomButtonClicked {
    self.timer = [NSTimer scheduledTimerWithTimeInterval:0.01 target:self selector:@selector(timerFired) userInfo:nil repeats:YES];
}

- (void)timerFired {
    CGSize size = CGSizeMake(1024 , 1024);
    const size_t bitsPerComponent = 8;
    const size_t bytesPerRow = size.width * 4;
    CGContextRef ctx = CGBitmapContextCreate(calloc(sizeof(unsigned char), bytesPerRow * size.height), size.width, size.height,
                                             bitsPerComponent, bytesPerRow,
                                             CGColorSpaceCreateDeviceRGB(),
                                             kCGImageAlphaPremultipliedLast);
    CGContextSetRGBFillColor(ctx, 1.0, 1.0, 1.0, 1.0);
    CGContextFillRect(ctx, CGRectMake(0, 0, size.width, size.height));
}

检查数据上报

OOM 上报后，在 OOM > 问题列表 可以看到上报的问题，点击进入问题详情，即可查看上报详情。

错误监控

错误一般是指用户自定义的异常，如已经 Catch 的 OC/C++异常，或者 C#异常、JS 异常、lua 异常等。一般通过 BuglyCrashMonitorPlugin.h 中的 reportException:、reportError:或 reportExceptionWithCategory:name:reason:callStack:extraInfo:terminateApp:来上报（详细参考其他接口/上报自定义异常部分）。

模拟异常

上报自定义错误，可以参考以下示例代码：
- (void)userDefinedCrash {
    NSError *error = [NSError errorWithDomain:@"Error Test" code:-2 userInfo:nil];
    [BuglyCrashMonitorPlugin reportError:error];
}
上报 OC/C++异常，可以参考以下示例代码：
- (void)userDefinedCrash {
    @try {
        NSString *value = @"This is a string";
        [NSException raise:@"TurboEncabulatorException"
                    format:@"Spurving bearing failure: Barescent skor motion non-sinusoidal for %p", value];
    } @catch (NSException *exception) {
        [BuglyCrashMonitorPlugin reportException:exception];
    }
}
上报自定义异常，参考以下示例代码：
    NSArray * arr = [NSThread callStackSymbols];
    [BuglyCrashMonitorPlugin reportExceptionWithCategory:3 name:@"reportTest" reason:@"test" callStack:arr extraInfo:[NSDictionary dictionary] terminateApp:false];

检查数据上报

错误上报后，在 错误 > 问题列表 看到上报的问题，点击进入问题详情，即可查看上报详情。
说明：
reportExceptionWithCategory:name:reason:callStack:extraInfo:terminateApp:的参数中，callStack 设置的出错堆栈，extraInfo 展示在附件中。

启动监控

在开启启动监控的情况下，启动模块会自动安装监控，并且在 SDK 初始化后，进行启动数据上报。用户可以通过[BuglyLaunchMonitorPlugin endColdLaunch]接口自定义启动结束点，也支持自定义标签以及通过打点接口，监控启动过程中的耗时任务。如需了解更多关于启动接口的使用，请参见 API 说明-启动监控 部分。
[BuglyLaunchMonitorPlugin startSpan:@"parentSpan" parentSpanName:nil];
[BuglyLaunchMonitorPlugin startSpan:@"spanTest" parentSpanName:@"parentSpan"];
    
dispatch_after(dispatch_time(DISPATCH_TIME_NOW, (int64_t)(3.0 * NSEC_PER_SEC)), dispatch_get_main_queue(), ^{
    [BuglyLaunchMonitorPlugin endSpan:@"spanTest"];
    [BuglyLaunchMonitorPlugin endSpanFromLaunch:@"spanFromLaunch"];
});

dispatch_after(dispatch_time(DISPATCH_TIME_NOW, (int64_t)(4.0 * NSEC_PER_SEC)), dispatch_get_main_queue(), ^{
    [BuglyLaunchMonitorPlugin endSpan:@"parentSpan"];
});
    
[BuglyLaunchMonitorPlugin addTag:@"tagTest1"];
[BuglyLaunchMonitorPlugin addTag:@"tagTest2"];

检查数据上报

可在 启动 > 启动个例 查看上报详情。看到上报的问题，点击进入问题详情，即可查看上报详情。

卡顿监控

卡顿指标：FPS 及挂起率
在开启卡顿指标（"looper.fluency"）的情况下，SDK 会在初始化完成后，监控应用的流畅度情况。在应用运行一次的期间，会先收集数据，保存至本地，下次启动时再聚合上报。为了避免影响应用的启动，SDK 会在初始化5分钟后，再将缓存的数据聚合上报后台。
FPS：帧率，即单位时间内刷新次数 / 单位时间。因为 iPhone 13的高刷屏的出现，FPS 采用一种归一化的计算方案，即将大于60 FPS的数据归一化为 60。
挂起率：挂起率定义为单位时间内回调间隔超过200ms的时间和除以单位总时间 * 3600，即单位是 s/h。
说明：
可以通过在 Demo 中测试滑动卡顿来观察列表滑动情况下的 FPS 以及挂起率。您可在 终端性能监控 Pro > 应用列表 页面右上角选择终端性能监控 Pro Demo。

卡顿监控
开启卡顿监控（"looper.hitches"）后，在 UI 线程执行耗时逻辑，耗时超过500ms的情况下，会触发卡顿上报。卡顿监控通过监控 UI 线程的消息执行来判断当前 UI 线程是否发生卡顿。
在验证阶段，建议将卡顿监控的"event_sample_ratio"（消息采样率）以及"sample_ratio"（设备采样率）都设置为1。这样只要满足卡顿的耗时阈值，即可触发卡顿上报。

模拟异常

可以在 tableView 的回调方法中添加一个耗时操作，参考以下示例代码模拟一个卡顿上报：
- (UITableViewCell *)tableView:(UITableView *)tableView cellForRowAtIndexPath:(NSIndexPath *)indexPath {
    UITableViewCell *cell = [[UITableViewCell alloc] initWithStyle:UITableViewCellStyleDefault reuseIdentifier:@"defaultcell"];
    cell.textLabel.text = [self.dataList objectAtIndex:indexPath.row];
    cell.textLabel.font = [UIFont systemFontOfSize:80];

    BOOL hitch = arc4random() % 5;
    if (hitch) {
        [NSThread sleepForTimeInterval:0.02];
    }

    return cell;
}

检查数据上报

卡顿上报后，在 卡顿 > 问题列表 可以看到上报的问题，点击进入问题详情，即可查看上报详情。

内存监控

峰值内存

峰值内存表示在 App 的整个生命周期中，最大的 phys_footprint 的值。峰值内存越高，意味着极端情况下 App 使用内存越多。
数据上报后，在 内存 > 指标分析 可以看到上报的问题。

VC 内存泄漏

VC 内存泄漏表示监控 iOS App 开发框架中的 UIViewController 的泄漏情况。可以通过以下示例代码来验证：
    UIStoryboard *storyboard = [UIStoryboard storyboardWithName:@"RMVCLeakExample"
                                                         bundle:[NSBundle mainBundle]];
    
    UIViewController * subVC = [storyboard instantiateViewControllerWithIdentifier:@"rm.vcleak.subvc"];
    
    [self.navigationController pushViewController:subVC animated:YES];
    
    self.holdVC = subVC;
泄漏发生并且上报后，在 内存 > VC 内存泄漏 > 问题列表 可以看到上报的问题，点击进入问题详情，即可查看上报详情。

大块内存分配监控

大内存分配监控的目的是针对 App 中使用大块内存的情况进行监控，让业务感知 App 中使用内存较为严重的业务逻辑。大内存监控在 App 触发大于一定阈值的内存分配时，收集触发内存分配的堆栈、当前的业务场景、内存使用情况等数据并上报。数据上报后，在 内存 > 大块内存分配 可以看到上报的问题。

大内存分配不一定是一个明确问题，但是可以让业务得知对应的业务逻辑中有较大的内存消耗，需要关注和优化，避免内存快速消耗，导致发生 FOOM 的情况。
中国站
目录