崩溃相关
为什么本地崩溃没有上报？如何进行排查？
1. 确认 SDK 本地已被正确初始化。在初始化时将 SDK 的 debug 模式
builder.debugMode设置为 true，在 adb 调试中使用 logcat -s CrashReport eup 命令过滤日志，如果可以看到终端性能监控 Pro 打印如下信息，则表明 SDK 本地已被正确初始化。06-13 11:03:09.597 27513 27513 W eup : rumpro debug模式开启，请在发布时把isDebug关闭。 -- Running in debug model for 'isDebug' is enabled. Please disable it when you release.06-13 11:03:09.597 27513 27513 E eup : --------------------------------------------------------------------------------------------06-13 11:03:09.597 27513 27513 W eup : rumpro debug模式将有以下行为特性 -- The following list shows the behaviour of debug model:06-13 11:03:09.597 27513 27513 W eup : [1] 输出详细的rumpro SDK的Log -- More detailed log of rumpro SDK will be output to logcat;06-13 11:03:09.597 27513 27513 W eup : [2] 每一条Crash都会被立即上报 -- Every crash caught by rumpro will be uploaded immediately.06-13 11:03:09.597 27513 27513 W eup : [3] 自定义日志将会在Logcat中输出 -- Custom log will be output to logcat.06-13 11:03:09.597 27513 27513 E eup : --------------------------------------------------------------------------------------------
2. 确认异常是否能被 SDK 正常捕获。在触发崩溃或 ANR 问题后，如有以下日志打印，表明崩溃异常可以正常被 SDK 捕获。
06-13 11:11:41.777 29271 30104 E eup : #++++++++++Record By rumpro++++++++++#06-13 11:11:41.777 29271 30104 E eup : # You can use rumpro(https://console.cloud.tencent.com/monitor/rumpro) to get more Crash Detail!06-13 11:11:41.777 29271 30104 E eup : # PKG NAME: com.tencent.demo.rumprodemo06-13 11:11:41.777 29271 30104 E eup : # App VER: 1.0.006-13 11:11:41.777 29271 30104 E eup : # SDK VER: 4.3.0.30-SNAPSHOT06-13 11:11:41.778 29271 30104 E eup : # LAUNCH TIME: 2023-06-13 11:09:4106-13 11:11:41.778 29271 30104 E eup : # CRASH TYPE: JAVA_CRASH06-13 11:11:41.778 29271 30104 E eup : # CRASH TIME: 2023-06-13 11:11:4106-13 11:11:41.778 29271 30104 E eup : # CRASH PROCESS: com.tencent.demo.rumprodemo06-13 11:11:41.778 29271 30104 D eup : isAppForeground:true06-13 11:11:41.778 29271 30104 E eup : # CRASH FOREGROUND: true06-13 11:11:41.778 29271 30104 E eup : # CRASH THREAD: Thread-906-13 11:11:41.778 29271 30104 E eup : # REPORT ID: cf5fb020-4c42-4cee-8d78-299940bd4d5606-13 11:11:41.779 29271 30104 E eup : # CRASH DEVICE: V2034A UNROOT06-13 11:11:41.780 29271 30104 E eup : # RUNTIME AVAIL RAM:5672812544 ROM:87523766272 SD:8731404697606-13 11:11:41.780 29271 30104 E eup : # RUNTIME TOTAL RAM:8068177920 ROM:116628795392 SD:11641908019206-13 11:11:41.780 29271 30104 E eup : # CRASH STACK:06-13 11:11:41.780 29271 30104 E eup : java.lang.RuntimeException: This Crash create for Test! You can go to rumpro see more detail!06-13 11:11:41.780 29271 30104 E eup : at com.tencent.rumpro.proguard.dz.dq(Unknown Source:16)06-13 11:11:41.780 29271 30104 E eup : at com.tencent.rumpro.library.rumpro.testCrash(Unknown Source:28)06-13 11:11:41.780 29271 30104 E eup : at com.tencent.demo.rumprodemo.MainActivity$2$1.run(MainActivity.java:85)06-13 11:11:41.780 29271 30104 E eup : at java.lang.Thread.run(Thread.java:919)06-13 11:11:41.780 29271 30104 E eup : #++++++++++++++++++++++++++++++++++++++++++#
3. 检查异常是否能正常上报。可以在上述过滤的日志中检索
crash upload 关键字，会打印崩溃类型+上报是否成功的日志。如上报成功，会有如下打印示例，如上报不成功，可 联系我们。06-13 11:25:44.752 1566 1795 I eup : java.lang.RuntimeException, crash upload success!
其他问题原因分析：
上报可能存在一定延时，如确认已成功打印上报成功的日志，可以等待数分钟后刷新页面看是否已经上报。
如遇 SDK 无法正常捕获崩溃异常的情况，可以检查当前业务中是否有其他逻辑注册了异常捕获函数或信号，或是有集成其他第三方异常捕获 SDK。建议仅在业务中集成一项异常捕获 SDK，其他 SDK 捕获逻辑可能会对 SDK 的异常捕获存在干扰。
为什么有的信息（如进程信息）没有数据展示？
进程信息：Java 崩溃不上报进程信息。如是 Native 崩溃或 ANR 问题，进程信息的上报链路不跟随崩溃上报，用户在发生崩溃问题后，需再次启动 App，才会上报进程信息，并自动关联至对应异常个例。如遇进程信息栏目未展示，可能是用户未二次启动 App。
Native 崩溃的部分现场数据：在发生 Native 崩溃时，如 JVM 相关的现场数据无法获取，原因可能是 JVM 环境可能已被破坏，崩溃处理逻辑无法进入 Java 层进行采集。
其他信息：与崩溃捕获处理链有关，可能是系统逻辑中断了处理导致信息未采集完成。详情可 联系我们 进行处理。
为什么相同的崩溃问题没有被聚在同一个 Issue 里？
终端性能监控 Pro 会提取崩溃问题出错堆栈中的部分栈帧作为特征进行聚合，在问题详情的顶部展示了提取的堆栈特征。主观认为相同的堆栈，未被聚合在同一个 Issue 中，是因为堆栈之间存在差异导致提取的特征之间存在差异。
为什么联网设备数的波动较大？崩溃率的波动较大？
联网设备数的统计是根据设备 ID 进行统计的，不正确的设置设备 ID（uniqueId）会导致联网设备数统计异常，如不能将不同设备的设备 ID 设置为相同值或固定值，联网设备数波动可能受此影响。
崩溃率的波动可能会受联网设备数的影响。如联网设备数趋于稳定，而崩溃率波动较大，则需根据具体业务逻辑进行排查。
如何判断崩溃问题上报的 SDK 版本？
可以先通过筛选条件过滤 App 版本，找到当前 App 版本的一条上报个例，在上报个例的现场数据中，可以找到 SDK 版本号字段，即可知道当前集成的 SDK 版本号。
为什么上报的堆栈提示未翻译？
如在出错堆栈中提示堆栈未翻译，可以先进行如下自查：
对应的符号表是否已经上传，Java mapping 符号表使用
版本号+构建号进行匹配，Native so 符号表使用 UUID 进行匹配。如果是 Native 堆栈，需检查上传的 Native so 是否是被裁剪过的 so，裁剪过的 so 不携带符号表，无法进行翻译。可以使用
file 命令查看 so 是否被裁剪，本地执行 file libxxx.so 来打印 so 相关信息。not stripped 是未裁剪过的so，stripped是裁剪过的 so。如仍不能解决问题，可参见 符号表 FAQ。
ANR 相关（Android）
为什么本地 ANR 没有上报？如何进行排查？
为什么有的信息（如 ANR_INFO 、ANR Trace）没有数据展示？
ANR 相关信息：部分 ANR 信息，如 ANR Trace、ANR_INFO 信息获取不到，可能和厂商定制化的 ANR 处理逻辑有关，部分机型在系统发出 ANR 信号后，会直接停止进程，因此来不及获取对应 ANR 信息。
其他信息：与崩溃捕获处理链有关，可能是系统逻辑中断了处理导致信息未采集完成，详情可 联系我们 进行咨询与反馈。
为什么相同的 ANR 问题没有被聚在同一个 Issue 里？
ANR 发生的条件是什么？
在 Android 中，系统会在以下情况判定 ANR（应用程序无响应）事件发生：
当应用程序在主线程上执行耗时操作时，例如网络请求或长时间的计算，而没有及时响应用户输入事件（例如点击屏幕或按键）时，系统会认为应用程序无响应。
当应用程序在5秒钟内没有响应用户输入事件时，系统会认为应用程序无响应。
当应用程序在 BroadcastReceiver 或 Service 组件中执行耗时操作时，而没有及时完成操作并释放锁时，系统会认为应用程序无响应。
对于 ANR 应如何优化？有什么优化建议？
避免主线程中进行耗时操作。
使用异步任务来处理耗时操作。
使用多线程处理耗时操作。
使用 Handler 处理消息。
卡顿相关
挂起率是怎么统计的？
挂起率是以设备为单位，按天统计，该设备在一天中，应用在前台时，两帧耗时超过200ms的挂起时长，以及应用在前台的时长。
设备挂起率 = 设备一天的累计挂起时间（单位秒）/ 设备一天的前台总时长 （单位小时），挂起率的单位是秒/小时（s/h）。
FPS 是怎么统计的？
FPS 按场景统计，当前统计的是应用包含 UI 真实刷新的 FPS，剔除了页面无 UI 刷新时的数据。平台当前展示的 FPS 数据通过了归一化处理，以兼容不同屏幕刷新率。
卡顿的方法耗时是怎么统计的？
卡顿问题监控中，方法耗时是通过连续抓栈，结合抓栈间隔，估算得到。例如一个堆栈被连续抓中6次，抓栈间隔是52ms，则这个堆栈的执行耗时是6 x 52 = 312ms 。
这种估算方式存在误差，误差为抓栈间隔，但是卡顿耗时却是准确的，表示一个 UI 线程的消息执行的耗时。当前卡顿监控通过监控 UI 线程的消息执行耗时来判断应用是否发生了卡顿。
堆栈树或者火焰图中，耗时为52ms的堆栈代表什么？
如果一个堆栈耗时为52ms，表示这个堆栈在连续抓栈过程中，只被抓中了一次，并不代表其真正耗时为52ms。如果一个堆栈被抓中 N 次，其中 N 大于1，则表示该堆栈耗时一定大于(N-1)*52ms。
抓栈间隔：
Android 与 iOS 的机型，抓栈间隔可能都有差异，您可以结合时间片中显示的抓栈次数，再结合推算的抓栈耗时推算出本个例的抓栈间隔。
什么是关键堆栈耗时？
每一个个例包含一棵堆栈树，为了聚合问题，需要抽取特征。在抽取关键堆栈时会产生耗时，导致卡顿。如下所示就是一个个例的关键堆栈。
叶子结点最大耗时有什么作用？
叶子结点最大耗时是指一个堆栈树，所有叶子结点中耗时最大的。如果一个卡顿问题，其叶子结点最大耗时比较大，甚至接近于关键堆栈耗时，说明叶子结点的堆栈就是卡顿的主要原因。像死锁，UI 线程执行 IO 操作，UI 线程访问 DB，往往叶子结点最大耗时会比较大。
符号表相关
为什么异常堆栈提示未翻译？
异常堆栈提示未翻译的主要原因是相应的符号表没有上传。
1. 可以单击去上传切到符号表 Tab，根据指引上传指定的符号表。
2. 确认符号表上传成功后，单击问题详情顶部的手工还原进行堆栈重还原。
说明：
手工还原堆栈后，异常堆栈发生了变化，根据异常堆栈生成的个例特征也会发生变化，会使得重还原后的个例，聚合到其他的 Issue 中。
为什么网页上传，拖拽文件失败？
无论是 so 符号表，dSYM 文件还是 Java mapping 文件，都需要用户先用 zip 压缩后，再拖拽上传。上传组件只支持 zip 文件，不支持其他格式的文件。
对于 mapping 文件，一定要命名为 mapping.txt，再用 zip 压缩成 mapping.txt.zip，然后拖拽到上传区域中。
对于 so 文件，先将要上传的 so 文件用 zip 压缩，如 libnative.so，zip 压缩成 libnative.so.zip，然后拖拽到上传区域中。
对于 dSYM 文件，先将要上传的 dSYM 文件用 zip 压缩，如 RUMPro.dSYM，压缩成 RUMPro.dSYM.zip 后，拖拽上传 RUMPro.dSYM.zip 文件。
为什么网页上传符号表，提示成功，符号表文件的状态还显示未上传？
这种情况有两种可能：
情况一：符号表没有真正上传成功，可参见 为什么网页上传，拖拽文件失败，正确命名以及压缩符号表文件。
情况二：符号表文件已经上传，但是入库时间有延时，需要重新刷新页面。
为什么上传 mapping 文件，提示成功，但是找不到上传的符号表文件？
这种情况，可先尝试刷新页面，如果刷新页面后，依然找不到上传的符号表，或者符号表 Tab 显示该符号表文件未上传，可能是 mapping 文件没有正确命名。
对于 mapping 文件，一定要命名为 mapping.txt，再用 zip 压缩成 mapping.txt.zip，然后拖拽到上传区域中。
mapping 文件以
App 版本号 + 构建号 作为 Key 来识别，请查看版本号和构建号是否填写正确。上传符号表为什么需要 Java 环境?
符号表提取工具依赖于 Java 环境，符号表工具只提取必要的信息，可以大幅度减少需要上传的文件体积。
符号表上传失败提示 UUID 不匹配?
每次构建，符号表的 UUID 都会发生改变，所以需要当次构建生成的符号表文件才能还原当次构建后上传的 crash。
不配置还原符号表会影响异常上报吗？会有什么影响?
不会影响异常上报。没有符号表，堆栈无法还原成代码中的类或方法及源文件行号，会对异常合并存在一定影响。
每个版本都要配置符号表吗?
是的，每个 App 版本都需要对应一份符号表（Java 的 Mapping 文件及 so 的 Symbol 文件，applec++的 dSYM 文件），配置只对设置的版本有效，重复配置将会覆盖。
Java 崩溃堆栈中没有行号信息（如出现 Unknown Source）？
在 ProGuard 配置中添加 keep 行号的设置，如：
-keepattributes SourceFile,LineNumberTable
Unity Android 项目需要配置符号表吗?
Unity 项目的 Android工程生成的 Java 代码只有几个入口类，没有 ProGuard 混淆必要，所以无需配置符号表（即 mapping 信息）。
Unity 项目的 Android 工程中默认加载的几个 Native 库（libmono.so、libunity.so 等）没有 debug 版本，所以开发者也无法获得对应的符号信息进行配置。
注意：
如果开发者有自己开发独立的功能组件（.jar 或 .so）集成到 Unity 项目中，需配置相应的符号表信息（开启了“Development Build”选项，development 文件夹里面的就是 debug 版本的 so，可以用平台的符号表工具生成符号表文件并上传到版本管理）。
为什么我的符号表已经正确上传，堆栈还是不可读？
针对这种情况的解决方法：建议重新上传符号表，然后单击手工还原触发重新还原。
如果重新上传符号表后，堆栈仍然不可读，很可能是符号表或抓取的堆栈存在问题，您可以线下用堆栈中的地址来手动还原，检查系统抓的堆栈是否可以正常还原。
怎样判断上传的符号表是否有效？
检查是否有还原出源码文件名和行号。
文件非法是什么意思？怎么处理？
上传的文件格式不对，系统扫描到不是符号表文件。 系统扫描规则是：遍历到一级文件目录下的 so 文件，否则认为非法。建议用单个 so 文件上传，后续版本会优化扫描规则。
