崩溃分析白皮书

第一章 产品概述

崩溃分析系统为移动APP提供崩溃监控及崩溃模块定位，通过对APP崩溃数据的监控和分析，从而协助APP降低崩溃频率，提升用户满意度。

第二章 产品优势

2.1 接入简单

支持Android、iOS极简接入, 只依赖SDK，所有的功能提供运行时开关控制。

2.2 实时监控

多种时间维度分析崩溃趋势，及时发现重点问题。

2.3 信息全面

采集崩溃设备信息，异常堆栈信息，运行时信息，提升定位效率。

2.4 安全稳定

采用安全解决方案和服务器集群设计，服务安全可靠。

2.5 弹性设计

所有服务之前解偶，以功能为单位迭代升级。

第三章 应用场景

崩溃监控系统定位于为移动APP提供崩溃监控及崩溃模块定位的服务平台，具有接入简洁、响应及时、信息全面、分析透彻、统计详细等特点。通过对APP崩溃数据的监控和分析，从而协助APP降低崩溃频率，提升用户满意度。

第四章 总体设计

4.1 产品架构

4.2 部署架构

第五章 产品功能

5.1 崩溃上报

实时上报所有崩溃异常，支持用户未联网时崩溃数据保存，上报信息全面有效，帮助开发者快速定位解决问题。

5.2 崩溃分析

支持按分钟、小时、按天等多种时间维度的崩溃统计分析，实现TOP崩溃展示和趋势分析，帮助开发者快速发现重点问题，提升用户留存。

5.3 BUG列表

系统按照一定的规则，将崩溃问题分类汇总，形成BUG列表，方便开发者或测试人员跟进修改。

5.4 OOM监控

OOM（out-of-memory event） 通常是发生在：应用持续内存增长，在内存不足，系统会先触发MemoryWarning通知，此时内存如仍持续增长，即可能被系统kill。 应用被系统kill时可能是在前台，也可能是在后台，崩溃监控系统的SDK只上报在前台触发的OOM事件。

5.5 高级功能

可配置平台、版本、build，并针对各种异常信息进行详尽的搜索查询，支持导出报表，支持不同查询条件的对比查询。

第六章 部署环境要求

6.1 硬件要求

根据日活1000w，QPS 峰值6w估算：

• 客户端上报API，用于接收客户端上报数据，单个4C8G容器（两个实例）可支持uv上报约3000 QPS的经验；
• 1000w日活，大约部署4个4C8G容器可满足需求；
• 崩溃监控系统服务，部署2个4C8G容器可满足需求；
• iOS解析服务，用于iOS原生崩溃数据的解析，一台I5 CPU/8G/1T的Mac机器约能满足需求。

6.2 软件要求

• 操作系统

建议CentOS 6.5以上；

• 中间件