Skip to main content

Bugly Android SDK 日志分析指引

在接入过程中，可能会因为没有绑定资源包，或者资源包过期，或者配置没有开启，或者超过设备单日最大上报量，或者网络策略的原因，导致在管理台查不到期望数据的情况。为了帮助大家快速定位问题，提升接入的效果，我们特别提供了《Bugly Android SDK 日志分析指引》。主要是通过分析Bugly Android SDK的日志，可以帮助我们快速了解，数据没有上报的原因。

Bugly 的监控项分两类，一类是崩溃模块，另一类是启动，卡顿，内存，网络，电量，流量，页面性能等监控插件。这两类监控项的日志有所区别，下面将分别介绍。

1. 分析前检查​

1.1 检查日志等级​

在接入验证阶段，推荐在初始化时将 Bugly Android SDK 的日志设置为 LEVEL_DEBUG 或者 LEVEL_VERBOS 级别，请参考以下代码。

...
buglyBuilder.logLevel = BuglyLogLevel.LEVEL_VERBOS;
...
Bugly.init(application, buglyBuilder);
重要提醒

接入验证结束后，请务必将日志级别设置为 LEVEL_WARN 或者 LEVEL_INFO 级别，否则日志量会比较大。Bugly Android SDK 默认的日志级别为 LEVEL_WARN。

...
buglyBuilder.logLevel = BuglyLogLevel.LEVEL_WARN;
...
Bugly.init(application, buglyBuilder);

1.2 检查上报域名​

Bugly 支持多种版本，如专业版本，海外版等等。不同版本共用SDK，但是上报域名不同。

  • 专业版的上报域名设置
buglyBuilder.setServerHostType(BuglyBuilder.ServerHostTypeBuglyPro);
  • 海外版的上报域名设置
buglyBuilder.setServerHostType(BuglyBuilder.ServerHostTypeBuglyOversea);
  • 腾讯云版的上报域名设置
buglyBuilder.setServerHostType(BuglyBuilder.ServerHostTypeBuglyCloud);

1.3 检查监控配置​

像启动，卡顿，内存，网络，电量，流量，页面性能等监控插件，支持在管理台配置是否允许开启，推荐参考 SDK配置使用指引 ，在接入阶段推荐将要验证的监控插件都打开。

  • "sample_ratio"：设备采样率，在接入阶段推荐设置为1.0，即全采样。
  • "event_sample_ratio"：事件采样率，对部分监控插件有效，也建议设置为1.0，即全采样。

2. 崩溃模块的检查​

崩溃模块，包含崩溃，OOM，ANR，错误等监控项，日志Tag为 "eup"。

2.1 检查初始化日志​

在日志TAG为 "eup" 的日志中，如果看到以下日志，说明初始化成功。

2025-12-12 18:20:48.258  1003-1003  eup                     com.tencent.demo.buglyprodemo        I  Success to load so: Bugly_Native

2.2 检查联网上报日志​

在日志TAG为 "eup" 的日志中，如果看到以下日志，说明联网上报成功。

2025-12-12 18:20:48.464  1003-1106  eup                     com.tencent.demo.buglyprodemo        I  [Upload] Success: userinfo

2.3 检查异常捕获日志​

在日志TAG为 "eup" 的日志中，如果看到以下日志，说明捕获到一个异常。其中 "CRASH TYPE: JAVA_CRASH" 表示这是一个Java异常，"CRASH TYPE: NATIVE_CRASH" 表示这是一个Native异常, "CRASH TYPE: ANR" 表示这是一个ANR，"CRASH TYPE: Unity" 表示这是一个Unity错误。

2025-12-12 18:25:14.096  1003-2828  eup                     com.tencent.demo.buglyprodemo        E  #++++++++++Record By Bugly++++++++++#
2025-12-12 18:25:14.096  1003-2828  eup                     com.tencent.demo.buglyprodemo        E  # PKG NAME: com.tencent.demo.buglyprodemo
2025-12-12 18:25:14.096  1003-2828  eup                     com.tencent.demo.buglyprodemo        E  # APP VER: 4.4.2.6
2025-12-12 18:25:14.097  1003-2828  eup                     com.tencent.demo.buglyprodemo        E  # SDK VER: 4.4.7.9-SNAPSHOT
2025-12-12 18:25:14.097  1003-2828  eup                     com.tencent.demo.buglyprodemo        E  # LAUNCH TIME: 2025-12-12 18:20:48
2025-12-12 18:25:14.097  1003-2828  eup                     com.tencent.demo.buglyprodemo        E  # CRASH TYPE: JAVA_CRASH
2025-12-12 18:25:14.097  1003-2828  eup                     com.tencent.demo.buglyprodemo        E  # CRASH TIME: 2025-12-12 18:25:14
2025-12-12 18:25:14.097  1003-2828  eup                     com.tencent.demo.buglyprodemo        E  # CRASH PROCESS: com.tencent.demo.buglyprodemo
2025-12-12 18:25:14.097  1003-2828  eup                     com.tencent.demo.buglyprodemo        D  isAppForeground:true
2025-12-12 18:25:14.098  1003-2828  eup                     com.tencent.demo.buglyprodemo        E  # CRASH FOREGROUND: true
2025-12-12 18:25:14.098  1003-2828  eup                     com.tencent.demo.buglyprodemo        E  # CRASH THREAD: Thread-12
2025-12-12 18:25:14.098  1003-2828  eup                     com.tencent.demo.buglyprodemo        E  # REPORT ID: 5a0079b7-58d3-4cc2-a583-811904068503
2025-12-12 18:25:14.098  1003-2828  eup                     com.tencent.demo.buglyprodemo        E  # CRASH DEVICE: V1821A UNROOT
2025-12-12 18:25:14.098  1003-2828  eup                     com.tencent.demo.buglyprodemo        E  # RUNTIME AVAIL RAM:6392360960 ROM:51966001152 SD:51756285952
2025-12-12 18:25:14.098  1003-2828  eup                     com.tencent.demo.buglyprodemo        E  # RUNTIME TOTAL RAM:10002735104 ROM:119698042880 SD:119488327680
2025-12-12 18:25:14.099  1003-2828  eup                     com.tencent.demo.buglyprodemo        E  # CRASH STACK: 
2025-12-12 18:25:14.099  1003-2828  eup                     com.tencent.demo.buglyprodemo        E  java.lang.IndexOutOfBoundsException: Index: 3, Size: 3
                                                                                                        at java.util.ArrayList.get(ArrayList.java:437)
                                                                                                        at com.tencent.demo.buglyprodemo.testcase.TestMain.testJavaCrash(TestMain.java:458)
                                                                                                        at com.tencent.demo.buglyprodemo.testcase.TestMain.access$2300(TestMain.java:34)
                                                                                                        at com.tencent.demo.buglyprodemo.testcase.TestMain$24$1.run(TestMain.java:383)
                                                                                                        at java.lang.Thread.run(Thread.java:919)

2.4 检查异常保存日志​

在日志TAG为 "eup" 的日志中检查，是否保存了异常日志。如果保存成功，会打印以下日志：

2025-12-12 18:25:14.130  1003-2828  eup                     com.tencent.demo.buglyprodemo        I  [crash] save crash success

2.5 检查异常上报日志​

  • 上报成功日志

在日志TAG为 "eup" 的日志中检查，是否上报了异常日志。如果上报成功，会打印以下日志：

2025-12-12 18:25:14.437  1003-2847  eup                     com.tencent.demo.buglyprodemo        I  java.lang.IndexOutOfBoundsException, crash upload success!

"java.lang.IndexOutOfBoundsException" 是异常名称。如果是ANR，异常名称为"ANR_EXCEPTION"。自定义错误的异常名称由开发者自己定义，可以是类似 "Flutter Exception" 这样。

  • 上报失败日志

如果没有看到上报成功的日志，再检查是不是因为服务限制上报导致上报失败。检查在日志TAG为 "RMonitor_report_entrance" 的日志中，是否包含下述类似的日志，包含"crash.basic_info" 或者 "crash.state_file" 或者 "crash.custom_log"，而且 "block: true"，表示服务端限制上报了。

2025-12-13 08:47:16.330 29193-29250 RMonitor_r...t_entrance com.tencent.demo.buglyprodemo        V  check block report of [crash.basic_info], block: true
...
2025-12-13 08:47:16.909 29193-29250 RMonitor_r...t_entrance com.tencent.demo.buglyprodemo        V  check block report of [crash.state_file], block: true
...
2025-12-13 08:47:16.948 29193-29250 RMonitor_r...t_entrance com.tencent.demo.buglyprodemo        V  check block report of [crash.custom_log], block: true

如果发现上报被拦截的情况，请检查一下是否有绑定资源包，或者绑定的资源已经消耗完，或者绑定的资源包已经过期，或者当前套餐对于上报有限制。

3. 监控插件的通用检查​

除崩溃/ANR/错误外，其他监控项以监控插件的形式提供服务，每个监控插件有共同的流程，但是各个插件的采集数据的方式不同，相关的日志也有所差异。我们会先介绍这些监控插件共同的日志部分。

Bugly Android SDK 当前支持的监控插件如下：

  • launch_metric: 启动监控
  • looper_metric: 卡顿指标
  • looper_stack: UI线程的卡顿监控
  • work_thread_lag: 工作线程的卡顿监控
  • net_quality: 网络监控
  • traffic_detail: 流量异常监控
  • traffic: 流量指标
  • custom_event: 自定义事件
  • battery_metric: 电量指标
  • battery_ele_metric: 耗电因素指标
  • battery_element: 耗电因素监控
  • page_launch: 页面性能监控
  • memory_quantile: 内存指标
  • sub_memory_quantile: 子进程内存指标
  • fd_leak: FD触顶监控
  • native_memory: 原生内存详情监控 或者 Native内存详情监控
  • activity_leak: Activity泄漏监控
  • asan: ASAN监控
  • java_memory_ceiling_hprof: Java内存详情监控
  • big_bitmap: 大图监控

这些监控插件的上报分析都包含以下通用流程：

3.1 检查监控插件是否配置开启​

需要在日志TAG为 "RMonitor_config" 且包含 "dump for loadConfig" 的日志中检查，期望的监控项是否配置开启。一般是 "{plugin_name}:false" 表示某监控项禁止开启，"{plugin_name}:true" 表示某监控项允许开启。例如，"looper_metric:true" 表示卡顿指标配置打开，而 "fd_leak:false" 表示FD触顶监控配置关闭。

2025-12-12 18:56:22.312  8837-8903  RMonitor_config         com.tencent.demo.buglyprodemo        I  dump for loadConfig, {sse:false, work_thread_lag:false, fd_leak:false, sub_memory_quantile:false, custom_event:true, looper_metric:true, battery:false, native_memory:true, traffic_detail:false, traffic:false, battery_metric:false, memory_quantile:true, io:false, list_metric:false, page_launch:true, activity_leak:true, battery_element:false, launch_metric:true, battery_ele_metric:false, looper_stack:true, asan:false, java_memory_ceiling_hprof:false, http:false, net_quality:true, device:false, big_bitmap:true, db:false}

3.2 检查监控插件是否注册成功​

除启动监控外，大部分监控插件如果成功启动，会在日志TAG为 "RMonitor_plugins"的日志中，看到包含 "register module {plugin_name} success." 以及 "start {plugin_name}" 的类似日志。

下面以 "big_bitmap" 为例，检查日志TAG为 "RMonitor_plugins" 且包含 "register module big_bitmap success." 和 "start big_bitmap" 的日志。

2025-12-12 18:56:21.982  8837-8903  RMonitor_plugins        com.tencent.demo.buglyprodemo        I  register module big_bitmap success.
2025-12-12 18:56:21.983  8837-8903  RMonitor_plugins        com.tencent.demo.buglyprodemo        I  start big_bitmap

但是启动监控比较特殊，包含以下日志是正常的。原因是启动监控插件跟其他监控插件不同，一般是由ContentProvider直接拉起的。

2025-12-12 18:56:21.968  8837-8903  RMonitor_plugins        com.tencent.demo.buglyprodemo        I  launch_metric is null.
2025-12-12 18:56:21.968  8837-8903  RMonitor_plugins        com.tencent.demo.buglyprodemo        I  start plugin fail for launch_metric is null.

对于启动监控，如果看到日志TAG为 "RMonitor_launch_cold"的日志，包含"onApplicationCreateStart"的日志，表示启动监控插件已经开启了。

2025-12-12 18:56:21.799  8837-8837  RMonitor_launch_cold    com.tencent.demo.buglyprodemo        W  onApplicationCreateStart

3.3 检查监控插件是否采集到数据​

每个监控插件采集到数据的日志有差异，但是一般都有以下共性日志，就是采集到数据后，会生成一条上报记录。有这条日志并不代码上报成功，只是代表采集到数据，尝试上报，具体是否可以上报还依赖后续检查流程。

注意：这是一个VERBOS级别的日志，需要在初始化时，设置日志级别为BuglyLogLevel.LEVEL_VERBOS。如果没有看到这条日志，先检查日志级别。

2025-12-12 20:02:46.109  8837-8903  RMonitor_report         com.tencent.demo.buglyprodemo        V  reportNow, plugin: looper_metric, strategy:ReportStrategy(needCache=true, priority=2, connectTimeout=30000, readTimeout=30000, retryTimes=3, retryStrategy=RETRY_BACKOFF, uploadStrategy=UPLOAD_ANY, alreadyRetryTimes=0), dbId: 0

3.4 检查监控插件是否上报成功​

检查日志TAG为"RMonitor_report"的日志，是否按顺序同时看到以下三行日志，没有连续要求，中间可能插入其他日志。如下示例，卡顿指标成功上报了一条数据。

2025-12-12 20:02:46.186  8837-8939  RMonitor_report         com.tencent.demo.buglyprodemo        V  reportInternal, name: looper_metric, dbID: 21, cid: 1bf7b12d9eaf2ae6be69ec1f42a4d944

2025-12-12 20:02:46.187  8837-8939  RMonitor_report_entrance com.tencent.demo.buglyprodemo       V  check block report of [looper.looper_metric], block: false

2025-12-12 20:02:46.310  8837-8939  RMonitor_report         com.tencent.demo.buglyprodemo        V  reportInternal-onSuccess, pluginName: looper_metric, dbId: 21

注意：这是V级别的日志，请在初始化时，设置日志级别为BuglyLogLevel.LEVEL_VERBOS。如果没有看到这条日志，先检查日志级别。

3.5 排查监控插件上报失败的原因​

如果没有看到监控插件上报成功的日志，在管理台也没有看到期望的上报数据，请按以下顺序排查上报失败的原因。

3.5.1 检查监控插件的上报策略​

检查日志TAG 为 "RMonitor_report"的日志，是否包含 "reportNow, plugin: {plugin_name}, strategy:ReportStrategy" 的日志。如果找到这行日志会看到，类似"uploadStrategy=UPLOAD_WIFI" 或者 "uploadStrategy=UPLOAD_NEXT_LAUNCH" 或者 "uploadStrategy=UPLOAD_ANY" 的日志。

  • "uploadStrategy=UPLOAD_ANY"：表示要求数据上报模块立即上报。
  • "uploadStrategy=UPLOAD_WIFI"：表示只有当设备当前处于WIFI网络下，才会尝试上报，否则由上报模板先持久化存储到本地。在下次进程启动后，再尝试上报。
  • "uploadStrategy=UPLOAD_NEXT_LAUNCH"：表示要求数据上报模块先持久化存储到本地，下次进程启动后，再尝试上报。
2025-12-12 19:06:43.525  8837-8939  RMonitor_report         com.tencent.demo.buglyprodemo        V  reportNow, plugin: launch_metric, strategy:ReportStrategy(needCache=true, priority=2, connectTimeout=30000, readTimeout=30000, retryTimes=3, retryStrategy=RETRY_BACKOFF, uploadStrategy=UPLOAD_WIFI, alreadyRetryTimes=0), dbId: 0

如果看到上报策略不是"UPLOAD_ANY"，或者是"UPLOAD_WIFI"但是当前不是WIFI网络，需要手动kill进程，然后重新启动进程，再重新检查数据上报流程。

3.5.2 检查监控插件是否被服务器限流​

block: true，代表被服务器限流了，不允许上报。block: false，代表没有被服务器限流，允许上报。

2025-12-12 20:02:46.187  8837-8939  RMonitor_report_entrance com.tencent.demo.buglyprodemo        V  check block report of [looper.looper_metric], block: true

被服务器限流的原因有多种，请按以下顺序在管理台排查：

  • 检查是否有绑定资源包，入口在「设置/产品信息/用量明细」。
  • 检查资源包是否过期，或者资源包已经耗尽，产品已经欠费。这种情况一般会在顶部看到一条欠费的通知条。
  • 检查当前的套餐类型，有些套餐有上报额度限制。

3.5.3 检查监控插件是否被远程关闭​

检查日志TAG为 "RMonitor_report" 的日志中，是否有 "block report for not hit sampling, plugin: {plugin_name}" 的日志，如果存在，代表该监控插件被远程关闭了。这种情况下，即使后面有"reportInternal-onSuccess, pluginName: {plugin_name}"的日志，也是没有上报的。

2025-12-12 20:02:46.109  8837-8903  RMonitor_report         com.tencent.demo.buglyprodemo        D  block report for not hit sampling, plugin: looper_metric .
...
2025-12-12 20:02:46.310  8837-8939  RMonitor_report         com.tencent.demo.buglyprodemo        V  reportInternal-onSuccess, pluginName: looper_metric, dbId: 21

3.5.4 检查监控插件是否超出上报限额​

检查日志TAG为 "RMonitor_report" 的日志中，是否有 "block report for exceed limit, plugin: {plugin_name}" 的日志，如果存在，代表该监控插件上报数据超出限额。这种情况下，即使后面有"reportInternal-onSuccess, pluginName: {plugin_name}"的日志，也是没有上报的。

2025-12-12 20:02:46.109  8837-8903  RMonitor_report         com.tencent.demo.buglyprodemo        D  block report for exceed limit, plugin: looper_metric .
...
2025-12-12 20:02:46.310  8837-8939  RMonitor_report         com.tencent.demo.buglyprodemo        V  reportInternal-onSuccess, pluginName: looper_metric, dbId: 21

3.5.5 检查监控插件是否上报失败​

检查日志TAG为 "RMonitor_report" 的日志中，是否包含 "reportInternal-onFailure, pluginName: {plugin_name}" 的日志，如果存在，代表该监控插件上报失败。

Bugly Android SDK有重试机制，即使包含上报失败的日志，后面也有可能再次包含上报成功的日志。

2025-12-12 20:02:46.310  8837-8939  RMonitor_report         com.tencent.demo.buglyprodemo        V  reportInternal-onFailure, pluginName: looper_metric, dbId: 21, errorCode: 400, errorMsg: some error msg

4. 特定监控插件的检查​

4.1 启动监控​

启动监控插件的插件名为 "launch_metric"，因启动比较特殊，往往在Android Bugly SDK初始化前就会启动，所以日志是直接通过 adb logcat 打印。模块的大部分日志不受前面日级级别的控制，但是数据上报流程跟其他监控插件一样。

启动监控插件的配置检查流程和数据上报流程跟其他监控插件一样，所以不再赘述。这里重点介绍怎么检查启动监控插件是否正常打开，以及是否成功采集到数据。

4.1.1 检查功能是否正常打开​

检查日志TAG为 "RMonitor_launch_cold" 的日志，是否有 "onApplicationCreateStart" 的日志，如果存在，代表启动监控功能已经启动。

2025-12-12 18:56:21.799  8837-8837  RMonitor_launch_cold    com.tencent.demo.buglyprodemo        W  onApplicationCreateStart

4.1.2 检查数据是否成功采集​

检查日志TAG为"RMonitor_launch_Monitor"的日志，找包含"report, result: "的日志，表示启动监控采集到数据，准备上报。其中 "launchType: cold_launch”表示冷启动，"launchType: warm_launch”表示温启动。

  • 如下所示，采集到一条冷启动，而且启动耗时为2118ms。
2025-12-12 18:56:24.152  8837-8837  RMonitor_launch_Monitor com.tencent.demo.buglyprodemo        I  report, result: {launchType: cold_launch, launchCostInMs: 2118, tags: [has_cost_job_one,has_cost_job_two,tag_normal_launch], spans: [{name: applicationCreate, cost: 202, parentSpan: },{name: application_create_start, cost: 285, parentSpan: },{name: application_create_end, cost: 487, parentSpan: },{name: firstScreenRender, cost: 459, parentSpan: },{name: first_screen_complete, cost: 1013, parentSpan: },{name: landing_page_complete, cost: 1013, parentSpan: },{name: costJobOne, cost: 802, parentSpan: },{name: costJobTwo, cost: 200, parentSpan: costJobOne},{name: app_full_launch, cost: 2118, parentSpan: }]}
  • 如下所示，采集到一条温启动，而且启动耗时为233ms。
2025-12-12 19:06:43.524  8837-8837  RMonitor_launch_Monitor com.tencent.demo.buglyprodemo        I  report, result: {launchType: warm_launch, launchCostInMs: 233, tags: [], spans: []}

4.2 卡顿指标​

卡顿指标监控插件的插件名为 "looper_metric"，该监控插件的配置检查流程和数据上报流程跟其他监控插件一样，所以不再赘述。这里重点介绍怎么检查卡顿指标监控插件是否正常打开，以及是否成功采集到数据。

4.2.1 检查功能是否正常打开​

分析日志TAG为"RMonitor_looper_metric"的日志，是否有 "looper_metric start" 的日志，如果存在，代表卡顿指标监控功能已经打开。

2025-12-12 18:56:21.961  8837-8903  RMonitor_looper_metric  com.tencent.demo.buglyprodemo        D  looper_metric start
2025-12-12 18:56:21.962  8837-8903  RMonitor_looper_metric  com.tencent.demo.buglyprodemo        D  start, reportBackground: true

4.2.2 检查数据是否成功采集​

分析日志TAG为"RMonitor_looper_metric"的日志，找到 "changeScene, {lastScene} --> {destScene}" 和 "dump, DropFrameResultMeta" 的日志。

  • "changeScene, {lastScene} --> {destScene}" 表示检测到场景切换或者页面切换。如本示例中，从场景 "MainProcessActivity" 切换到场景 "MainSecondActivity"。
2025-12-12 19:02:50.516  8837-8837  RMonitor_looper_metric  com.tencent.demo.buglyprodemo        V  changeScene, MainProcessActivity --> MainSecondActivity
  • 检查到场景切换后，在切到新场景前，会将上一个场景或者页面的卡顿指标数据保存为一份样本。如本示例中，保存上一个场景"MainProcessActivity"的卡顿指标数据。
2025-12-12 19:02:50.517  8837-8903  RMonitor_looper_metric  com.tencent.demo.buglyprodemo        V  dump, DropFrameResultMeta(scene=MainProcessActivity, totalDuration=372784, refreshDuration=[16, 272, 66, 0, 66, 0, 0, 133, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0], refreshCount=[1, 17, 2, 0, 1, 0, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0], hitchesDuration=198, suspendDuration=816, timeStamp=1765536982345, userCustom=null), totalRefreshDuration: 553, fps1: 39.783, fps2: 38.517178
  • 采集到样本并不会立即上报，会先缓存到本地，等应用切后台，或者收集一批样本后，才会触发一次上报。只有在日志TAG为"RMonitor_report"的日志中，看到"reportNow, plugin: looper_metric" 的日志，代表生成了一条上报记录。
2025-12-12 21:06:49.541  8837-8903  RMonitor_report         com.tencent.demo.buglyprodemo        V  reportNow, plugin: looper_metric, strategy:ReportStrategy(needCache=true, priority=2, connectTimeout=30000, readTimeout=30000, retryTimes=3, retryStrategy=RETRY_BACKOFF, uploadStrategy=UPLOAD_ANY, alreadyRetryTimes=0), dbId: 0

4.3 卡顿问题​

卡顿问题监控插件的插件名为 "looper_stack" ,该监控插件的配置检查流程和数据上报流程跟其他监控插件一样，所以不再赘述。这里重点介绍怎么检查卡顿问题监控插件是否正常打开，以及是否成功采集到数据。

4.3.1 检查功能是否正常打开​

分析日志TAG为"RMonitor_lag"的日志，如果可以看到 "start Lag Monitors."的日志，代表卡顿问题监控功能已经打开。

2025-12-12 18:56:21.964  8837-8903  RMonitor_lag            com.tencent.demo.buglyprodemo        D  createLagParam lagParam: [1.0,200,52,3000,true,msg]
2025-12-12 18:56:21.965  8837-8903  RMonitor_lag            com.tencent.demo.buglyprodemo        D  createLooperStackProvider, stackProvider: com.tencent.rmonitor.looper.provider.StackQueueProvider@d707751
2025-12-12 18:56:21.966  8837-8903  RMonitor_lag            com.tencent.demo.buglyprodemo        I  start Looper Observer of main
2025-12-12 18:56:21.968  8837-8903  RMonitor_lag            com.tencent.demo.buglyprodemo        I  start Lag Monitors.

4.3.2 检查数据是否成功采集​

分析日志TAG为"RMonitor_report"的日志，检查是否有"reportNow, plugin: looper_stack, strategy:ReportStrategy"的日志。

2025-12-13 12:37:00.683  6955-7040  RMonitor_report         com.tencent.demo.buglyprodemo        V  reportNow, plugin: looper_stack, strategy:ReportStrategy(needCache=true, priority=2, connectTimeout=30000, readTimeout=30000, retryTimes=3, retryStrategy=RETRY_BACKOFF, uploadStrategy=UPLOAD_WIFI, alreadyRetryTimes=0), dbId: 0

4.4 网络监控​

卡顿问题监控的插件名为 "net_quality" ，该监控插件的配置检查流程和数据上报流程跟其他监控插件一样，所以不再赘述。这里重点介绍怎么检查网络监控插件是否正常打开，以及是否成功采集到数据。

4.4.1 检查功能是否正常打开​

分析日志TAG为"RMonitor_net_quality"的日志，检查是否有"startCollector"的日志，如果包含说明功能已经打开。

2025-12-13 12:40:20.398 23850-23904 RMonitor_net_quality    com.tencent.demo.buglyprodemo        D  startCollector
2025-12-13 12:40:20.398 23850-23904 RMonitor_net_quality    com.tencent.demo.buglyprodemo        I  start

4.4.2 检查数据是否成功采集​

分析TAG为"RMonitor_net_quality"的日志，检查是否有 "onCallFinished" 的日志，如果包含说明数据已经成功采集数据。

2025-12-13 12:40:20.527 23850-23913 RMonitor_net_quality    com.tencent.demo.buglyprodemo        V  onCallFinished, data: {url: https://pro.bugly.qq.com/v1/75f820edad/upload-json, host: pro.bugly.qq.com, statusCode: 200, cost: 119}
2025-12-13 12:40:20.528 23850-23904 RMonitor_net_quality    com.tencent.demo.buglyprodemo        V  onCallFinished, data: {url: https://pro.bugly.qq.com/appconfig/v7/config/75f820edad/, host: pro.bugly.qq.com, statusCode: 200, cost: 112}

4.4.3 检查是否满足上报策略​

网络监控目前是对每一个HTTP/HTTPS请求进行监控，其数据样本就是一个个的HTTP/HTTPS请求。网络监控采样到样本后，并不是立即上报，而是先本地聚合，聚合到一批数据后才会上报。目前的策略是，应用退后台后，检查当前采集的数样本数量是否满足最低上报样本量，如果满足则上报，否则等待下次应用切后台时再检查。

分析日志TAG为"RMonitor_net_quality"的日志，检查是否有包含"try report or cache data for background."的日志，而且后续会有一条包含"reportNow, plugin: net_quality, strategy:ReportStrategy"的日志。如果包含这些日志，说明采集了足够的样本，触发了一条网络上报日志。

2025-12-13 12:47:05.053 23850-23850 RMonitor_net_quality    com.tencent.demo.buglyprodemo        D  try report or cache data for background.

2025-12-13 12:47:05.063 23850-23904 RMonitor_report         com.tencent.demo.buglyprodemo        V  reportNow, plugin: net_quality, strategy:ReportStrategy(needCache=true, priority=2, connectTimeout=30000, readTimeout=30000, retryTimes=3, retryStrategy=RETRY_BACKOFF, uploadStrategy=UPLOAD_WIFI, alreadyRetryTimes=0), dbId: 0
Bugly监控定位
无极智能低码
Hippy开发框架
Shiply容器与发布
Copyright © 1998 - 2024 Tencent. All Rights Reserved.
服务协议
隐私保护声明
腾讯公司版权所有主体备案号粤B2-20090059