- 异常
- 崩溃
- ANR
- 错误
- 发生次数
- 设备的唯一标识（Device ID）
- 问题上报
- 联网
- 联网设备
- 影响设备
- 设备异常率
- 次数异常率
- 启动次数
- 今日设备异常率
- 首次上报时间
- 问题累积影响设备
- 问题累积影响次数
- 小时/累计
- 真机/模拟器
- 数据更新时间
- 问题ID
- 上报ID
- 崩溃时访问地址
- 客户端侧上报ID
- 二次上报
- 符号表
- 搜索维度
常用术语
异常
App在运行过程中发生的崩溃、ANR、错误，统称为异常。
崩溃
用户在使用App过程中发生一次闪退，计为一次崩溃。
ANR
用户在使用App过程中出现弹框，提示应用无响应，计为一次ANR，ANR仅用于Android平台应用。
错误
主动上报的Exception、Error，或脚本(如C#、Lua、JS等)错误，统称为错误。
发生次数
一个异常发生且被记录上报，计为一次异常发生。
设备的唯一标识（Device ID）
用于唯一标识一个设备的标记，由sdk自己默认生成，并在应用卸载前一直保持不变和有效。
CrashSight使用Device ID来识别设备，即，如果有X条问题上报的Device ID相同，那么这X条上报会使问题发生次数+X，但是影响设备数+1。联网和问题上报都会带有Device ID信息，以下是一些常用平台上CrashSight SDK生成Device ID的默认方式。
| 平台 | 默认的Device ID生成方式 |
|---|---|
| Android | 首次启动时生成UUID |
| iOS | IDFV |
| Windows | MAC地址 |
问题上报
当触发CrashSight SDK的问题上报机制（对于崩溃是自动捕获，对于错误是调用接口，详情可参考CrashSight帮助文档），CrashSight会自动收集信息并进行上报。
联网
CrashSight SDK初始化时，将会立即进行一次上报，它被称作联网。联网产生的数据可以用于统计启动次数。
联网设备
以设备为判断指标，每一个发生联网的设备或者发生一次上报，即为一个联网设备。 在指定时间范围内，若一个设备重复发生联网行为，只算一个联网设备。(设备去重以设备的唯一标识为准)
影响设备
一台设备发生异常，计为一个影响设备。 在指定时间范围内，若一个设备发生多次异常，只算一个影响设备,(设备去重以设备的唯一标识为准)
设备异常率
诸如设备崩溃率、设备卡顿率、设备ANR率、设备错误率等 即影响设备/联网设备 比值。
次数异常率
诸如次数崩溃率、次数卡顿率、次数ANR率、次数错误率 即发生次数/联网次数的比值。
启动次数
应用完全退出后重新启动，计为一次启动(总启动次数具体是启动上报+异常上报中携带启动次数来累计，具体由sdk来进行启动判定)。
今日设备异常率
当日时间内的 异常影响设备/联网设备。
首次上报时间
问题第一次上报系统的时间。
问题累积影响设备
问题第一次上报系统之后，截止当前时间，一共影响设备的总数。
问题累积影响次数
问题第一次上报系统之后，截止当前时间，发生总次数。
小时/累计
小时窗口是，对应当前小时的00分00秒 到 当前小时 59分59秒之间。 累计窗口是，对应当天00时00分00秒 到 当前小时 59分59秒之间。
真机/模拟器
真机：真实的移动物理设备。 模拟器：能在个人计算机运行并模拟安卓手机系统的模拟器(大多数模拟器，每次启动app会产生新的设备唯一标识，同时云游戏设备也有这样的特点，也会标记为模拟器)。
数据更新时间
统计结果数据后台刷新的时间(数据更新是后台异步更新，默认崩溃趋势间隔10分钟左右更新一次)。
问题ID
异常在上报后会进行归类(同一类异常归为一个集合，称为一个问题)，对应问题的唯一的UUID叫做问题ID，同问题一一对应。
上报ID
一个异常在上报的时候，产生一个唯一uuid叫做上报ID，同该次上报一一对应。
崩溃时访问地址
当发生坏内存访问时，程序实际访问的地址会和预期不符，CrashSight能上报崩溃时程序访问的地址。一般来说，崩溃时访问0x0为空指针，而崩溃时访问大地址则是野指针。
客户端侧上报ID
CrashSight SDK会在处理崩溃/错误时生成一个随机的UUID，并随崩溃/错误一同上报，这个UUID被称为客户端侧上报ID。客户端侧上报ID是每条上报的唯一标识，可以用来查找和定位上报信息。开发者可以在客户端的日志中搜索“expuid”来找到客户端侧上报ID。
二次上报
当崩溃发生时，CrashSight会尝试立即将错误信息上报到后台，但是因为种种不可抗因素（例如用户强杀程序，网络错误等），崩溃信息的处理和上报可能无法立即完成。在下次启动时，CrashSight会检查上次是否有未上报的崩溃信息，如果有，则会进行上报，这一过程被称为二次上报。值得注意的是，由于上次崩溃信息处理的过程可能没有完整进行，二次上报的崩溃信息有时会有所缺失。
符号表
CrashSight需要符号表才能对堆栈进行还原，上传符号表请参考符号表使用处理相关说明。
为了保证数据安全，CrashSight不会要求您直接上传原始符号表文件（so、dsym、pdb等），而是使用我们的符号表工具提取出stif文件再进行上传。
每个符号表拥有一个唯一的UUID，如果上传的符号表UUID与之前的一样，CrashSight认为这份符号表是重复的，将会使用新的符号表替代旧的（换言之，如果您上传了错误的符号表，您可以利用这个机制来修正错误）。在还原堆栈时，CrashSight会优先使用UUID匹配符号表，如果匹配失败，则会使用版本号+库名来查找符号表。
上传Android符号表时，请务必保证您的so文件带有调试信息。您可以通过stif文件的大小来简单判断，如果生成的stif文件很小（<=1kb），则可能是您使用了不带调试信息的so来制作符号表，这样的符号表并不能成功还原堆栈。获取带调试信息的so的方法可参考各平台符号表文件格式，及在unity、unreal引擎中的生成方法。
搜索维度
CrashSight页面中提供了丰富的问题筛选功能，以下是可选搜索维度的含义。
| 搜索维度 | 含义 | 搜索维度 | 含义 |
|---|---|---|---|
| 问题最后上报时间 | 问题最近一次上报的时间 | 问题首次上报时间 | 问题初次上报的时间 |
| 问题首次上报版本 | 问题初次上报时的版本号 | 异常类型 | CrashSight对异常上报的分类，如Native崩溃、C#错误等 |
| 异常大类 | 崩溃、ANR或错误 | 问题标签 | 可以在“问题列表”页设置的自定义标签 |
| 问题处理状态 | 问题处理状态，可在“问题列表”页配置 | 是否关联缺陷单 | 是否关联缺陷单，可在“问题列表”页配置 |
| 问题处理人 | 问题处理人，可在“问题列表”页配置 | 版本 | CrashSight SDK提取到的版本号，可通过接口设置 |
| 上报时间 | 问题上报时间 | 发生时间 | 问题发生时间 |
| 应用包名/Bundle ID | Android的包名，或iOS的Bundle ID | 应用分发渠道 | 应用分发渠道，可通过接口设置 |
| 问题ID | 问题列表中展示的问题ID，一类问题拥有同一个问题ID | 上报ID | 服务端生成的上报ID，每一次上报都有唯一的上报ID |
| 客户端侧上报ID | 客户端上报时生成的上报ID，可以在日志中搜索“expuid”查看，也可在上报详情中查看 | 用户ID | 用于标识用户，可通过接口设置，默认为“unknown” |
| 设备ID | 用于标识设备，详见Device ID | 异常名 | 异常名 |
| 异常消息 | 异常消息 | 设备原始Model | 从系统接口提取到的机型 |
| 应用位数 | 32位或64位 | 系统版本 | 系统版本 |
| 出错进程名 | 出错进程名 | 出错线程名 | 出错线程名 |
| 运行时长 | 运行时长 | 是否模拟器 | 是否模拟器 |
| 是否系统退出 | CrashSight后台匹配到系统退出特征 | ROM | 系统固件名称（仅Android） |
| 自定义关键字 | 用户自定义的关键字，详见自定义数据 | 出错堆栈 | 出错线程的堆栈 |
| 出错堆栈（还原前） | 还原前的原始堆栈 |